Multiple Sessions created per user?
June 3, 2011 at 3:29 pm #17962
We are using PrettyFaces, JSF2, Spring, Spring Webflow, & Spring Security, on GAE, and are having a strange issue with session creation. We are still looking at the problem, but an initial view, is that this is somehow related to PrettyFaces:
<pattern value="/" />
– redirects requests to the homepage, which is a Spring Webflow flow.
If we go directly to the flow, /z/home.do, the user session is created and initialised, all is good, and that’s it!
If we go to / (caught by PrettyFaces), then again the user session is created and initialised, but every resource request in home.xhtml (the home page in the flow) causes a new session to be created and initialised.
Regardless of which method (i.e. direct or via PF) is used to access the page, the resources are all referenced as /java.faces.resource/xxxx.xxx.do – so we don’t see this as part of the problem, as PF is not catching /java.faces.resource/xxxx.xxx.do
But this only happens on the first page the user hits, i.e. once this has happened, if they refresh the page, or navigate to (or type in) a new URL that is either handled directly, or caught by PrettyFaces, then everything goes back to normal (working properly).
Spring Webflows default action is to redirect the incoming request, to start the flow, but obviously this rewrites the URL, looks bad, and in our app, for more than aesthetics, can’t be used.
So we have turned off this action for a number of landing pages, and have noticed that where we allow Spring to start with a redirect (to the direct url with it’s executuion param), this issue does not happen when going to a Prettyfaces URL. This is ONLY happening on where we DON’T allow a redirect. (Probably the expected result for a redirect!)
But, as noted previously, it only happens when we go to those URLS via PrettyFaces, not if we go directly????
So at this point, we’re not sure *IF* this is a PrettyFaces issue, or something deeper in the Spring/JSF world, but either way it’s causing a MASSIVE issue.
Can anybody shed any light on *IF* this is something being caused by Prettyfaces – and if so, any idea how to fix?
Sorry for the “War & Peace” post, but feel the info is relevant.
Thanks in advance,
DaveJune 3, 2011 at 8:55 pm #21056
Are you getting more than two sessions or exactly two?
I suspect, that one cookie is set for the “/” path and one for the “/z/” path.
Also don’t wonder if you’re experiencing problems with Spring and JSF.. they
don’t give a fu%# about JSF.. I have a few bug reports open and unfixed for almost 3 years now.June 4, 2011 at 1:20 pm #21057
No, on the initial landing page, it is creating a session for EVERY resource request (on the home page, this means about 23 sessions on landing).
As I said, a very weird problem, if there are 8 resources, it creates 9 sessions (initial + , but once this has finished loading, regardless of what you navigate to, it never creates another session.
We’ve tried creating a landing page with NO resources, and it creates the initial session, and subsequent browsing does not create any more – regardless of pretty urls, or direct urls, for all subsequent requests.
But as said previously, this ONLY happens when the initial session is created via a pretty url.
All that said, we are now thinking (although still could be wrong), that this isn’t a PrettyFaces problem, as it only appears to happen when the user is either pre-authenticated by a google account, or has the ‘remember me’ cookie set.
So appears to be somehow related to Spring Security, with PrettyFaces urls.
The diagnosis continues……
DaveJune 4, 2011 at 10:10 pm #21058
how have you setup the spring security filter?
this sounds like its also mapping the /javax.resources.*June 8, 2011 at 8:06 am #21059
As per various examples, Spring security is set to operate against /* requests, as is the main Spring framework.
Within the MVC & Flow configuration files, we filter the resource requests to the spring resource handler, and yes, it would appear that Spring Security *IS* also part of the processing chain.
We’re going to change this, and see how that effects this issue – Will let you know!
You must be logged in to reply to this topic.