I have my SvelteKit web app running on http://www.projectname.localhost:3000/, and a Django backend running on http://api.projectname.localhost:8000/. I have configured Django as such:
SESSION_COOKIE_SECURE = False
SESSION_COOKIE_DOMAIN = ".projectname.localhost"
When I make a login request from the frontend to the backend, there is a set-cookie header in the response with the correct session cookie:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://www.projectname.localhost:3000
Set-Cookie: session_id=some_value_here; Domain=.projectname.localhost; expires=Fri, 10 Mar 2023 13:43:56 GMT; HttpOnly; Max-Age=2592000; Path=/; SameSite=Lax
As far as I can see everything is perfectly fine and this should work, and yet the cookie isn't actually stored in Safari, and I am not logged in. However, it works fine in Chrome.
Any idea what might be causing the cookie to not be stored in Safari? What am I doing wrong?
Related
In my application, I added secure cookies and I deployed it to the remote server. However, when I do a request, I can see that there are 2 identical cookies (1 is AWSALB unsecure, 2 is AWSALBCORS secure):
set-cookie
AWSALB=J8Hw07Jy8ein8Hei2SOME_NUMBERSMiRhCvCtL+1psSOME_NUMBERS84qI2vb/lmSOME_NUMBERS61i/LWSOME_NUMBERSLK2/itJs7pSOME_NUMBERSqcE8Y2/D3C55sSOME_NUMBERSGQUzxBh; Expires=Fri, 15 Jan 2021 07:19:43 GMT; Path=/
set-cookie
AWSALBCORS=J8Hw07Jy8ein8Hei2SOME_NUMBERSMiRhCvCtL+1psSOME_NUMBERS84qI2vb/lmSOME_NUMBERS61i/LWSOME_NUMBERSLK2/itJs7pSOME_NUMBERSqcE8Y2/D3C55sSOME_NUMBERSGQUzxBh; Expires=Fri, 15 Jan 2021 07:19:43 GMT; Path=/; SameSite=None; Secure
I investigated it and found out that it is related to AWS Load balancer, but I am unable to further investigate. I do not want to see unsecure cookie in response header. How can I remove it? Where should I look into?
Browser is ignoring reponse cookies (csrftoken + seesionid). document.cookie() returns empty string and chrome developer tool shows this site has no cookies
How to solve this ?
FRONT : Angular 2 (localhost:4200)
Back : Django/DRF (localhost:8000)
Login route : [post] /login
Response header :
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://localhost:4200
Allow:POST, OPTIONS
Date:Wed, 05 Apr 2017 07:38:24 GMT
Server:WSGIServer/0.2 CPython/3.5.2
Set-Cookie:sessionid=d5v1mri12bniyvyqqt55ar8mfl9mr2jk; expires=Wed, 19-Apr-2017 07:38:24 GMT; HttpOnly; Max-Age=1209600; Path=/
Set-Cookie:csrftoken=5PcTF8aQ1O79gdrylZcGchnmKyRy6zwS3kL2jR5dY2CMdjPfEYyhkoJjOzsDZuvj; expires=Wed, 04-Apr-2018 07:38:24 GMT; Max-Age=31449600; Path=/
Vary:Accept, Cookie, Origin
X-Frame-Options:SAMEORIGIN
Request header :
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8,fr;q=0.6
Connection:keep-alive
Content-Length:51
content-type:application/json
Cookie:sessionid=d5v1mri12bniyvyqqt55ar8mfl9mr2jk; csrftoken=sml3uocRIeiB3KfHSnNkJXBJn3QAFN3p7lLtdvhrALgUwoVnfNjGM5PIy2L3UHls
Host:127.0.0.1:8000
Origin:http://localhost:4200
Referer:http://localhost:4200/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/56.0.2924.76 Chrome/56.0.2924.76 Safari/537.36
Cookies are not shared among different ports of a host (localhost in your case). The browser shows you content from localhost:4200, but the cookies are set to localhost:8000. They are correctly set and used, as can be seen in your second listing titled "Request header". So to see them in the browser, you would have to open a URL from localhost:8000. Even then the sessionid would not be listed in document.cookie(), because it's marked as "HttpOnly" (which means not available to JavaScript).
If you are use angular cli you could set proxy.
ng serve --proxy-config proxy.conf.json
sample of proxy.conf.json
{
"/api": {
"target": "http://localhost:3000",
"secure": false
}
}
Or local development use
https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi
I was taking a diff in the response header of wireshark traces of two applications and found that setting ACCOUNT_EMAIL_VERIFICATION = 'optional' in the settings.py changes the behaviour of the HTTP response cookie. It sets the csrf field in the cookie in the http header, which somehow fails my subsequent POST request as rest requests by giving me csrf validation failed error. Is this behaviour normal? Or am I supposed to do some other settings to change this. I am new to django.
Please go easy on me if it is something silly.
With ACCOUNT_EMAIL_VERIFICATION = 'optional'
Allow: POST, OPTIONS, HEAD\r\n
Vary: Accept, Cookie\r\n
Content-Type: application/json\r\n
X-Frame-Options: SAMEORIGIN\r\n
Set-Cookie: sessionid=5bp1r9cr167ice1kb8o1sjeo5i4yv05x; expires=Mon, 23-Mar-2015 18:52:12 GMT; httponly; Max-Age=1209600; Path=/\r\n
Set-Cookie: csrftoken=33tKW0NTfjdWZ4CNtpqK91BxEMniJECM; expires=Mon, 07-Mar-2016 18:52:12 GMT; Max-Age=31449600; Path=/\r\n
[truncated]Set-Cookie: messages="d113558d7ba4e1085f84fce405e0ad52e2d0442b$[[\"__json_message\"\0540\05425\054\"Successfully signed in as abhishek10.\"]\054[\"__json_message\"\0540\05425\054\"Successfully signed in as abhishek11.\"]\054[\
\r\n
With ACCOUNT_EMAIL_VERIFICATION = 'mandatory'
Allow: POST, OPTIONS, HEAD\r\n
Content-Type: application/json\r\n
X-Frame-Options: SAMEORIGIN\r\n
Vary: Accept, Cookie\r\n
Set-Cookie: sessionid=2k89iyebjvy4vqulqfiqntjaft2a2d68; expires=Mon, 23-Mar-2015 18:57:21 GMT; httponly; Max-Age=1209600; Path=/\r\n
\r\n
I have two subdomains, local-api.domain.com and local-web.domain.com
local-web.domain.com has a page (local-web.domain.com/test/authtest) that calls out via AJAX to a login service (local-api.domain.com/authentication/login) on local-api.domain.com. The login checks the user's posted credentials, and if they're valid then logs the user in via ASP.Net forms auth. Here is a sample raw response that comes back from the service:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Set-Cookie: token=dsaaflkdaflkxEfrLEUH2Bsfdsjfdksfjdsklfj; expires=Sat, 11 Jan 2014 00:16:04 GMT; domain=.domain.com; path=/; httponly
Access-Control-Allow-Origin: http://local-web.domain.com
Access-Control-Allow-Credentials: true
Set-Cookie: .ASPXAUTH=E18F1521FFF70FDFD60444F6EA791D28DDF1010F907D35DD13CDA7E2698CE9DCFB50A25853A5BCFEA0E21820A0760D8412D517548F59344EDDA052DD6D7BD7DDB1D47D011F2EFE3B58B6B2690B370D54C560FC6FA3B0990190E0CB8A8B4CC80BEA925CA928256C78C502E74444566785C95EDC399777B3CB0D2AAFFD219B3ED5; domain=.domain.com; path=/; HttpOnly
Set-Cookie: Visitor=acfbc21b-6259-4000-809d-7dbc72db8309; domain=.domain.com; expires=Sat, 10-Jan-2015 00:16:04 GMT; path=/; HttpOnly
Set-Cookie: Visit=78406825-adf1-4224-af57-0350136a5fc6; domain=.domain.com; path=/; HttpOnly
Set-Cookie: Culture=en; domain=.domain.com; expires=Sat, 10-Jan-2015 00:16:04 GMT; path=/; HttpOnly
Date: Fri, 10 Jan 2014 00:16:04 GMT
Content-Length: 122
{"token":"dsaaflkdaflkxEfrLEUH2Bsfdsjfdksfjdsklfj","firstName":"Steve","lastName":"Smith"}
However, when I reload the page; I find that the cookie that was set in the response is not there. Further investigation with Chrome Developer Tools finds that the cookie doesn't even get saved after the login response; even though there is a Set-Cookie header.
I'm not sure what I'm doing wrong here. Going by similar questions on the site and their responses; I believe I have everything set up properly for the cookie to be saved and resent across my subdomains. Been Googling for last hour but haven't found anything. Any ideas?
As reproduced on Charles Proxy application,
Replacing httponly with HttpOnly on the conflict cookie did work fine.
I think that's the issue.
i have a problem with the safari browser and our set-cookie.
Safari is ignoring our set-cookies completely while FF and IE accept and send the cookies.
The Cookie setting page is not a redirection, direct HTTP 200 with set-cookie.
Is there a special character or malformed set-cookie that causes Safari to ignore the cookies completely?
The following Cookies are sent:
CURL output:
Set-Cookie: ASP.NET_SessionId=rdmpn1b4eckozzjns0voon33; path=/
Set-Cookie: SHOPPERID=jZlotLr6HESiqoB/3F0brg==; expires=Wed, 28-Jul-2060 01:09:04 GMT;path=/
Set-Cookie: FVISIT=2010?N7??28??; expires=Wed, 28-Jul-2060 01:09:04 GMT; path=/
Set-Cookie: STOCKMCD=Direct=2010/07/28 10:09:04; expires=Tue, 26-Oct-2010 01:09:04 GMT; path=/
Safari Developer Tools:
Set-Cookie:ASP.NET_SessionId=xqf3eui1r2fce4e30ogh2145; path=/, SHOPPERID=C/lG3XGVPEa7QgGcsqt3yg==; expires=Wed, 28-Jul-2060 01:15:26 GMT; path=/, FVISIT=2010N728รบ; expires=Wed, 28-Jul-2060 01:15:26 GMT; path=/, STOCKMCD=Direct=2010/07/28 10:15:26; expires=Tue, 26-Oct-2010 01:15:26 GMT; path=/
With default privacy settings Safari rejects cookies from domains other than user visited. For example, if page from example.com contains resources from example.net, example.net is not allowed to set cookies.
Take a look at the answers to HTTP headers encoding/decoding in Java. It looks as if the Set-Cookie header being sent has an character without a valid encoding. It seems that IE and Firefox are less strict than Safari.