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
>
>

Reply via email to