Opened 17 years ago
Closed 14 years ago
#7183 closed (duplicate)
sessionid broken by jsession
Reported by: | mbeattie | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Keywords: | wsgi session | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I was trying to use a django setup on a machine that used to have a j2ee setup and whenever I tried to use any of the session
functionality it would give an error saying that the key I was looking for wasn't found. I figured out that the problem is
for some reason once a particular jsessionid is set, firefox will hold on to it forever for that host and always send it as
part of the HTTP_COOKIE. The way to fix it is to clear the cookies for that host. I am not too sure what the real cause of
this is or what belongs in HTTP_COOKIE, but I found a way to make it go away by modifying wsgi.py. It seems that django only
cares about the sessionid part of that header so that's all I grabbed. Someone more knowledgeable about why this happens
might have something better.
13a14 > import re 147c148,153 < self._cookies = http.parse_cookie(self.environ.get('HTTP_COOKIE', '')) --- > cookiestring = self.environ.get('HTTP_COOKIE', '') > sessionfind = re.search("(sessionid=[0-9a-f]*)", cookiestring) > if sessionfind == None: > self._cookies = http.parse_cookie(cookiestring) > else: > self._cookies = http.parse_cookie(sessionfind.groups()[0])
Attachments (1)
Change History (8)
by , 17 years ago
Attachment: | wsgipatch.txt added |
---|
comment:1 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 16 years ago
Description: | modified (diff) |
---|
comment:3 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I firmly believe that this is not a bug in django but simply a wrong setup where the web server somehow fiddles with the session cookie. Simply use a different cookie name.
comment:4 by , 16 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
I executed the following sequence of actions with following results:
- Open local django instance in browser: sessionid cookie set.
- Log in to admin interface of django instance: successful. cookie unchanged.
- Log out of admin interface of django instance: successful. cookie unchanged.
- Open local J2EE admin interface login page in browser: JSESSIONID cookie set. sessionid cookie unchanged.
- Log in to admin interface of django instance: successful. cookies unchanged.
- Log out of admin interface of django instance: successful. cookies unchanged.
- Log in to J2EE admin interface: successful. cookie "form:tree-hi" set. JSESSIONID and sessionid unchanged.
- Log in to admin interface of django instance: fail. sessionid is set to a new value.
- Log in to admin interface of django instance: fail. sessionid is set to a new value.
- Delete JSESSIONID cookie, reload django admin login page: sessionid is set to a new value.
- Log in to admin interface of django instance: fail. sessionid is set to a new value.
- Delete "form:tree-hi" cookie, reload django admin login page: sessionid is unchanged.
- Log in to admin interface of django instance: successful. sessionid is unchanged.
I conclude that django has an issue with the "form:tree-hi" cookie. Issues with the ':' in the cookie name?
Django SVN r8074, Firefox 3, Glassfish J2EE server, cookies tracked using Firefox's Cookie browser.
comment:5 by , 16 years ago
milestone: | → post-1.0 |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
Triage Stage: | Accepted → Design decision needed |
Thanks for digging this up!
According to rfcs 2965 and 2616, the cookie name is a token
and cannot contain colons. This is why the standard python Cookie library does not accept cookie names with a colon in them, and it barfs if you feed it a http header line with an illegal cookie.
It might make still sense to treat this better, so I put this into the stage "Design decision needed" to let the core developers decide.
The patch is not very useful because it assumes a given session cookie name and is a bit naive.
comment:7 by , 14 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
The original cause of the problem is the colon in the cookie name. This problem is discussed at length is #13007.
my patch