Itay,
you seem to ignore selective parts of the answers and tips which you are
given, and then rediscover them selectively 3 posts later.
itay sahar wrote:
Andre,
I'm not sure why you worry about the other cookie value.
Thank you for your concern, but I don't worry too much. It is not my
application, it is yours.
let me show you an
example
maybe then you may see something that i'm missing.
getCookieMaxAge() is 31536000
cookiePath is /jboss-seam-jpa
That's nice ! That is the first time you show us what getCookieMaxAge()
and cookiePath can actually contain.
So now I can go to sleep peacefully, knowing that these parts of the
cookie do not in effect contain control characters.
You see, before now, you were the only person who could know that for sure.
What can be wrong here ? It works!
I am sure that your first version of the application worked fine too, as
long as the email addresses were very short.
Are you worry about special character on cookiePath. I can make sure
in my application this won't happen right ?
Right ! The whole point of my note was to point out to you that you
should make sure of it.
Because if you did not make sure of it, then you could have been
unexpectedly hit by yet another control character sometime in the
future. But now that you have taken care of it, I am reassured and happy.
If you think something is wrong in the methods below please suggest
solution..
The method below looks ok, by itself. My worries were about things used
in the method below, but coming from somewhere else previously unknown,
like getCookieMaxAge() and cookiePath.
Thanks!
On Mon, Dec 7, 2009 at 10:42 PM, itay sahar <itay.sa...@gmail.com> wrote:
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 <a...@ice-sa.com> 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: 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
