Opened 7 years ago

Closed 4 years ago

#7183 closed (duplicate)

sessionid broken by jsession

Reported by: mbeattie Owned by: nobody
Component: HTTP handling Version: master
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: UI/UX:

Description (last modified by ramiro)

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 7 years ago.
my patch

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by mbeattie

my patch

comment:1 Changed 7 years ago by Simon Greenhill

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 7 years ago by ramiro

  • Description modified (diff)

comment:3 Changed 7 years ago by mir

  • Resolution set to invalid
  • Status changed from new to 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 Changed 7 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to 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 Changed 7 years ago by mir

  • milestone set to post-1.0
  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Accepted to 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:6 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:7 Changed 4 years ago by aaugustin

  • Resolution set to duplicate
  • Status changed from reopened to closed

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