I was doing some analysis on a grails application and i noticed two cookies being sent by browser to server everytime. If i understand correctly one session id should be enough to implement sessions in a web application but i am wondering why are two session ids being used instead of one. The cookie looks as follows:
JSESSIONID=4206209230A211D7D45DF1124B2E08C1; session-id=37663030303130312D353235342D313339652D383235372D363464386133343030303032
I apprecaite any help! Thanks!
The JSESSIONID is generated from the servlet-container like jetty or tomcat or the builtin if you run a grails app standalone.
The session-id is generated from the used http-server like apache, etc.
I assume, you run the grails application behind an apache/http-server proxy?
If you access the servlet-container directly, only the JSESSIONID cookie is send.
Related
I am running spring applications in a JBOSS server inside a test machine. My application does some calls, for example it requires to access a webseal server which is not available in this machine, so I need to simulate its response by injecting the corresponding webseal http headers. I don't know where to start nor if you need more information to propose a solution.
Depend if your app wanna be a Client for webseal, or wanna be a Backend app for webseal. If your app is a client, only recibe a Cookie with your Session ID. If your app is a Backend for web-seal(you are behind of a junction) you need recibe HTTP Headers "iv-user" and "iv-creds", this example help you to understand iv-creds:
JSP Example - get Header Credentials Webseals
I have a Spring MVC App and I have an issue with invalidated sessions.
The app performs AJAX requests that are all authenticated/tied to a session (hold a JSESSIONID)
So here's what happens. Let's say I'm in the app authenticated with a session. If I go into Tomcat and invalidate that session, then the next time an HTTP request gets made, Spring forwards me to the login page. Once I login again, Spring authenticates me fine, but then a number of my AJAX requests get HTTP 403 errors, continuously.
If I go into the HTTP Headers of the requests that get the 403s, I notice they have 2 JSESSIONIDs, one of the authenticated session, the other one of a session that holds only this attribute:
SPRING_SECURITY_SAVED_REQUEST DefaultSavedRequest[<OLD URL>]
So these sessions are not authenticated sessions so they are causing Spring to return a 403.
The issue is that this persists until I kill the browser (on some mobile devices that doesn't even work, and I have to go into settings to clear the browser cache).
Any suggestions?
this is a big problem because it's happening when Sessions invalidate themselves because of TTL, and we're stuck with users who get booted out, log back in and still get 403s, forever, until they clear the cache.
One thing to note is that Spring Security invalidates the existing session when you login and creates a new one, copying the contents of the old one across. This is intended to create a new session identifier to avoid session fixation attacks. You can try disabling this feature to see if it is related to your problem. It sounds like these are the two sessions you are talking about.
However if there are two JSESSIONID headers in the request then it sounds like a problem on the client side. You should work out why your client is sending two values. Also, it sounds like there may be an issue with Tomcat on the server side if you are still able to read the contents of the previously invalidated session.
Also check that Tomcat isn't sending two JSESSIONID values in the login response. There was an issue ages ago where it was doing just that, but it's unlikely you are running such an old version of Tomcat.
Hi I have 2 wars on same machine. Let's say warA and warB.
When user is in /warA I have the sessionId of the same user in /warB. And i want to kill this session.
My aim is if user in /warA , i want to quarentee that the user session in /warB is killed.
Some can say write a servlet that kills /warB 's session and call it from /warA.
The reason i can't do this is, there is an agent(Oracle Access Manager) infront of /warB that do authentication part and don't let me call warB's servlet directly.
So is there any other way to do my job?
Edit:
I found this. Does OAM Agent breaks this request? Is it a simple request or a request between contexts?
servletContext.getContext("/warB").getRequestDispatcher("/logout");
If the two war files are deployed to the same WLS server, I believe this is the default behavior. WebLogic stored session id in the cookie named jsessionid, if you do not configure a different cookie name in the weblogic.xml. Thus if a user login war2, the jsessionid cookie from war1 will be overwritten and the session with war1 will not be maintained.
I have a web application running on JBoss server based on JSF framework.
I need to redirect my request to an entirely new web application running on some other server and on some other machine geographically located.
My doubt is if I redirect the request from my web page to another web application web page will it expose the session parameter at the other end.
I have some very critical information stored in the session and I cannot afford to expose the details to another web application..
Along with the redirect request I would be sending some parameters to the remote web application which will use these parameters for certain mathematical computation.
Can anyone guide me on this?
Is it possible for the other web application to see what is present in the session
No. That would have been a huge security hole throughout the current world wide web. Think about it once again, are you able to see what for example google.com and stackoverflow.com have in its session? No? Then the other web application definitely also can't. All which the web application can see from outside is the sole incoming HTTP request in its entirety.
This problem/question has at least nothing to do with JSF.
If you invalidate the session before the redirect then it doesn't matter if the external web application sees your session cookie. They couldn't turn around and emulate requests on your session anyway because the session is no longer valid.
request.getSession().invalidate();
I don't think this will be an issue though because I doubt that the request header to another web application would include the same session cookie.
is it possible to disable session cookies on tomcat just for some web-application url patterns?
All the examples i´ve seen so far disables sesssion cookies for the entire web application, via configuration on context.xml.
Just for contextualization,in my scenario I have a BLAZEDS polling channel that I´d like to have cookies ignored.
TKS.
The easiest way I know of would be to create a Page Filter to remove the session cookie for those url patterns as the request comes in.