I have multiple Django dev sites running locally like http://localhost:8000, http://localhost:8001, http://localhost:8002, etc.
Originally, I had SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN set to '' or 127.0.0.1 but this causes each site to overwrite the other's cookies, causing me to have to login every time I switch between sites. I tried using 127.0.0.1:<port> but that had no effect.
How do I get these sites to use separate cookies?
One solution to this problem is to use local domain name resolution to reach each of your different development servers. If you leave SESSION_COOKIE_DOMAIN as None, then the returned cookie is a standard domain cookie and will have the same domain as the request.
Have a look at http://en.wikipedia.org/wiki/Hosts_(file) which describes how to add local host file entries.
With a hosts file like this:
127.0.0.1 www.testserver1.com www.testserver2.com
You could then access each of your different test servers at:
http://www.testserver1.com:8000
http://www.testserver2.com:8001
I haven't tried this, but I believe it should work.
Alternatively, as per Mikhail's answer, use a different session cookie name for each instance.
Cookies are shared across ports for the same domain according to various RFCs (see e.g. https://www.rfc-editor.org/rfc/rfc6265#section-8.5). So this is not django-specific.
I think you could use different SESSION_COOKIE_NAME to have at least sessions separated.
Related
I a making a web application with a session cookie log in system. When using the cookies they expire within seconds, logging the user out of any service they were in. When I open my app I occasionaly get a warning in the terminal that states UserWarning: The session cookie domain is an IP address. This may not work as intended in some browsers. Add an entry to your hosts file, for example "localhost.localdomain", and use that instead. I'm hosting this app on Heroku so I don't think editing my local file would help, but if theres a way to get this to be solved on Heroku that would be great. Another error message I get comes from the console in the website itself, which reads:
Cookie “session” will be soon rejected because it has the “SameSite” attribute set to “None”
or an invalid value, without the “secure” attribute. To know more about the “SameSite“
attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
I set the Session cookie in my web application to:
app.config["SESSION_FILE_DIR"] = tempfile.mkdtemp()
app.config["SESSION_PERMANENT"] = False
app.config["SESSION_TYPE"] = "filesystem"
app.config["SESSION_COOKIE_SECURE"] = True
app.config["SESSION_COOKIE_SAMESITE"] = "None"
Session(app)
But this didn't solve my problem and both errors keep coming up. If there's any way to manually set SameSite and Secure that would be fantastic. Getting a https connection on Heroku did not work, I don't know why this is happening and it breaks the site, if there's any advice anyone has that would be greatly appreciated!
You need to use a domain name to access the service (https://domain.xxx/) and not the IP-address (https://123.123.123.213).
To avoid a lot of pain and errors, you should aim to use HTTPS, especially if you want cookies to work properly. Both the Secure and SameSite attributes requires HTTPS to work properly in most cases. And to get HTTPS to work you need a domain name and a proper certificate.
If I set ALLOWED_HOSTS = ['*'] I am able to make a succesfull call, however this seems dangerous and counterintuitive.
When I set ALLOWED_HOSTS to the recommended string, it fails. How to fix this?
Since you've tagged your post with AWS, I assume the host in question is an AWS EC2 instance. If so, try put in your EC2 private IP or your full domain instead, like:
['ip-XX-XX-XX-XX.XX-XXX-X.compute.internal']
OR
['.yourdomain.com']
The preceding . in your domain name represents a wildcard, as described in Django's docs
I encountered this and found the reason. There were 2 different tabs which were running server. For test reasons I just started server in another tab. Django doesn't warn in the second tab. So your requests are most probably falling to the another tab running the server.
tl;dr: Python newbie, Django's session not propagated correctly while using HTTPS
I'm building a basic web service which rely on session/cookies to authentication an user.
During the first authentication, I configure a specific session like this:
request.session['userSecureId'] = "blabla"
return HttpResponseRedirect('http://localhost/secure',context)
At this point, a new session key has been added to django_session table. A basic b64 decode on the session_data field confirm the presence of 'userSecureId'
On my view, I check if this session exist like this:
if request.session.get('userSecureId'):
# do something
If I try this on my local system (plain HTTP), it works great. So my next step was to run it on my remote server with SSL enabled. I've configured
SESSION_COOKIE_SECURE = True on my settings.py but now, the value returned by 'userSecureId' is always None.
This is probably a newbie question, so any pointer will be appreciated =)
Additionally, If I print request.session.session_key I'm able to successfully retrieve the session key, meaning Django correctly detect my sessionid cookie, but can't decode the content of session_value
EDIT: I just tried accessing Django on my remote system (same configuration) and I'm facing the same issue. I have no idea why I can't run the session value. Code works using 127.0.0.1 w/o problem though
According to here and here
To share a session between HTTP and HTTPS (and cross domain also), you should set SESSION_COOKIE_DOMAIN in your settings.
SESSION_COOKIE_DOMAIN = '.example.com'
In my python script, I am fetching pages but I already know the IP of the server.
So I could save it the hassle of doing a DNS lookup, if I can some how pass in the IP and hostname in the request.
So, if I call
http://111.111.111.111/
and then pass the hostname in the HOST attribute, I should be OK. However the issue I see is on the server side, if the user looks at the incomming request (ie REQUEST_URI) then they will see I went for the IP.
Anyone have any ideas?
First, the main idea is suspicious. Well, you can "know" IP of the server but this knowledge is temporary and its correctness time is controlled by DNS TTLs. For stable configuration, server admin can provide DNS record with long TTL (e.g. a few days) so DNS request will be always fulfilled using the nearest caching resolver or nscd. For changing configuration, TTL can be reduced to a few seconds or ever to 0 (means no caching), and it can be useful for some kind of load balancers. You try to organize your own resolver cache which is TTL ignorant, and this can lead to requests to non-functioning or wrong servers, with incorrect contents. So, I suggest not to do this.
If you are strictly sure you shall do this and you can't use external tools as custom resolver or even /etc/hosts, try to install custom "opener" (see urllib2.build_opener() function in documentation) which overrides DNS lookup. However I didn't do this ever, the knowledge is only on documentation read just now.
You can add the ip address mapping to the hosts file.
I want my Python script to access a URL through an IP specified in the script instead of through the default DNS for the domain. Basically I want the equivalent of adding an entry to my /etc/hosts file, but I want the change to apply only to my script instead of globally on the whole server. Any ideas?
Whether this works or not will depend on whether the far end site is using HTTP/1.1 named-based virtual hosting or not.
If they're not, you can simply replace the hostname part of the URL with their IP address, per #Greg's answer.
If they are, however, you have to ensure that the correct Host: header is sent as part of the HTTP request. Without that, a virtual hosting web server won't know which site's content to give you. Refer to your HTTP client API (Curl?) to see if you can add or change default request headers.
You can use an explicit IP number to connect to a specific machine by embedding that into the URL: http://127.0.0.1/index.html is equivalent to http://localhost/index.html
That said, it isn't a good idea to use IP numbers instead of DNS entries. IPs change a lot more often than DNS entries, meaning your script has a greater chance of breaking if you hard-code the address instead of letting it resolve normally.