Opened 16 years ago

Closed 13 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 Ramiro Morales)

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)

wsgipatch.txt (473 bytes ) - added by mbeattie 16 years ago.
my patch

Download all attachments as: .zip

Change History (8)

by mbeattie, 16 years ago

Attachment: wsgipatch.txt added

my patch

comment:1 by Simon Greenhill, 16 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Ramiro Morales, 16 years ago

Description: modified (diff)

comment:3 by Michael Radziej, 16 years ago

Resolution: invalid
Status: newclosed

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 anonymous, 16 years ago

Resolution: invalid
Status: closedreopened

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 Michael Radziej, 16 years ago

milestone: post-1.0
Needs tests: set
Patch needs improvement: set
Triage Stage: AcceptedDesign 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:6 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:7 by Aymeric Augustin, 13 years ago

Resolution: duplicate
Status: reopenedclosed

The original cause of the problem is the colon in the cookie name. This problem is discussed at length is #13007.

Note: See TracTickets for help on using tickets.
Back to Top