3001: Session cookies are stored imporperly
- ThirdParty
- Review Board
| mech*****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| June 14, 2013 |
What version are you running? 1.7.7.1 What's the URL of the page containing the problem? Review creation page What steps will reproduce the problem? 1. Create user account for the reviewboard, login, stay logged in. Do not close the tab with session while doing all other steps 2. Add another user account, do not login 3. Change the database for the system. 3.1 I'm not sure if this is required, but wait for some time. In my case there was a week delay between sessions. 4. Return to the session created on step 1. 5. Create new review. What is the expected output? Session is expired, the system asks for login, and password What do you see instead? Review is created under another account. The IDs in database are probably the same, but content differs. What operating system are you using? What browser? Debian 6.0, MySQL 5.1, browser-independent issue
Yep. From my experience I can guess that session cookies never expires. I mean, we've got session opened long ago, we've reconfigured the virtual host, and the only option left unchanged was the site name. Then user could proceed posting reviews, the system didn't ask him for credentials, and due to configuration changes he actually posted the review under the name of another user. I think you're storing cookies containing user id from the database. The database was changed, the id was changed, but the system was still allowing to use it. In lots of other systems you should re-enter your credentials after some time of idleness, but in reviewboard you're always signed in. This could lead to such a strange actions.
All session management is handled by Django. Short of duplicating all their work and rewriting it, there's not much we can do about cookies and how they map to user sessions in the database. We do have a 1 year expiration for cookies, and this is intentional. This is actually the first I've heard of someone not liking a long session :) We used to have shorter sessions, and it just annoyed people. We won't be changing back to that.
-
- NeedInfo + ThirdParty
Thank you for reply, I've got your point. The idea of too-long sessions is coming from the project security polices -- we have ldap-authorization in our project, so the password would expire six times during the cookie life. That's insecure, I think. But, anyway, if all other users are OK with these settings, I'm not insisting on fixing anything =)