Hi Jeff,

Thanks for your hint. I tried to implement some "magic" which determines 
whether to strip the jsessionid from a URL or not based on the page I request, 
i.e. I created some RedirectPage.

The problem is: When I access this page by clicking a link on another page, the 
method HttpServletResponse.encodeRedirectURL() is called no matter what I do 
before flushing the response. And this will then add the jsessionid in the very 
last step, even though I managed to keep the URL unencoded all the way there...

So, I think the solution from the wiki isn't feasible for me, or am I missing 
something?

However, I'm still curious how I should make a shared resource redirect 
somewhere, getting back to the API documentation.

Cheers,

Michael


-------- Original-Nachricht --------
> Datum: Wed, 22 Feb 2012 08:46:05 -0500
> Von: Jeff Schneller <j...@mootus.com>
> An: "users@wicket.apache.org" <users@wicket.apache.org>
> Betreff: Re: Redirect to external page without jsessionid in referrer

> So my last message got off.  
> 
> This will force a new session on every request of the page since the
> jsessionid is not in url and cookies are not being accepted by the browser.  
> 
> I would look at the wiki entry and see if that is what you are looking
> for.  
> 
> -- 
> Jeff Schneller
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> 
> 
> On Wednesday, February 22, 2012 at 8:31 AM, Jeff Schneller wrote:
> 
> > If all you want to do is remove the jsessionid from the URL there is a
> wiki entry on how to do this. It is under SEO optimization. This will force
> a new session on every 
> > 
> > Sent from my iPhone
> > 
> > On Feb 22, 2012, at 8:00 AM, geissb...@gmx.org
> (mailto:geissb...@gmx.org) wrote:
> > 
> > > Hi folks,
> > > 
> > > I'm struggling with the documentation of ExternalLink (applies for
> both 1.4 and 1.5):
> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/markup/html/link/ExternalLink.html
> > > 
> > > I.e. especially with this paragraph:
> > > 
> > > "Note: in the case when the support for cookies in the browser is
> disabled the user's jsessionid will leak in the 'Referrer' header after
> clicking this link. If this is a problem for the application then better use a
> Link which redirects to a shared resource (see
> WebApplication#mountResource(String, 
> org.apache.wicket.request.resource.ResourceReference) , e.g.
> "/myapp/redirecting-resource?url=...") which on its side redirects to the new 
> URL
> using RedirectToUrlException. Another option is to use rel="noreferrer"
> attribute in your markup but this will work only in the modern browsers
> (supporting HTML5 standard)."
> > > 
> > > For several internal reasons which can't be discussed here, the
> jsessionid has to be contained in the URL and I want to achieve exactly what 
> is
> described in the documentation: have a somewhat generic referrer which
> doesn't contain the jsessionid. But honestly, I am totally confused by the
> description. How could I mount something which is able to throw a
> RedirectToUrlException, i.e. something backed by Java logic, as a resource? 
> As far as I
> understand the concept of shared resources they are always things like
> images, CSS, etc., but not pages or something similar.
> > > 
> > > Both creating a link to a shared a resource and throwing a
> RedirectToUrlException in the request cycle are fine by themselves, but I 
> just can't
> see how to connect these two steps. Thus, I would be very pleased if someone
> could give me a hint on how to manage this.
> > > 
> > > Thanks! :-)
> > > 
> > > Cheers,
> > > 
> > > Michael
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> (mailto:users-unsubscr...@wicket.apache.org)
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> (mailto:users-h...@wicket.apache.org)
> > > 
> > 
> > 
> > 
> 
> 

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

Reply via email to