I updated a test server from ColdFusion 10 to ColdFusion 11 30 days Enterprise trail edition with update 7.
However, every time I hit refresh in my browsers, I get a new cfid.
As a result, a valid session is not found so the login page doesn't work.
I checked the session in coldfusion admin page and my cookie in my browsers, they are both created correctly.
This is what I have in my application.cfm
<CFAPPLICATION NAME="TESTWEB"
CLIENTMANAGEMENT="Yes"
SETCLIENTCOOKIES="Yes"
SESSIONMANAGEMENT="Yes"
SESSIONTIMEOUT = "#CreateTimeSpan(7,0,0,0)#"
SETDOMAINCOOKIES = "No">
However, when I open the page from the host computer, then the cfid doesn't get change everytime I hit refresh, so everything works.
Any idea what can cause my problem?
EDIT:
During login, I had code that set cfid/cftoken to cookie, but since I changed to SETCLIENTCOOKIES="Yes", I removed those code. The only other place would be in logout.
I am not using jsessionids, only coldFusion session id.
Timeout for all session variables is 7 days.
I have switched to using JEE session by enabling it in the ColdFusion admin. My session is now working.
I know this is an old question, but I'll leave this here to help others in case they've tried everything mentioned above and are still having issues.
Check your Cookie Samesite value.
If you've upgrading old apps to newer CF servers, to prevent Coldfusion from changing CFID and CFTOKEN on refresh or when you make an AJAX call referencing sessions or cookie variables - along with all the recommended settings stated by others above, check to following:
To set Cookie Samesite value at server level for CF 2016, 2018:
In the Coldfusion Admin Settings, Server Settings > Memory Variables > Session Cookie Settings, Set the "Cookie Samesite default value" to "-" or "LAX" (LAX is default value when NULL)
To set Cookie Samesite value at site level: For ColdFusion (2018 release) Update 9 and ColdFusion (2016 release) Update 15
You may use the cfcookie tag.
For those on CF11 or older CF versions, you may set your response headers in IIS or Apache. I am assuming people with this issue (cfid and cftoken changing on refresh) is because they made a change to the samesite attribute and broke something. In that case, review how you've implemented SameSite Cookies and what you set that value to.
SameSite Cookies with IIS
SameSite cookies with Apache
I am running Coldfusion 10 Update 14 (10,0,14,291717).
Is it normal for the jsessionid cookie to be set when the "Use J2EE session variables" option is unchecked in the cfadmin.
It is being set in the response from a page that is posted to using a form with enctype set to multipart/form-data. It seems to happen with any form in our application if I change the enctype. That is the only time I see it being set. There could be other conditions that cause it to be set, but I haven't found any. It doesn't happen if the form has no enctype set. It also doesn't happen for get requests.
Should this cookie ever be set if the option is unchecked in the cfadmin?
Is it normal for it to only be set with this particular type of post request?
This happens on my development machine Mac OSX 10.9.5 and on our production server running Windows Server and IIS.
These are the response headers from the page that sets the cookie. The page does some form processing and then does a cflocation.
HTTP/1.1 302 Found
Date: Wed, 10 Dec 2014 20:42:21 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_jk/1.2.32 mod_ssl/2.2.26 OpenSSL/0.9.8za
Set-Cookie: JSESSIONID=A61590143D1AD60644B208F25990F8FA.cfusion; Path=/; HttpOnly
Location: http://localhost/ethm/maintenanceForm/mrformv7/main.cfm?pid=home&BID=1995
Cache-Control: no-cache
Pragma: no-cache
Keep-Alive: timeout=5, max=49
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8
More Information:
I updated my development cf to update 15 so the version is now 10,0,15,292620.
I created a new folder in my local site and put the following 2 files in the folder:
Application.cfc
component{
}
index.cfm
<form enctype="multipart/form-data" method="post" action="index.cfm">
<input type="submit" value="Go">
</form>
Then if I clear my cookies and go to that page I get no new cookies. If I submit the form I get a JSessionID cookie. I can clear it and I get a new one every time I submit the form. If I don't clear my cookies the same one stays.
We tested this for you Mat (Wil Genovese) on CF10 UPdate 15. According to Wil CF does not set J2EE session cookeies if they are disabled in the CF Admin. However if an existing j2ee session cookie exists from when they were anabled it will persist until it expires. Hopefully that helps a little.
FYI - this was not on OSX.
EDIT: More information
Further testing revealed the following Matt.
When you issue a POST using multipart/form-data this condition (a J2EE cookie set) will always occur. If you change your POST header to /application/x-www-form-urlencoded it will not be set. And a GET request will not allow it to be set.
Using this Application.cfc (adding or subtracting settings and names):
component
{
THIS.name = "je22test";
THIS.Sessionmanagement = true;
THIS.ApplicationTimeout = CreateTimeSpan(1,0,0,0);
THIS.SessionTimeout = createtimespan(0,0,20,0);
THIS.SetClientCookies = false;
}
...does not appear to have any effect. We are going to log it as a bug. I'm not sure the impact exactly. It might red flag a security scan - but you really should use rotating J2EE sessions anyway. Still, a scan might notice that it only rotates on a POST request. It would see it, then flag it (as an info warning probably) for not rotating. Not sure that's enough of a bug to fix or worry about, but lets see what Adobe says eh?
I just searched through the Adobe ColdFusion bug base and found this bug report
https://bugbase.adobe.com/index.cfm?event=bug&id=3430245
This is related to what we are seeing (if not the exact same thing) and it was "fixed" in CF10u14 and CF11u3.
However, I can verify the results you're getting, as Mark already posted, in CF10. So after I found the bug report I went and tested this in CF11u3 and found that with J2EE Session variables turned off CF11u3 always sets the jsessionid cookie.
I created a new bug report with my findings and linked to the old bug report and this forum page. However, I made the mistake of tagging it as a 'security bug' because session cookies not being properly set is technically a security issue and now it's not visible to anyone including me. That will teach me.
Regards,
Wil Genovese
Sr. Web Application Developer/
Systems Administrator
CF Webtools
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?
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.