sure!
protected void clearCookieValue()
   {
      Cookie cookie = getCookie();
      if ( cookie!=null )
      {
         HttpServletResponse response = (HttpServletResponse)
FacesContext.getCurrentInstance().getExternalContext().getResponse();

         cookie.setValue(null);
         cookie.setPath(cookiePath);
         cookie.setMaxAge(0);
         response.addCookie(cookie);
      }
   }
But look like problem is fixed. I extended the encodeToken method and change
it to be
return Base64.encodeBytes(sb.toString().getBytes(),
Base64.DONT_BREAK_LINES);
And now it works (like a charm)! but i'm not sure it solve all the
scenarios/possibilities.

On Mon, Dec 7, 2009 at 9:47 PM, Pid Ster <p...@pidster.com> wrote:

> On 7 Dec 2009, at 19:26, itay sahar <itay.sa...@gmail.com> wrote:
>
> > 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!
>
> This is nice, but what does it prove?
>
> How about posting the bit of code where you create and set the cookie?
>
> Then we might see what you're doing wrong.
>
> p
>
> > 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
> >>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to