Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Servlet
-
Labels:None
-
Testcase included:yes
-
Patch Submitted:Yes
-
Number of attachments :
Description
When a browser first hits our app, say "/context", our app redirects them to "/context/search.htm".
However, because this is the first request, no session cookie was coming in, so the URL gets encoded with it, e.g. "/context/search.htm?jsessionid=x".
URL encoding the jsessionid might make sense for browsers with cookies turned off, but in the same response that has the redirect url "...?jsessionid=x" there is a Set-Cookie header with "jsessionid=x" in it as well.
Because the browser is already being told what the session id is via the cookie, I think it is redundant to encode it in the URL. Plus we have some users complaining about it.
So, I've attached a patch that short circuits jessionid url encoding at the same place it does the "is cookie in request" check by adding a "is cooking in response" check as well.
This seems to work pretty well. Let me know if my logic is flawed here or I'm missing something.
Otherwise, I'd appreciate the patch being applied. Refactoring it as needed would be appreciated as well--I wasn't sure about the best practice way to do this, and so just guessed at what would work.
Hm. Well, thinking about it, I can see why you are sending the session id in both the query string and the cookie--because you don't know if the browser will accept the cookie or not.
Nonetheless, this jsessionid in the query string bothers people using our app, making them think their session is insecure. I'll look around some more for best practice on keeping jsessionid from getting into the url. Pointers would be appreciated.