You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by David Leangen <wi...@leangen.net> on 2007/07/31 04:18:08 UTC
Testing for cookie capability
What would be the usual way of testing a client for cookie capability?
Essentially, I want to know if I can rely on the use of a cookie, or if
I should fall back on coding something into the URL parameters.
Thanks!
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing for cookie capability
Posted by Johan Compagner <jc...@gmail.com>.
session (in mem only) cookies are most likely usable.
But i don't see a big plus for them in a wicket application..
disk based cookies could be blocked earlier by people (privacy)
and third party cookies are now blocked by pretty much all the browsers
(so the url is www.wicket.org and the cookie that wants to set it self is in
that page but from a www.tapestry.org url)
johan
On 7/31/07, David Leangen <wi...@leangen.net> wrote:
>
>
> Actually, in the normal case, I just use normal cookies (i.e. stored to
> disk
> like you write below).
>
> Does it happen often that a user has cookies disabled or a client does not
> support cookies?
>
> Or am I being too paranoid, here?
>
>
>
>
> > -----Original Message-----
> > From: Johan Compagner [mailto:jcompagner@gmail.com]
> > Sent: 31 July 2007 20:04
> > To: users@wicket.apache.org; wicket@leangen.net
> > Subject: Re: Testing for cookie capability
> >
> >
> > i guess you want to set a cookie that is stored on disc on the client?
> > because setting a cookie that is a session cookie doesn't really make
> much
> > sense
> > except if you really also don't create a http session./wicket session
> >
> > But if it is a stored cookie then appending it to the url doesn't
> > make much
> > sense because
> > that won't tell you anything the next time.
> >
> > johan
> >
> >
> > On 7/31/07, David Leangen <wi...@leangen.net> wrote:
> > >
> > >
> > > > Looking at the logic, even if I set my own cookies and/or piggyback
> on
> > > > the jsessionid value, there is still the case of the first
> > visit (since
> > > > no values are set, so I don't know if it's just the first visit, or
> a
> > > > client with no cookie capability).
> > >
> > > Ok... that's just not true.
> > >
> > > Looks like wicket already uses the technique you mentioned.
> > >
> > > So, piggybacking works just great!
> > >
> > >
> > > Thanks again, Igor.
> > >
> > >
> > > Cheers,
> > > Dave
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Testing for cookie capability
Posted by David Leangen <wi...@leangen.net>.
Actually, in the normal case, I just use normal cookies (i.e. stored to disk
like you write below).
Does it happen often that a user has cookies disabled or a client does not
support cookies?
Or am I being too paranoid, here?
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@gmail.com]
> Sent: 31 July 2007 20:04
> To: users@wicket.apache.org; wicket@leangen.net
> Subject: Re: Testing for cookie capability
>
>
> i guess you want to set a cookie that is stored on disc on the client?
> because setting a cookie that is a session cookie doesn't really make much
> sense
> except if you really also don't create a http session./wicket session
>
> But if it is a stored cookie then appending it to the url doesn't
> make much
> sense because
> that won't tell you anything the next time.
>
> johan
>
>
> On 7/31/07, David Leangen <wi...@leangen.net> wrote:
> >
> >
> > > Looking at the logic, even if I set my own cookies and/or piggyback on
> > > the jsessionid value, there is still the case of the first
> visit (since
> > > no values are set, so I don't know if it's just the first visit, or a
> > > client with no cookie capability).
> >
> > Ok... that's just not true.
> >
> > Looks like wicket already uses the technique you mentioned.
> >
> > So, piggybacking works just great!
> >
> >
> > Thanks again, Igor.
> >
> >
> > Cheers,
> > Dave
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing for cookie capability
Posted by Johan Compagner <jc...@gmail.com>.
i guess you want to set a cookie that is stored on disc on the client?
because setting a cookie that is a session cookie doesn't really make much
sense
except if you really also don't create a http session./wicket session
But if it is a stored cookie then appending it to the url doesn't make much
sense because
that won't tell you anything the next time.
johan
On 7/31/07, David Leangen <wi...@leangen.net> wrote:
>
>
> > Looking at the logic, even if I set my own cookies and/or piggyback on
> > the jsessionid value, there is still the case of the first visit (since
> > no values are set, so I don't know if it's just the first visit, or a
> > client with no cookie capability).
>
> Ok... that's just not true.
>
> Looks like wicket already uses the technique you mentioned.
>
> So, piggybacking works just great!
>
>
> Thanks again, Igor.
>
>
> Cheers,
> Dave
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Testing for cookie capability
Posted by David Leangen <wi...@leangen.net>.
> Looking at the logic, even if I set my own cookies and/or piggyback on
> the jsessionid value, there is still the case of the first visit (since
> no values are set, so I don't know if it's just the first visit, or a
> client with no cookie capability).
Ok... that's just not true.
Looks like wicket already uses the technique you mentioned.
So, piggybacking works just great!
Thanks again, Igor.
Cheers,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing for cookie capability
Posted by David Leangen <wi...@leangen.net>.
Excellent! Thanks again.
Looking at the logic, even if I set my own cookies and/or piggyback on
the jsessionid value, there is still the case of the first visit (since
no values are set, so I don't know if it's just the first visit, or a
client with no cookie capability).
Either I need to always append the value to the URL for the first case
(and remove it later if I need to), or use the redirect trick you
mentioned.
How do redirects work within Wicket, though?
Looking at the API:
redirect(java.lang.String url)
CLIENTS SHOULD NEVER CALL THIS METHOD FOR DAY TO DAY USE!
Seems to be that by forcing a redirect (in the normal way), this could
seriously break wicket encapsulation. So, what's the wicket way to
redirect?
Cheers!
Dave
> you need to set it up yourself.
>
> request A
> setcookie C
> append &cookie=C to url
> request B
> if (!cookie C set) always append to url
>
> you can setup an automatic redirect as the first page your users hit that
> does this check and sets a session value.
>
> so instead of /=homepage you get
>
> /=A->B->homepage
>
> another trick you can do, which is "unsupported" is to check if the url
> contains jsessionid var, if it does then you append your cookie to the url -
> so you are piggybacking onto the servlet container's check.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing for cookie capability
Posted by Igor Vaynberg <ig...@gmail.com>.
you need to set it up yourself.
request A
setcookie C
append &cookie=C to url
request B
if (!cookie C set) always append to url
you can setup an automatic redirect as the first page your users hit that
does this check and sets a session value.
so instead of /=homepage you get
/=A->B->homepage
another trick you can do, which is "unsupported" is to check if the url
contains jsessionid var, if it does then you append your cookie to the url -
so you are piggybacking onto the servlet container's check.
-igor
On 7/30/07, David Leangen <wi...@leangen.net> wrote:
>
>
> Wow! Thanks for the lightening fast reply!
>
> > no way to test it except try it - which is what the servlet container
> does
>
> Do you mean that I can query the servlet container somehow?
>
> Or I need to set up this mechanism myself?
>
>
> I poked around, but didn't see anything pop out at me that indicates it
> holds this kind of info.
>
>
> Thanks!
> Dave
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Testing for cookie capability
Posted by David Leangen <wi...@leangen.net>.
Wow! Thanks for the lightening fast reply!
> no way to test it except try it - which is what the servlet container does
Do you mean that I can query the servlet container somehow?
Or I need to set up this mechanism myself?
I poked around, but didn't see anything pop out at me that indicates it
holds this kind of info.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing for cookie capability
Posted by Igor Vaynberg <ig...@gmail.com>.
no way to test it except try it - which is what the servlet container does
first url it adds a cookie, then on next request if its not there it means
cookies are disabled
-igor
On 7/30/07, David Leangen <wi...@leangen.net> wrote:
>
>
> What would be the usual way of testing a client for cookie capability?
>
> Essentially, I want to know if I can rely on the use of a cookie, or if
> I should fall back on coding something into the URL parameters.
>
>
> Thanks!
> David
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>