I must be missing some basic thing about cookies. On localhost, when I set a cookie on server side and specify the domain explicitly as localhost (or .localhost). the cookie does not seem to be accepted by some browsers.
Firefox 3.5: I checked the HTTP request in Firebug. What I see is:
Set-Cookie:
name=value;
domain=localhost;
expires=Thu, 16-Jul-2009 21:25:05 GMT;
path=/
or (when I set the domain to .localhost):
Set-Cookie:
name=value;
domain=.localhost;
expires=Thu, 16-Jul-2009 21:25:05 GMT;
path=/
In either case, the cookie is not stored.
IE8: I did not use any extra tool, but the cookie does not seem to be stored as well, because it’s not being sent back in subsequent requests.
Opera 9.64: Both localhost and .localhost work, but when I check the list of cookies in Preferences, the domain is set to localhost.local even though it’s listed under localhost (in the list grouping).
Safari 4: Both localhost and .localhost work, but they are always listed as .localhost in Preferences. On the other hand, a cookie without an explicit domain, it being shown as just localhost (no dot).
What is the problem with localhost? Because of such a number of inconsistencies, there must be some special rules involving localhost. Also, it’s not completely clear to me why domains must be prefixed by a dot? RFC 2109 explicitly states that:
The value for the Domain attribute
contains no embedded dots or does not
start with a dot.
Why? The document indicates that it has to do something with security. I have to admit that I have not read the entire specification (may do it later), but it sounds a bit strange. Based on this, setting cookies on localhost would be impossible.
By design, domain names must have at least two dots; otherwise the browser will consider them invalid. (See reference on http://curl.haxx.se/rfc/cookie_spec.html)
When working on localhost, the cookie domain must be omitted entirely. You should not set it to "" or NULL or FALSE instead of "localhost". It is not enough.
For PHP, see comments on http://php.net/manual/en/function.setcookie.php#73107.
If working with the Java Servlet API, don't call the cookie.setDomain("...") method at all.
I broadly agree with #Ralph Buchfelder, but here's some amplification of this, by experiment when trying to replicate a system with several subdomains (such as example.com, fr.example.com, de.example.com) on my local machine (OS X / Apache / Chrome|Firefox).
I've edited /etc/hosts to point some imaginary subdomains at 127.0.0.1:
127.0.0.1 localexample.com
127.0.0.1 fr.localexample.com
127.0.0.1 de.localexample.com
If I am working on fr.localexample.com and I leave the domain parameter out, the cookie is stored correctly for fr.localexample.com, but is not visible in the other subdomains.
If I use a domain of ".localexample.com", the cookie is stored correctly for fr.localexample.com, and is visible in other subdomains.
If I use a domain of "localexample.com", or when I was trying a domain of just "localexample" or "localhost", the cookie was not getting stored.
If I use a domain of "fr.localexample.com" or ".fr.localexample.com", the cookie is stored correctly for fr.localexample.com and is (correctly) invisible in other subdomains.
So the requirement that you need at least two dots in the domain appears to be correct, even though I can't see why it should be.
If anyone wants to try this out, here's some useful code:
<html>
<head>
<title>
Testing cookies
</title>
</head>
<body>
<?php
header('HTTP/1.0 200');
$domain = 'fr.localexample.com'; // Change this to the domain you want to test.
if (!empty($_GET['v'])) {
$val = $_GET['v'];
print "Setting cookie to $val<br/>";
setcookie("mycookie", $val, time() + 48 * 3600, '/', $domain);
}
print "<pre>";
print "Cookie:<br/>";
var_dump($_COOKIE);
print "Server:<br/>";
var_dump($_SERVER);
print "</pre>";
?>
</body>
</html>
localhost: You can use: domain: ".app.localhost" and it will work. The 'domain' parameter needs 1 or more dots in the domain name for setting cookies. Then you can have sessions working across localhost subdomains such as: api.app.localhost:3000.
When a cookie is set with an explicit domain of 'localhost' as follows...
Set-Cookie: name=value;
domain=localhost; expires=Thu, 16-Jul-2009 21:25:05 GMT; path=/
...then browsers ignore it because it does not include at least two periods and is not one of seven specially handled, top level domains.
...domains must have at least two (2) or three (3) periods in them to
prevent domains of the form: ".com", ".edu", and "va.us". Any domain
that fails within one of the seven special top level domains listed
below only require two periods. Any other domain requires at least
three. The seven special top level domains are: "COM", "EDU", "NET",
"ORG", "GOV", "MIL", and "INT".
Note that the number of periods above probably assumes that a leading period is required. This period is however ignored in modern browsers and it should probably read...
at least one (1) or two (2) periods
Note that the default value for the domain attribute is the host name of the server which generated the cookie response.
So a workaround for cookies not being set for localhost is to simply not specify a domain attribute and let the browser use the default value - this does not appear to have the same constraints that an explicit value in the domain attribute does.
Cross sites cookies problem I solved like this:
Backend
Server side
serving on: http://localhost:8080
when creating a response, set Cookie
attributes:
SameSite=None; Secure; Path=/
Client side
Frontend (in my case Angular)
serving on: http://localhost:4200/
when sending request to Server (backend)
set XHR.withCredentials=true:
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://localhost:8080/', true);
xhr.withCredentials = true;
xhr.send(null);
My interpretation:
when backend and frontend domains differ the decision if the cookies will be saved in frontend domain cookie storage from received response is brought by the browser. Browser will allow sending cookies ONLY if XHR request has withCredentials=true and correct server Cookie attributes (HTTP Set-Cookie header) are recieved
when backend and frontend domains differ the decision if the cookies will be sent within request is brought by the browser. Browser will allow this ONLY if XHR request has withCredentials=true
in other words, if withCredentials=true is ommited - cookies won't be sent within request NOR will be recieved and saved from response
recieved cookies are allways stored under frontend domain name in browser cookie storage. In case when server domain differs and cookies are saved successfully, the effect is the same as if they have been sent by frontend domain in the first place.
if SameSite=None cookie attribute is omitted today's browser (Firefox/Chrome) will use default Lax mode which is too strict for cross site cookies
if Secured cookie attribute is ommited - then SameSite=None will be ignored - it requires Secured to be set
for localhost Secured cookie property browser does not require HTTPS / SSL, http will work - no need to serve frontend or backend under https://localhost ...
EDIT 2022-03-02 - For Safari (v15.1) this is not true -> in Safari http://localhost + cookie with Secure - the cookie will be ignored, not saved in browser (solution: for Safari + http://localhost remove Secure and SameSite if provided).
EDIT 2023-01-13 - #Barnaby reported that "Firefox refuses to set it: 'has been rejected because a non-HTTPS cookie can’t be set as “secure”.'" If this is the case - solution as for Safari should work (see EDIT 2022-03-02 above).
Hints for diagnostics:
in order to check if the cookies are sent - open browser developer tools and check Network tab. Find the request to backend and check Headers - search for Cookie header in Request headers, and Set-Cookie in Response headers
in order to check if the cookies are saved - open browsers developer tools, see Storage manager (Firefox), check Cookies and search for frontend domain name, check if the cookie exists and if does, check when it was created ...
don't forget to set CORS on backend first
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
If you're setting a cookie from another domain (ie you set the cookie by making an XHR cross origin request), then you need to make sure you set the withCredentials attribute to true on the XMLHttpRequest you use to fetch the cookie as described here
I had much better luck testing locally using 127.0.0.1 as the domain. I'm not sure why, but I had mixed results with localhost and .localhost, etc.
Results I had varied by browser.
Chrome- 127.0.0.1 worked but localhost .localhost and "" did not.
Firefox- .localhost worked but localhost, 127.0.0.1, and "" did not.
Have not tested in Opera, IE, or Safari
Spent a great deal of time troubleshooting this issue myself.
Using PHP, and Nothing on this page worked for me. I eventually realized in my code that the 'secure' parameter to PHP's session_set_cookie_params() was always being set to TRUE.
Since I wasn't visiting localhost with https my browser would never accept the cookie. So, I modified that portion of my code to conditionally set the 'secure' param based on $_SERVER['HTTP_HOST'] being 'localhost' or not. Working well now.
I hope this helps someone.
you can make use of localhost.org or rather .localhost.org it will always resolve to 127.0.0.1
The only thing that worked for me was to set Path=/ on the cookie.
Moreover, the default value of a path attribute seems to be different from browsers to browsers although I tested only two of them (Firefox and Chrome).
Chrome tries to set a cookie as is; if path attribute is omitted in Set-Cookie header then it will not be stored and ignored.
However, Firefox stores a cookie even without an explicit path attribute. It just set it with the requested path; my request url was /api/v1/users and the path was set to /api/v1 automatically.
Anyway, both browsers worked when path was set to / even without an explicit domain, ie Domain=localhost or something. So there are some differences in the way how each browser handles cookies.
None of the suggested fixes worked for me - setting it to null, false, adding two dots, etc - didn't work.
In the end, I just removed the domain from the cookie if it is localhost and that now works for me in Chrome 38.
Previous code (did not work):
document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
New code (now working):
if(document.domain === 'localhost') {
document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';path=/;' ;
} else {
document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
}
There seems to be an issue when you use https://<local-domain> and then http://<local-domain>. The http:// site does not send cookies with requests after https:// site sets them. Force reload and clear cache doesn't help. Only manual clearing of cookies works. Also, if I clear them on the https:// page, then http:// page starts working again.
Looks to be related to "Strict secure cookies". Good explanation here. It was released in Chrome 58 on 2017-04-19.
It looks like Chrome does in fact record both secure cookies and non-secure cookies as it will show the correct cookies depending on the page's protocol when clicking the address bar icon.
But Developer tools > Application > Cookies will not show a non-secure cookie when there is a secure cookie of the same name for the same domain, nor will it send the non-secure cookie with any requests. This seems like a Chrome bug, or if this behavior is expected, there should be some way to view the secure cookies when on a http page and an indication that they are being overridden.
Workaround is to use different named cookies depending on if they are for an http site or https site, and to name them specific to your app. A __Secure- prefix indicates that the cookie should be strictly secure, and is also a good practice because secure and non-secure won't collide. There are other benefits to prefixes too.
Using different /etc/hosts domains for https vs. http access would work too, but one accidental https://localhost visit will prevent any cookies of the same names to work on http://localhost sites - so this is not a good workaround.
I have filed a Chrome bug report.
After much experimentation and reading various posts, this worked. I could set multiple cookies, read them back and set the time negative and delete them.
func addCookie(w http.ResponseWriter, name string, value string) {
expire := time.Now().AddDate(0, 0, 1)
cookie := http.Cookie{
Name: name,
Value: value,
Expires: expire,
Domain: ".localhost",
Path: "/",
}
http.SetCookie(w, &cookie)
}
Cookie needs to specify SameSite attribute, None value used to be the default, but recent browser versions made Lax the default value to have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
Along with SameSite=Lax you should also have Domain=localhost, so your cookie will be associated to localhost and kept. It should look something like this:
document.cookie = `${name}=${value}${expires}; Path=/; Domain=localhost; SameSite=Lax`;
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
There is an issue on Chromium open since 2011, that if you are explicitly setting the domain as 'localhost', you should set it as false or undefined.
I had the same issue and I fixed it by putting 2 dots in the cookie name itself without specifying any domain.
set-cookie: name.s1.s2=value; path=/; expires=Sun, 12 Aug 2018 14:28:43 GMT; HttpOnly
Tried all of the options above. What worked for me was:
Make sure the request to server have withCredentials set to true. XMLHttpRequest from a different domain cannot set cookie values for their own domain unless withCredentials is set to true before making the request.
Do not set Domain
Set Path=/
Resulting Set-Cookie header:
Set-Cookie: session_token=74528588-7c48-4546-a3ae-4326e22449e5; Expires=Sun, 16 Aug 2020 04:40:42 GMT; Path=/
I had a similar problem where my backend and frontend were running on localhost but different ports. To fix this I omitted the Domain in the Set-Cookie and used withCredentials: true in my request options.
see here
document.cookie = valuename + "=" + value + "; " + expires + ";domain=;path=/";
this "domain=;path=/"; will take dynamic domain as its cookie will work in subdomain.
if u want to test in localhost it will work
None of the answers here worked for me. I fixed it by putting my PHP as the very very first thing in the page.
Like other headers, cookies must be sent before any output from your script (this is a protocol restriction). This requires that you place calls to this function prior to any output, including and tags as well as any whitespace.
From http://php.net/manual/en/function.setcookie.php
I was playing around a bit.
Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=localhost; Path=/
works in Firefox and Chrome as of today. However, I did not find a way to make it work with curl. I tried Host-Header and --resolve, no luck, any help appreciated.
However, it works in curl, if I set it to
Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=127.0.0.1; Path=/
instead. (Which does not work with Firefox.)
Another important detail, the expires= should use the following date time format: Wdy, DD-Mon-YYYY HH:MM:SS GMT (RFC6265 - Section 4.1.1).
Set-Cookie:
name=value;
domain=localhost;
expires=Thu, 16-07-2019 21:25:05 GMT;
path=/
If anyone is still facing this, I found that switching from a post request to a get request was needed.
I was using axios, and withCredentials: true on the frontend, but this was failing. Switching the request to get and changing my backend to match worked.
Related
We have an Angular app that makes a request to a resource on another domain (a headless cms api). The flow is as follows:
Spartacus=Angular, OCC=Java backend, Episerver=.Net backend
Call nr 10 looks like this:
getExternalCmsAuthCookie(jwt: string): Observable<any> {
const url = `${this.episerverBaseUrl}/externalauth`;
const requestOptions = {
headers: new HttpHeaders({
Authorization: 'Bearer ' + jwt
}),
withCredentials: true
};
return this.http.post(url, {}, requestOptions);
}
The in the server response we see the header
Set-Cookie: role-token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1NzUxMTE0OTQsInJvbGVzIjpbIkFwaUNvbnN1bWVycyIsIlBhcnRuZXJQb3J0YWxVc2VycyJdLCJ1c2VySWQiOiI4Nzk2MDk0NzkxNjg0In0.Mbvwe5qPIGSvUS-sFzxzPq7PAMed3LJaVeP8hK7eHQI; expires=Sat, 30 Nov 2019 10:58:15 GMT; domain=api.ourepiserver.com; path=/;SameSite=None; secure; httponly
After that all requests to the cms include the cookie and are let through by the server that sends some cms content back. This content can include tags pointing to episerver. This is the reason we need the cookie beause we can't add any custom http headers to resources the browser is downloading through tags.
This is working in all browsers except Safari. There are some duplicate questions (but not as elaborately explaind) but none seems to have any good answers.
Versions of Safari on MacOS 10.14 and iOS 12 have a bug where they will erroneously treat cookies marked with SameSite=None as if they were marked SameSite=Strict. You may be hitting this issue if you are not on the most recent version.
Potentially, this is also just an ITP limitation if you're trying to set a cookie from a third-party domain that the user has never visited in a first-party context.
I would test this by sending a cookie without the SameSite=None attribute to see if it's passed by Safari. If it is, then this is probably a SameSite compatibility issue. If not, it's likely something else.
I'm also assuming your domains are genuinely different sites and not just different origins. e.g. img.example.com and api.example.com are still the same-site. example.com and service.elsewhere.api are cross-site.
If you're hitting SameSite compatibility, you can mitigate this by setting two versions of the cookie or using useragent sniffing. More details on https://web.dev/samesite-cookie-recipes.
I have an Identity Server (v4) on one server and a web application on a different server & domain. I only need windows authentication, and everything works fine with a redirect. However, I noticed that silent sign-in works if the cookie hasn't yet expired.
If the cookie has expired, a redirect is currently necessary which works fine. Unfortunately however, this would mean if there's data the user hasnt saved on the current screen they will loose it unless I implement a caching mechanism. Instead, I want to set a hidden iframe that simply navigates to the Identity Server, auto logs in if the user is inside the company infrastructure (which they always will be).
After hours of debugging I have found that while cookies are correctly sent from the iFrame, any that are SET don't seem to work - they are in chrome debugger as a response cookie, but are not sent along on the next redirect as request cookies and I dont know why.
On response:
Cookie Options: SameSite Lax, HTTP true, Secure true, Path /
Headers:
Content-Security-Policy: default-src 'self'; object-src 'none'; frame-src localhost:44388; frame-ancestors 'self'
https://localhost:44388/; sandbox allow-forms allow-same-origin
allow-scripts; base-uri 'self';
Persistent-Auth: true
Pragma: no-cache
Referrer-Policy: no-referrer
WWW-Authenticate: Negotiate oRswGaADCgEAoxIEEAEAAABJ+0p/zH0aeAAAAAA=
X-Content-Security-Policy: default-src 'self'; object-src 'none'; frame-src
**localhost:44388; frame-ancestors 'self' https://localhost:44388/; sandbox allow-forms allow-same-origin allow-scripts; base-uri 'self';
X-Content-Type-Options: nosniff
X-Frame-Options: ALLOW-FROM https://localhost:44388/
From August 2020 you have to set SameSite to None, and secure to True.
In php could be done with something like:
setcookie("variable", 1, time() + (86400), "/; SameSite=None; Secure");
In javascript will be similar after path option.
document.cookie="cookiename="+0+";Domain=.yourdomain.net; path=/; SameSite=None; Secure"
I was seeing this same behavior when my parent website is localhost and the frame is not localhost. Strangely, the cookie works fine when both the parent and frame are not localhost, even though they are also not the same domain. I used the SameSite "None" setting for the cookie that multiple comments recommended to get around this problem. It seems like it should work with either Strict or Lax, since the ajax queries I am making are from within the frame, which is technically the same site, but for some reason, having a different domain for the frame's parent is throwing it off (though only when the parent is localhost).
I found that this worked for me - setting SameSite as "None" - and some more info on what that means here.
It's all from the PHP manual, but the other answers here helped me find the solution.
Apparently, browsers no longer allow you to set whatever you want in an iframe, I was trying to handle a session in an iframe, loaded on a different domain and while doing that, I noticed that a different session was being created for the OTHER domain instead of what I was loading in the iframe. This seems to have fixed it. I am still testing but it's the first thing that worked since I started looking for a fix this morning.
To fix a similar issue -- authenticated site inside an iframe from a different hostname -- I had remove the SameSite attribute that I had set up.
Really there are three options for SameSite, from most strict to least: Strict, Lax, and "don't set it at all".
We have a simple service running in EC2. We are testing setting our cookies with domain ".amazonaws.com", but it's not working correctly.
The cookie and domain are being set:
Content-Length:62
Date:Tue, 15 Apr 2014 10:26:55 GMT
Server:Apache-Coyote/1.1
Set-Cookie:test=alfie; Domain=.mycompany.com; Expires=Sun, 27-Apr-2014 00:13:35 GMT; Path=/
Set-Cookie:test2=alfie; Domain=.amazonaws.com; Expires=Sun, 27-Apr-2014 00:13:35 GMT; Path=/
If we request using xxxx.yyyy.mycompany.com, the cookie appears in Resources (Chrome tools) and is resent on the next request.
However, if we request using host xxxx.yyyy.amazonaws.com, the response is the same but the cookie does not appear in Chrome tools and is not resent.
Removing the domain (so that cookie uses fully qualified hostname) works fine in both cases.
Clearly using .amazonaws.com as the domain is a Bad Idea, but it seems strange to me that it doesn't work, as it implies this restriction is being enforced by Chrome somehow (and other browsers - Firefox shows the same behaviour).
Or it is something else basic we are missing?!
Thanks, Alfie.
Yes. Browsers don't let you set cookies for what they consider to be top level domains, for example you can't set a cookie for .com.
There's not a hard and fast rule you can use for determining whether a domain is a top level domain - it's up to the registrar where they allow registrations, so you pretty much just have to create a list.
You can see the list of domains Firefox considers to be top level domains in the Firefox source code. Among other things there are a bunch of amazon related ones.
I am trying to mark the ASP session ID cookie as HttpOnly but can't seem to find a way to tell if it is working. The environment I am trying this in is as follows:
OS: Windows Server 2003
IIS: 6
ASP Version: ASP 3 (Classic ASP)
In order to mark the cookie as http only, I followed MS KB
As per our architect's suggestion, to test whether this works, a javascript document.cookie should not be able to read the ASPSESSIONID* cookie. My issue is that javascript:alert(document.cookie) still echoes the ASPSESSIONID* cookie, albeit it appears to be encrypted(?)
I also tried to do this via Response.AddHeader "Set-Cookie" but can't determine what value to give for this header to mark all the cookies OR AT LEAST the ASP Session ID cookie as HttpOnly.
Help!!!
Just came across this issue because of a "new" PCI compliance item. It's a bit clumsy but this seems to work:
<%
Dim AspSessionCookie
AspSessionCookie = Request.ServerVariables("HTTP_COOKIE")
If len(AspSessionCookie) > 0 Then
AspSessionCookie = "ASPSESSIONID" & Split(AspSessionCookie,"ASPSESSIONID")(1)
If InStr(1,AspSessionCookie,";") then
AspSessionCookie = Split(AspSessionCookie,";")(0)
End If
Response.AddHeader "Set-Cookie", AspSessionCookie & ";HttpOnly"
Else
Response.redirect(Request.ServerVariables("URL"))
End If
%>
You seem to be confused between SECURE and HTTPONLY
These are different. The MS KB article you refer to is for SECURE.
Setting a cookie SECURE will stop IIS/Browser sending the ASP Session ID over HTTP.
Setting a cookie HTTPONLY will stop script (javascript) from accessing the value in most browsers.
There is a very GOOD reason to set HTTPONLY on a sessionID cookie. It help prevent theft of the users sessionID cookie, which could lead to session hijacking. That is why major browsers have implemented it.
I don't think your architect is correct regarding accessing the cookie in javascript.
There is no reason to stop javascript running in your page from accessing the cookie any more than javascript accessing the rest of your data in the HTML.
The purpose of adding the secure qualifier to a cookie is to prevent it from being sent in an unsecure request.
Oridinarily cookies set when the client is connected using https will still be sent when requests are made to the same server using plain http. The marking a cookie with the secure qualifier when its Set indicates to the client that it should only be sent in subsequent requests if those requests are using https.
Hence to test your setting get yourself a copy of fiddler, with that running hit the server over https then in the same browser session hit the same location with just http. Fiddler should show the second request going to the server and there should not be an ASPSESSION cookie present.
I found a strange cookie problem on safari. If you surf to http://2much.ch you can enter with FF/IE and surf inside the site.
But if you use safari, you can enter only once; you can't surf inside the site. I found that Safari doesn't set the entered cookie, but FF/IE does.
What is wrong here?
It looks like you hit a Safari bug here; you are redirecting any visiting browser to /entry while setting the cookie at the same time, and Safari is ignoring the Set-Cookie header when encountering the 302 HTTP status:
$ curl -so /dev/null -D - http://4much.schnickschnack.info/
HTTP/1.1 302 Moved Temporarily
Server: nginx/0.7.61
Date: Sun, 19 Jul 2009 12:20:49 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Content-Length: 14260
Content-Language: de
Expires: Sat, 1 Jan 2000 00:00:00 GMT
Location: http://4much.schnickschnack.info/entry
Set-Cookie: colorstyle="bright"; Path=/; Expires=1248092449.12
Set-Cookie: _ZopeId="73230900A39w5NG7q4g"; Path=/
Technically, this would be a bug in Apple's Foundation Classes, I've found a WebKit bug that states this is the case.
I suppose the workaround is to set the cookie not in index_html but in entry instead.
In the intervening years since I first answered this question, this issue now appears solved, at least it was for Safari 6 when someone tested all major browsers for Set-Cookie support on 302 redirects in 2012.
A month ago, I ran into this issue. At first I thought it was a corrupted cookie jar as I could clean out the cookies and go.
However, it popped up again. This time I spent an hour going through it, watching what was sent, reviewing what safari sent back, and I found the problem.
In this case, I had an array of cookie values being sent to the browser after login prior to the redirect. The values looked something like 'user id', 'user full name', 'some other id', etc.
( yes, the id's are encrypted so no worries there )
My user full name was actually in a <lastname>, <firstname> format.
When safari was posting the cookie back to the server, everything after the comma after the lastname was dropped. It was only posting back values up to that point.
When i removed the comma the rest of the values started working just fine.
So it appears that if you send a cookie value that contains a comma, then safari doesn't properly escape that in it's internal storage. Which leads me to think that if they aren't properly escaping commas, then there are probably some security issues with safari's cookie handling code.
Incidentally, this was tested on Win 7 x64 with safari 4.0.5. Also I put up a web page at: http://cookietest.livelyconsulting.com/ which shows this exact problem.(I removed that test site)
IE, FF, and chrome all correctly set the cookie. safari does not.
Looks like this is no longer an issue. See http://blog.dubbelboer.com/2012/11/25/302-cookie.html
We've run into a very similar issue where Safari (v. 7.0.6) would ignore a cookie. The cookie header looked perfectly fine, almost identical to another cookie which was remembered.
It turned out that the culprit was the previous cookie header having a malformed expires value. Safari's handling of broken cookie headers is evidently not as robust as that of the other browsers.
I ran into same issue with Chrome. Chrome doesn't ignore the set-cookie header while you are redirecting, but you never know the order (set cookie first or redirect first). Here is something I have tried:
I have a website, which supports English and French. I implemented it (with php) this way:
localhost has a link to localhost/fr (which set-cookie to French and redirect to localhost). It works. (set cookie first)
localhost/path1 has a link to localhost/fr?return=/path1 (which set-cookie to French and redirect to localhost/path1). It doesn't work. (redirect first, the language didn't change)
localhost/path1 has a link to localhost/fr?return=www.google.com (which set-cookie to French and redirect to google). When I came back to my website again, it's in French. (which means set-cookie to French is not ignored, only executed after redirect)
Hope I make myself clear, English is a foreign language to me.
After a great deal of pain, I found out that Safari (15.3) actually does save and my cookie, but it never displayed in developer tools storage -> cookies, but it works fine.
Here's the cookie I create and return in a Netlify function.
const secureCookie = cookie.serialize('jwtToken', JSON.stringify(jwtToken), {
secure: process.env.CONTEXT !== 'dev',
domain: process.env.CONTEXT === 'dev' ? 'localhost' : '.domain.com',
httpOnly: true,
sameSite: true,
expires: new Date(Date.now() + (1000 * jwtToken.expires_in))
})
and netlify function return
return {
statusCode: 200,
headers: {
"Cache-Control": "no-cache",
},
multiValueHeaders: {
"Set-Cookie": [secureCookie],
},
body: JSON.stringify(body),
}