I'm seeing something mysterious with the SESSION_COOKIE_DOMAIN setting in django.
Normally, when I have this set to ".mydomain.net" it works fine. But occasionally cookies don't seem to be being set, because when I log in, I'm not remembered in the session and I become AnonymousUser when I get to the next page.
In these circumstances, if, I change my settings file so that SESSION_COOKIE_DOMAIN is now None or "", then the site behaviour returns to normal. If I change SESSION_COOKIE_DOMAIN back to mydomain, the problem returns.
Any ideas? Is this likely to be a silent failure in the settings? Or could it be something to do with my server configuration? Or the machine I'm accessing the site from?
In all likelihood, you are ending up with multiple sessionid cookies being sent. If you have a sessionid cookie with domain 'example.com' and another cookie with domain '.example.com', Django will test only one of those sessionid values. I am unsure of how Django decides which sessionid value to test for validity.
Check your cookies in your browser (in FF, Tools -> Options -> Privacy -> Something about cookies) and see if they are correctly set. Search for your domain, and see if you have the sessionid cookie is set.
It might be a browser issue as Paul suggests. However, I'd be tempted to do some HTTP analysis with Firebug or Live HTTP Headers in Firefox. Is it trying to set the cookie correctly?
Related
I'm encountering a strange behavior, and I'm not really sure if it is framework-related or not.
Anyway, for my Flask project I'm using flask-login to manage user authentication.
I noticed that when I'm logging in from domain.com and then I'm switching to www.domain.com, the user appears to be logged out.
If I'm switching back to domain.com the user appears to be logged in (as expected).
This behavior doesn't go both ways, which means that logging in on www.domain.com will keep me logged in on domain.com too.
I'm not sure if it's an issue with flask-login and how it sets the session cookies or if it's related with how cookies work and so on.
Maybe you could help me out on this one :)
I believe you have to set the domain on the cookie to be .domain.com instead of domain.com for the cookie to be available to all subdomains. See this StackOverflow Question for more details!
You need to include the following line to your config file.
http://flask.pocoo.org/docs/0.12/config/
SESSION_COOKIE_DOMAIN = '.domain.com'
I have a django app. That app has 2 main cookies that are returned from the server (csrftoken and sessionid). I set the SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE flags in my settings.py file to True, and if I examine the initial request to login to my app I see that both of those cookies have the "secure" flag set in the response from the server.
When I am examining cookies in my app, I notice there are "request cookies" and "response cookies". The "response cookies" are the ones that have their flags set. The request cookies do not.
My question: Is there some way to force "request cookies" to have their secure flag set? Is this even a security concern? My application traffic is over https, so all connections between the browser and the server will already be encrypted from that...
It doesn't really work that way ... The flags are only present in the Set-Cookie header (the response).
When the client (a browser) receives a Set-Cookie header, it will store the flags together with the cookie value, but only for its own usage (so that the browser itself can know when and where to send the cookie value if necessary).
The Cookie header (request) cannot contain flags; it is only a list of <cookie-name>=<cookie-value> pairs and when you (the server) receive them, you're not even guaranteed to have set them yourself.
That's because any application under the same domain name can set cookies for that said domain. For example, an application running on example.com/foo would be able to set a cookie for example.com/bar, or even for another.example.com.
However, excluding the possibility of really horrible browser bugs, you can be sure that if you set the "secure" flag for a cookie in your response, the receiving browser won't send it over a non-encrypted connection.
It's not really 100% guaranteed, but it's really the only option you have and the pretty much the whole web relies on browsers behaving properly, so you're not alone in that.
Sadly, that's just how cookies work. Read the official standard for them here if you're interested in learning more about them.
I have a public Django site which uses CSRF protection.
I have not set the CSRF_COOKIE_DOMAIN. My site uses subdomains.
Sometimes, a user ends up having a csrftoken cookie set on .toplevel.com as well as on sub.toplevel.com. This causes problems, as CSRF checking fails if the wrong cookie is used in the check.
I would like to set a CSRF_COOKIE_DOMAIN to .toplevel.com. However, I would also like to delete any csrftoken cookies for any *.toplevel.com subdomains. How would I do this?
If I do not delete the other cookies, I will just end up in the original situation of having two cookies with the same name on different domains, which causes issues.
I had a similar problem. The way I dealt with it is together with CSRF_COOKIE_DOMAIN I also changed the CSRF_COOKIE_NAME, making old "csrftoken" cookies obsolete.
Below, Chrome shows a cookie on current page by viewing Inspect->Resources->Cookies, but why is there nothing by reading "document.cookie".
#EDIT
The cookie is firstly returned from the server via Set-Cookie: JSESSIONID=01E9...; Path=/myUrl/.
It's intended to remove the cookie on the client but fails. Probably the trailing "/" of the cookie path has caused this nasty issue.
#EDIT 2
The "problematic" cookie is set to HttpOnly by the server, so client scripting can neither change, remove nor read it. This resource protecting your cookies explains the reasons. BTW, Chrome devtools can do nothing more than either view or clear it.
I have two pages on two different domains example1.blogspot.com (a Blogspot blog) and example2.com (my own domain, static page). Both pages contain an iframe which loads the same document from a third domain, example.org. The iframe's document contains a small JS web app which calls example.org via AJAX, one of the calls is a POST request and the server sets a cookie with the response.
Upon reloading the pages, the cookie on example1.com seems gone, i.e. jQuery's $.cookie() returns null. On example2.com, everything is fine. This happens only in IE7 - IE6, Safari and Firefox all behave as expected. What's wrong with IE7?
Thanks, Simon
edit:
Oh well, stupid me ;-) It looks like I have a race condition between some event handlers and a window.setTimeout call when deciding whether to check for cookies...sorry!
So if $.cookie() returns null, What does document.cookie show? Also have you taken a look in IE7's list of cookies to see if the cookie is actually there? Also check that PATH and DOMAIN settings on the cookie are correct.