We use Flex and BlazeDS and we faced a peculiar issue.
BlazeDS is used in my Flex application context to collect information from multiple IP's. Whenever the flex application tries to collect the information from the same server (webservice hosted on port 5002) the https session ID of main application gets overridden by flex session ID.
My main J2EE web application and Flex application runs on https on 5000 port.
Here while making a SOAP call, if the host in the endpoint URI is set to the same server IP (localhost/loopback IP/fully Qualified Domain Name) then the HTTP session gets reset.
The flex application I am referring to resides under JBoss Application server 4.2.3 GA. Whenever the above SOAP call is made from this sub web application the whole HTTP session of the server gets overridden.
And once the JSESSIONID gets overridden by Flex web applications JSESSIONID, my main web application becomes useless since I am internally tracking session management via web applications JSESSIONID.
Application Server: JBoss 4.2.3 GA
I also tried to verify this use-case by using BlazeDS 3.2 and found out that my application is working.
Gist of the scenario:
1.My Flex module is child web application used by main web application, and this flex application collects various information via SOAP call and displays them on UI.
2. Here multiple web applications are present and one of them is Flex web application, and all web applications are hosted on port 5000. Ex: https://localhost:5000/flexapp/app.swf
3. Whenever flex application makes a web service hoisted on the same server on port 5002 then the main webapplication (that is containing this flex web application) HTTP Session ID is updated to what is used by Flex application.
4. The same doesn't occur while SOAP connection is made to other server hosted on different IP's.
Could anyone please help me understand that what exactly is going wrong?
Thanks in advance.
Can you try and capture a log of the traffic between the client and the server using a traffic monitoring utility such as Charles? That should help show what the problem is.
If I had to guess, I would say that maybe the path of the session cookies for both web applications is the same and that is why the HTTP session is getting reset.
I found a thread that would seem to indicate that in JBoss 4.2.3.GA the path is set to “/” which means that the browser might try to use the same session cookie for both web applications.
You might check and see if there is a way to include the context-root for the web application in the session cookie path. That might resolve the problem.
I am from Arunav's team.
I used Charles and I do not see anything in the "Error Log".
I would also like to tell you that we do not face this issue if we use BlazeDS 3.2. So if everything remains the same and I just move back to BlazeDS 3.2 from BlazeDS 4.0.1. I do not come across this issue. The moment we use BlazeDS 4.0.1 we get this issue.
Also would you be able to let me know how BlazeDS does session management.
Are you using the proxy service in BlazeDS?
It could be that there was some change in behavior with how cookies are handled by the proxy service between BlazeDS 3.2 and BlazeDS 4.0.1. That's just a guess though. It would be hard for me to say for sure without looking at a Charles log.
BlazeDS for the most part lets the application server handle session management. When the MessageBrokerServlet receives a request a new session is created if one doesn't exist already. There is also some code to do URL rewriting of session ids which is needed in case the client doesn't support cookies or has disabled them. There is also a setting that allows the HTTP session to get invalidated when a disconnect message is received from the Flex client.
Another thing is that each Flex application is represented on the server by a FlexClient object. This FlexClient object gets tied to the HTTP session. If the server receives a request where the FlexClient ID on the request is already associated with another HTTP session, the HTTP session will get invalidated. You would know if this was happening though because you'd be getting duplicate session detected errors.
That is mostly it I think and then some proxy service code which might pass cookies from the target server or service back to the client.
Hope that helps.
I debugged BlazeDS code and found out the piece of code that was causing this problem.
It is in RequestFilter.java. There is a section of code that says the following.
"If this is a session cookie and we're dealing with local domain, make sure the session cookie has the latest session id. This check is needed when the session was invalidated and then recreated in this request; we shouldn't be sending the old session id to the endpoint."
It is in this section that BlazeDS is over writing the main application JSESSIONID with the FLEX session id, if it is from local domain.
Can you please let me know why it is done this way?
This code was added because there were problems with stale session cookies being used if the session was invalidated during the request. I don't remember the details exactly. It looks like the code is assuming that the session cookie will be shared by the entire domain.
Here is an interesting post you may want to take a look at.
It sounds like even if the BlazeDS code could detect that the session cookie was for a different server (port) on the same machine and therefore didn't overwrite the cookie there may be problems with the browser keeping things straight. Your best bet might be to change one of your servers to use a different identifier for the session cookie, ie, something other than JSESSIONID.
It is not possible for us to change and use some other identifier for session cookie other than JSESSIONID.
In this section of code the developer checks for localDomain and session cookie identifier. If it is localDomain and session cookie identifier is JSESSIONID, he is over writing the JSESSIONID of all the cookies with the Flex session id. I feel there is some issue in this section of code. I feel the developer should check if the Flex session is invalidated and if so the Flex JSESSIONID should be over written with latest Flex session id and we should not over write JSESSIONID in other cookies.
I would like to know if there is a fix to this issue. If so when is the fix expected?
Also I noticed that this section of code was added after BlazeDS 3.2. Was this code added as part of the security vulnerability fix (I doubt though)?
In the worst case if I comment out this section of code in BlazeDS, what is the impact? Please elaborate.
If you think this isn’t working correctly, please log a bug.
Once you log a bug, I don’t have any insight as to when it will get fixed. I’m not working on the BlazeDS product any more.
This code wasn’t added to fix a security vulnerability.
If you remove the code, I don’t think it will cause any problems for you. I think it was added to fix a problem that could happen when BlazeDS and the web service were running in the same web application and that’s not the case for you.
If you do remove the code definitely make sure that it works for your situation though and doesn’t introduce any problems I haven’t anticipated.
We are also facing the same issue when we deployed our code in clustered environment.
Our environment is:
Application Server: Websphere 6.1, Clustered with 2 nodes.
We are having the swf file embedded in a Java struts web application. There is a link in the web app which launches the swf file and displays a dashboard. When we login to our app, a session (with Jsessionid) is created and we can browse through the app and access other links (except the link that launches the swf). Everything seems fine up till this. Once we click on the link that launches the swf file, we get an error for DuplicateSessionDetected in the log. Also, after this, when we click on any other link in the web app, it logs out the user from the app saying - the user session has expired.
When the swf loads, there are 2 BlazeDS calls happening. The first call is happening and returning the result. When making the second call, we get "DuplicateSessionDetected" error in the log.
We have checked the logs. Something like this happens -
1) When the user logs in to the app, a java session is created with valid jsession id.
2) We can click on any other links in the app and it works fine
3) Once we click on the link that launches the swf, there are 2 BlazeDS calls happening. The first call is happening and returning the result. When making the second call, we get "DuplicateSessionDetected" error in the log. It seems that BlazeDS is creating a new Flex session of its own and invalidates or overwrites the existing Http session.
4) After the error, when we click on any other link in the app, it logs out the user saying session has expired. That is, the new Flexsession created overwrites the existing Httpsession.
Can you please let me know -
1) Is there any way to prevent BlazeDs from creating a new Flexsession and force it to use the existing Httpsession? I tried to pass the jsessionid using flashvars to the swf and then appending the jsession id to endpoint URL. But that is giving an error. If this approach works, can you please let me know how exactly are we supposed to pass the jsession id from mxml so that a new session is not created.
2) The issue of overwriting the existing HttpsessionId with FlexSessionId seems to be similar to the one mentioned above. Is there any fix in BlazeDS 4.0 or the only option is to downgrade to 3.2?
3) Also, do we have to make any specific configuration changes/ settings for using BlazeDS in clustered environment? As this problem is not happening in our local environment, but when we deploy our code in clustered environment.
Any help would be greatly appreciated!
Also, would like to include here that I tried to download Blaze DS 3.2 (blazeds-bin-220.127.116.1178.zip) from the Adobe site. But, the download mirror site is giving the error - DNS name cannot be resolved for flexorg.wip3.adobe.com. Have tried with IE, Chrome etc. and it is the same error everywhere. Can you pls provide the link to site from where I can download Blaze DS 3.2 binary distribution. It is very urgent.