You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Don Ferguson <do...@gmail.com> on 2011/03/19 15:59:46 UTC

Handling first AJAX request when cookies are disabled

I'm struggling with a problem that probably has an easy solution.  When cookies are disabled, if the first action on viewing the site is an AJAX request, it fails because the jsessionid hasn't been written into the URL.  I notice that on other sites (such as wicketstuff), this doesn't happen because the first request gets a "302" (Temporarily Moved) to a URL that includes the jsessionid.  Is this being done by the servlet container (I'm using Jetty), or is it handled elsewhere in the stack?

One workaround to this problem is to setGatherExtenededBrowserInfo(true), but that results in the temporary display of an error page, which freaked out my boss.

Any ideas how to best handle this?  Thanks, and sorry if this has been discussed before.  I searched in vain.

-Don


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Handling first AJAX request when cookies are disabled

Posted by Don Ferguson <do...@gmail.com>.
Bernard,

I owe you a beer.  Calling session.bind() did the trick.  Thanks.

	-Don

On Mar 21, 2011, at 12:18 PM, bht@actrix.gen.nz wrote:

> Without having tested it, I would try to create a permanent session,
> hoping that the framework would do the rest in order to create server
> side state for the page:
> 
> session.bind()
> 
> The idea behind this is that Wicket can do AJAX only for stateful
> pages.
> 
> Regards,
> 
> Bernard
> 
> 
> 
> On Sat, 19 Mar 2011 07:59:46 -0700, you wrote:
> 
>> I'm struggling with a problem that probably has an easy solution.  When cookies are disabled, if the first action on viewing the site is an AJAX request, it fails because the jsessionid hasn't been written into the URL.  I notice that on other sites (such as wicketstuff), this doesn't happen because the first request gets a "302" (Temporarily Moved) to a URL that includes the jsessionid.  Is this being done by the servlet container (I'm using Jetty), or is it handled elsewhere in the stack?
>> 
>> One workaround to this problem is to setGatherExtenededBrowserInfo(true), but that results in the temporary display of an error page, which freaked out my boss.
>> 
>> Any ideas how to best handle this?  Thanks, and sorry if this has been discussed before.  I searched in vain.
>> 
>> -Don
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Handling first AJAX request when cookies are disabled

Posted by bh...@actrix.gen.nz.
Without having tested it, I would try to create a permanent session,
hoping that the framework would do the rest in order to create server
side state for the page:

session.bind()

The idea behind this is that Wicket can do AJAX only for stateful
pages.

Regards,

Bernard



On Sat, 19 Mar 2011 07:59:46 -0700, you wrote:

>I'm struggling with a problem that probably has an easy solution.  When cookies are disabled, if the first action on viewing the site is an AJAX request, it fails because the jsessionid hasn't been written into the URL.  I notice that on other sites (such as wicketstuff), this doesn't happen because the first request gets a "302" (Temporarily Moved) to a URL that includes the jsessionid.  Is this being done by the servlet container (I'm using Jetty), or is it handled elsewhere in the stack?
>
>One workaround to this problem is to setGatherExtenededBrowserInfo(true), but that results in the temporary display of an error page, which freaked out my boss.
>
>Any ideas how to best handle this?  Thanks, and sorry if this has been discussed before.  I searched in vain.
>
>-Don
>
>
>---------------------------------------------------------------------
>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