I am writing a Python/Django web application that uses OAuth (for the TwitterAPI, not that it should matter).
I am storing a session ID in my login function, and then after using OAuth to get the user’s token, I try to retrieve the sessionID in my callback function. The callback function then always fails(throws an exception) because it can’t find the OAuth token in the session. Through the debugger, I am able to determine that the session ID that the server is using is incorrect – it does not match the session ID that was stored in the login function. It’s therefore unsurprising that the Oauth tokens were not there. The session that appears in the callback was the same one each time (until I tried deleting it – see “things I’ve tried below”), and it started out as an old session, with some data in it that is from a different django app running on the same server that I hadn’t touched in a couple weeks.
Here’s the kicker: everything I described is an issue only on our production server, and only when connecting to it from my computer. Let me clarify: this only happens with my particular laptop. I can connect to the app just fine from someone else’s computer. Other people cannot connect with their accounts on my computer. Furthmore, I can connect just fine to the app when it is running on my localhost using the built-in django webserver, just not to the production server.
My setup: my server and local box are running= Django 1.2.0 and Python 2.6.5. My local box is running Snow Leopard and the Django webserver, the server is running Ubuntu, Apache2, and mod-wsgi. For sessions, I am using Django’s default session backend (DB).
Things I have tried, all to no avail:
My first question on StackOverflow, so bear with me if I didn’t quite follow local conventions. I am just at a loss as to what to even look for – what are the things that could possibly be causing sessions to not work on my particular computer, and (so far!) only my particular computer?
EDIT: solved it, a few hours after posting this question, after struggling with this for a couple days!
The problem had nothing to do with my computer, and was caused by the person typing on it! Subconsciously, I was typing “www.our-domain.com”, and all of my coworkers have been typing “our-domain.com” the entire time. We didn’t have Apache rewrite rules in place, so at login, the session ID was being set in a cookie with the “www.” as part of the domain, but the redirect for the callback function had an associated url without the “www.”, so my browser was using two different cookies, which I somehow didn’t see until now (because the way I was searching for cookies also included the www!). Very simple, and should have thought of it earlier. Moral of the story: be careful about subdomains with your sessions.
Solved it, a few hours after posting this question, after struggling with this for a couple days!
The problem had nothing to do with my computer, and was caused by the person typing on it! Subconsciously, I was typing “www.our-domain.com”, and all of my coworkers have been typing “our-domain.com” the entire time. We didn’t have Apache rewrite rules in place, so at login, the session ID was being set in a cookie with the “www.” as part of the domain, but the redirect for the callback function had an associated url without the “www.”, so my browser was using two different cookies, which I somehow didn’t see until now (because the way I was searching for cookies also included the www!). Very simple, and should have thought of it earlier. Moral of the story: be careful about subdomains with your sessions.