Documentation to describe cross-domain caveat with SESSION_COOKIE_DOMAIN

[ryanisnan@…]

I recently ran into an issue with updating SESSION_COOKIE_DOMAIN on a production site.

I went from using the standard domain setting (None, default), to using a cross-domain setting (.example.com). The problem was that existing users who already had established cookies ran into authentication problems as soon as they tried to log in.

It seems that because of the change in the cookie domain, their browsers (noticed in FF 19 and IE 9) failed to update the cookies' domains, which left the client unable to log in, despite everything working on the server. The only current solution I found was to destroy the cookies locally (and via JS for my users).

For now, concerning this ticket, I have submitted a pull request to update the documentation to contain a small note about this caveat: ​https://github.com/django/django/pull/927

As an aside to this ticket, I chatted with FunkyBob in #django about a potential fix for this. Perhaps the server can be a bit more selective when analyzing incoming cookies from the client, and notice discrepancies in their domain setting. When one is detected, perhaps they can be updated on the client?

[FunkyBob]

My suggestion was a flag for the sessions middleware to enforce that the session cookie have a matching domain. However, I've not looked yet at how much detail on each cookie is easily available.

In such cases, if possible, solutions would include:
1) deleting the old cookie
2) 'promoting' the old cookie to the current settings
3) ignore the old cookie, and look only at 'correct' ones.

[Jacob]

Fixed in [20661d2].