开发者

Wrong sessionID being used in callback, but only on one particular computer

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:

  • logging in with a different account, including new accounts that have never OAuthed to this app before
  • Clearing cookies, using incognito mode, using a different web browser on my same computer. Each time, upon inspecting my cookies, the sessionID matched the sessionID in the login function and was different from the sessionID in the callback.
  • deleting t开发者_运维百科he session in the database that appears in the callback function, (the one that appeared to be old data). The callback function still fails, and the sessionID it appears to be using is now a new one
  • using a different session backend (DB-cache, flat file, etc...)
  • restarting the server, my computer, etc.

    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.

  • 0

    上一篇:

    下一篇:

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    最新问答

    问答排行榜