jsessionid is not added to resources if cookies are disabled by the server

2012-05-04 Thread geissbock
Hi Wicket fellows,

When I configure the container (either Jetty or Tomcat) to not support cookies, 
I expect the jsessionid to be added to all resource links in the page. However, 
with Wicket 1.5.5 this isn't the case, i.e. all URLs are lacking the jsessionid.

We are running our application in a setup with one active and one inactive 
Tomcat instance running in parallel behind a loadbalancer and an Apache. The 
requests are routed to the worker that is appended to the jsessionid, and if no 
worker can found it will be route to the currently active instance. This way 
you can keep sessions stable on a deactivated Tomcat if you deploy a new 
version to the inactive Tomcat and then switch it to be the active one.

Now this leads to a quite random behavior when it comes to resources. Let's say 
Tomcat A is active and Tomcat B is inactive. If I then deploy a new version of 
the application to B and switch (i.e. A is inactive, B is active), the users 
still logged in on A will get the resources served by B because the jsessionid 
is missing and the requests are thus routed to B as the active instance. This 
causes strange side effects concerning Javascript, CSS, mounted images etc.

In my opinion, this is a bug. I have found a few issues regarding this topic, 
e.g. https://issues.apache.org/jira/browse/WICKET-4334 and 
https://issues.apache.org/jira/browse/WICKET-4312. But even if WICKET-4312 
seems to say that everything should work as before, I doubt that ;-)

Could someone please verify that I'm not missing some configuration or 
anything? I created a quickstart do demonstrate the behavior - please see the 
attached file. The file jetty-web.xml tells Jetty to not support cookies, so it 
can be run with mvn jetty:run without any further configuration.

By the way, I found a suggestion to use a custom IResourceCachingStrategy to 
append the jsessionid (or whatever) to URLs of resources in the archive of this 
list. Unfortunately, this doesn't work because the URL is encoded afterwards 
and the ; is turned into %3B :-(

Any help is very much appreciated :-)

Cheers,

Michael


jsessionid.tar.gz
Description: GNU Zip compressed data

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

Re: Redirect to external page without jsessionid in referrer

2012-02-28 Thread geissbock
Hi,

just to complete this topic: I finally found a solution that's working for all 
browsers our application needs to support.

As we are already tracking the browser of the user anyway, it was easy to build 
a server-side switch. If the browser is Chrome I simply use an ExternalLink and 
use an AttributeAppender to add rel=noreferrer to the a. Unfortunately, all 
other modern browsers don't support this HTML5 attribute, yet.

So, if the browser is anything else I redirect the user to a page which is 
basically empty except for a meta refresh in the header. In this case, neither 
Firefox nor IE nor Opera add a referrer header to the request, thus the 
jsessionid is hidden from the destination. Dealing with the drawbacks of a meta 
refresh (back button etc.) is irrelevant in my case as the links are opened in 
a new tab/window anyway.

Cheers,

Michael


 Original-Nachricht 
 Datum: Thu, 23 Feb 2012 16:33:46 +0100
 Von: geissb...@gmx.org
 An: users@wicket.apache.org
 Betreff: Re: Redirect to external page without jsessionid in referrer

 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)

   
   
   
  
  
 
 

Re: Redirect to external page without jsessionid in referrer

2012-02-23 Thread geissbock
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



Redirect to external page without jsessionid in referrer

2012-02-22 Thread geissbock
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
For additional commands, e-mail: users-h...@wicket.apache.org



Job opportunity in Germany

2011-12-26 Thread geissbock
Hi folks,

The department I work at as an architect is currently looking for a talented 
Wicket developer.

We're a company with 5,000 employees located in the south-west of Germany. The 
position is permanent and full-time, and it is required to work on-site, i.e. 
it is currently not possible to work on a contract or remote basis. A good 
command of the German language is definitely a plus, but being a great 
developer is certainly more important ;-)

We are currently developing two new e-commerce/online marketing products with 
Wicket which are about to be launched in the next months. These (and other) 
products will also be enhanced after their launch, which is why we are 
currently setting up cross-functional Scrum teams to be the think tanks in 
these areas.

So, if you are interested or know anyone who might be interested please feel 
free to get in touch with me and I will be glad to tell you some more details.

Cheers,

Michael

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



Re: [1.5]Current number of users (sessions) in a wicket app

2010-10-26 Thread geissbock
Hi Nino,

 Or if I still need to make my own HttpSessionListener for this?

Why don't you just turn on the RequestLogger like this:

Application.getRequestLoggerSettings().setRequestLoggerEnabled(true)

Then you can get quite some information about the current sessions, see the 
interface IRequestLogger for this.

Or is there a catch about the RequestLogger that I am missing? Performance 
maybe?

Cheers,

Michael

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



Job(s) for Wicket developers

2010-06-22 Thread geissbock
Hi,

The company I work at currently has two open permanent positions for 
middleware/frontend developers in my team. A sound knowledge of Javascript, CSS 
etc. is a must-have, and Wicket experience is a big plus as current and future 
projects are developed with Wicket.

We are located in the southwest of Germany and it is necessary to work on-site. 
If you are interested or know anyone who might be interested please feel free 
to get in touch with me and I will tell you some more details.

By the way, I'm one of the developers you would work with, not an HR guy or 
something ;-)

Cheers,

Michael

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



Looking for an experienced Wicket developer in Germany

2010-03-19 Thread geissbock
Hi,

My company is currently looking for an experienced Wicket developer. Three new 
products will be developed from scratch, so there is a lot of room for your 
talent and creativity :-) We offer a contract for (at least) three months here 
in Germany.

If you are interested or know anyone who might be interested please get in 
touch with me and I will tell you some more details.

And no, I'm neither a headhunter nor from the HR department - I'm just one of 
the developers you would work with. ;-)

Cheers,

Michael

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