sure!
protected void setCookieValueIfEnabled(String value)
{
FacesContext ctx = FacesContext.getCurrentInstance();
if ( isCookieEnabled() && ctx != null)
{
HttpServletResponse response = (HttpServletResponse)
ctx.getExternalContext().getResponse();
Cookie cookie = new Cookie( getCookieName(), value );
cookie.setMaxAge( getCookieMaxAge() );
cookie.setPath(cookiePath);
response.addCookie(cookie);
}
}
On Mon, Dec 7, 2009 at 10:26 PM, André Warnier <[email protected]> wrote:
> itay sahar wrote:
>
>> 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);
>> }
>> }
>>
>
> That's not the code setting the cookie, it is code clearing a cookie value.
> But nevertheless..
>
>
> 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)!
>>
>
> And may I point you to a remark from quite a few posts ago, which went like
> :
> ...
> --quote--
>
> 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 ?
> --end of quote--
>
>
> > but i'm not sure it solve all the
> > scenarios/possibilities.
>
> No, as also already pointed out, considering the code you posted before, a
> control character could also creep into cookiePath or getCookieMaxAge().
>
> Also read what Mark posted previously, about possible "=" signs getting
> into the Base64 encoded value (at the end, for padding).
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>