I add log for the following method:
protected String encodeToken(String username, String value)
{
StringBuilder sb = new StringBuilder();
sb.append(username);
sb.append(":");
sb.append(value);
return Base64.encodeBytes(sb.toString().getBytes());
}
*Before encoding:*
sb.toString().getBytes() =
[105, 116, 97, 121, 46, 115, 97, 104, 97, 114, 64, 103, 109, 97, 105, 108,
46, 99, 111, 109, 58, 45, 51, 51, 99, 100, 102, 98, 54, 102, 58, 49, 50, 53,
54, 97, 57, 48, 99, 57, 97, 99, 58, 45, 56, 48, 48, 48, 58, 51, 54, 55, 56,
53, 55, 52, 53, 54, 55, 52, 56, 55, 53, 56, 54, 57, 51, 56]
*After encoding:*
Base64.encodeBytes(sb.toString().getBytes()) =
aXRheS5zYWhhckBnbWFpbC5jb206LTMzY2RmYjZmOjEyNTZhOTBjOWFjOi04MDAwOjM2Nzg1NzQ1
Base64.encodeBytes(sb.toString().getBytes()).getBytes()
[97, 88, 82, 104, 101, 83, 53, 122, 89, 87, 104, 104, 99, 107, 66, 110, 98,
87, 70, 112, 98, 67, 53, 106, 98, 50, 48, 54, 76, 84, 77, 122, 89, 50, 82,
109, 89, 106, 90, 109, 79, 106, 69, 121, 78, 84, 90, 104, 79, 84, 66, 106,
79, 87, 70, 106, 79, 105, 48, 52, 77, 68, 65, 119, 79, 106, 77, 50, 78, 122,
103, 49, 78, 122, 81, 49, 10, 78, 106, 99, 48, 79, 68, 99, 49, 79, 68, 89,
53, 77, 122, 103, 61]
Please note that any change in the above might affect the decoder.
Thanks!
On Mon, Dec 7, 2009 at 3:04 PM, itay sahar <itay.sa...@gmail.com> wrote:
> Thanks André,
> *
> *
> *I agree with you about the doubt you have about the ":" being in C (after
> encoding).*
> return Base64.encodeBytes(sb.toString().getBytes());
> *I guess you suggest to log somthing like *
> *(new String(C)).getBytes ? If yes I post it here later. I hope you can
> then suggest somthing to sove this.*
>
>
> On Mon, Dec 7, 2009 at 1:57 PM, André Warnier <a...@ice-sa.com> wrote:
>
>> itay sahar wrote:
>>
>>> Pid,
>>> I'm not using B as the cookie value. A & B go to encode and finally you
>>> have *one *value(C). this value
>>> is sent to addCookie.
>>>
>>> C is somthing like:
>>>
>>> aXRheS5zYWhhckBnbWFpbC5jb206NmRlNWNhNGY6MTI1NGM0NjExMTA6LTdmZWI6OTEzNTQ4NjI0
>>>
>>
>> Ok, let's take this at face value.
>>
>> So yet, you are still getting an exception, which says that there is a
>> "control character" in the value of the cookie which you are trying to add.
>>
>> Let's assume for now that the addCookie method itself has no bug, and that
>> what it says in the exception is the truth.
>>
>> It also does not look (in these email communications), as if your value C
>> above has a "control character" in it.
>>
>> (But note : there still could be one, that we do not see here in these
>> emails. For example, if the value C above was in reality ending in a CR/LF
>> pair. Apart from the string C itself above, you should maybe also log its
>> length in bytes, so that we can really make sure that this is not the case).
>>
>> Then, if I remember well the code which really adds the cookie (and which
>> is not the one shown below), independently of the "value", there is also in
>> these cookies an expiration date, and a path, which you add to the cookie
>> string one by one.
>> So really, when you do the addCookie, what you do is creating a cookie
>> header which looks like :
>> Set-Cookie: cookie-name=cookie-value(C);expires=somedate;path=somepath
>>
>> Any one of "somedate" or "somepath" could (potentially) contain a control
>> character, and the exception would only show up when you actually do the
>> addCookie() of the whole value (including expiration date and path) at once.
>>
>>
>>
>>
>>
>>
>>> On Mon, Dec 7, 2009 at 12:16 PM, Pid <p...@pidster.com> wrote:
>>>
>>> On 06/12/2009 21:51, itay sahar wrote:
>>>>
>>>> Hi Andre,
>>>>>
>>>>> please see below input and output of:
>>>>> protected String encodeToken(String username, String value)
>>>>> {
>>>>> StringBuilder sb = new StringBuilder();
>>>>> sb.append(username);
>>>>> sb.append(":");
>>>>> sb.append(value);
>>>>> return Base64.encodeBytes(sb.toString().getBytes());
>>>>> }
>>>>>
>>>>> Input is:
>>>>>
>>>>> username= itay.sa...@gmial.com
>>>>> value= 6de5ca4f:1254c461110:-7feb:9135486247122677484
>>>>>
>>>>> Output is (this is what actually addCookie get as parameter):
>>>>>
>>>>> 6de5ca4f:1254c461110:-7feb:9135486247122677484
>>>>>
>>>>> Can you suggest solution ?
>>>>>
>>>>> Yep.
>>>>
>>>> You are claiming that you are supplying A & B to the encodeToken
>>>> function,
>>>> but then you are using B as the cookie value.
>>>>
>>>> Try using the value returned from the encodeToken function instead.
>>>> Hint, if it contains a ":" character, it's not Base64 encoded.
>>>>
>>>>
>>>>
>>>> p
>>>>
>>>>
>>>> On Sun, Dec 6, 2009 at 11:28 PM, itay sahar<itay.sa...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Andre,
>>>>>
>>>>>> please see below input and output of:
>>>>>> protected String encodeToken(String username, String value)
>>>>>> {
>>>>>> StringBuilder sb = new StringBuilder();
>>>>>> sb.append(username);
>>>>>> sb.append(":");
>>>>>> sb.append(value);
>>>>>> return Base64.encodeBytes(sb.toString().getBytes());
>>>>>> }
>>>>>>
>>>>>> Input is:
>>>>>>
>>>>>> username= itay.sa...@gmial.com
>>>>>>
>>>>>> value= 6de5ca4f:1254c461110:-7feb:9135486247122677484
>>>>>>
>>>>>>
>>>>>> Output is:
>>>>>>
>>>>>>
>>>>>>
>>>>>> aXRheS5zYWhhckBnbWFpbC5jb206NmRlNWNhNGY6MTI1NGM0NjExMTA6LTdmZWI6OTEzNTQ4NjI0
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can you suggest solution ?
>>>>>>
>>>>>> On Sat, Dec 5, 2009 at 6:20 PM, André Warnier<a...@ice-sa.com> wrote:
>>>>>>
>>>>>> Mark Thomas wrote:
>>>>>>
>>>>>>> itay sahar wrote:
>>>>>>>
>>>>>>>> Caused by: java.lang.IllegalArgumentException: Control character in
>>>>>>>>
>>>>>>>>> cookie
>>>>>>>>> value, consider BASE64 encoding your value
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> org.apache.tomcat.util.http.ServerCookie.maybeQuote2(ServerCookie.java:396)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To cause this, there must be a character in the value with an
>>>>>>>> ASCII
>>>>>>>> code
>>>>>>>> of less than 0x20 or greater or equal to 0x7f and is not 0x09.
>>>>>>>>
>>>>>>>> You need to fix that first.
>>>>>>>>
>>>>>>>> Then you'll need to worry about Base64 using '=' in cookie values.
>>>>>>>> The
>>>>>>>> value needs to be quoted for this to work. Tomcat will do this
>>>>>>>> automatically if necessary.
>>>>>>>>
>>>>>>>>
>>>>>>>> Mark above is talking about the output value of the Base64 encoder
>>>>>>>>
>>>>>>> which
>>>>>>> you are using, and which you then feed to the
>>>>>>> response.addCookie(cookie)
>>>>>>> method.
>>>>>>>
>>>>>>> It is not clear (to me) where the used Base64.encodeBytes() method
>>>>>>> comes
>>>>>>> from. But wherever it comes from, it should encode any input series
>>>>>>> of
>>>>>>> bytes according to
>>>>>>> http://tools.ietf.org/html/rfc3548#section-3
>>>>>>> which cannot produce "control characters".
>>>>>>> Except that some Base64 encoders, in some cases, will "wrap" the
>>>>>>> output
>>>>>>> string at 76 bytes, by inserting a CR/LF pair, which are both
>>>>>>> "control
>>>>>>> characters". (Note that the output string of Base64 is longer than
>>>>>>> the
>>>>>>> input string, since it encodes 3 consecutive input bytes into 4
>>>>>>> output
>>>>>>> bytes.)
>>>>>>> My guess is that this is what happens here, and that could trigger
>>>>>>> the
>>>>>>> exception above.
>>>>>>> Maybe this Base64.encodeBytes() method has an optional argument which
>>>>>>> would tell it to not wrap the output value ?
>>>>>>>
>>>>>>> Note also that with the code you were showing, the control
>>>>>>> character(s)
>>>>>>> could presumably be also in "cookiePath".
>>>>>>>
>>>>>>> Why do you not log the cookie value, just before you call
>>>>>>> setCookieValueIfEnabled(String value) ?
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
