I am noticing strange behaviour with my ColdFusion session cookies whereby the domain, path and httponly attributes are not retained.
In my application.cfc file I have this.setclientcookies set to false.
In my onSessionStart event I then have the following code:
<cfset sessionRotate()>
<cfcookie name="CFID" value="#session.cfid#" path="#application.sessioncookiespath#" domain="#application.sessioncookiesdomain#" httponly="yes">
<cfcookie name="CFTOKEN" value="#session.cftoken#" path="#application.sessioncookiespath#" domain="#application.sessioncookiesdomain#" httponly="yes">
The first time I visit a page the CFID and CFTOKEN cookies get sent to the browser with the correct values, domains, paths expiry dates etc.
But when viewing the request cookies for subsequent requests everything but the value of the cookie has been lost.
If I then close the browser, reopen it and go to a page the same cookies are sent to the server and so I get the same session, instead of the expected behaviour of the browser deleting the cookies when closed.
Can anybody shed any light on this?
Thanks.
In response to Sean.
Response cookies returned on initial request to www.domainname.com/sub are:
Set Cookie CFID=123456; Domain=.domainname.com; Expires=Fri, 07-Feb-2014 15:12:33 GMT; Path=/sub; HttpOnly
Set Cookie CFTOKEN=2cf168a89952feec%2D4DAC5903%2D1DD8%2DB71C%2D3B0166C2FDAF5D6B; Domain=.domainname.com; Expires=Fri, 07-Feb-2014 15:12:33 GMT; Path=/sub; HttpOnly
Subsequent requests to any other page (any page at the same level or deeper than the /sub directory) or the same page (i.e. refreshing the page) send the following request cookie string:
CFID=191297; CFTOKEN=2cf168a89952feec%2D4DAC5903%2D1DD8%2DB71C%2D0B0166C2FDAF5D6D; ASP.NET_SessionId=s43bplyduc0hkgintth4gcqh
It's a CF10 bug, fixed, but not available.
https://bugbase.adobe.com/index.cfm?event=bug&id=3593673
Related
I have a parent webpage with a child iframe:
parent at https://first-site.com
child at <iframe src="https://second-site.com"> (inside of parent)
cookie is set by the second-site.com server upon page load using this HTTP header:
Set-Cookie: iqsession=869194b8e575d0d333f9395557f564f5eca31c15761c; expires=Wed, 08-Feb-2023 03:51:14 GMT; Max-Age=600; path=/; secure; httponly; samesite=none
When I load the page on first-site.com (with second-site.com in an iframe), Firefox fails to store the cookie for second-site.com. It's not accessible under the cookies tab, nor is it available to second-site.com on subsequent page loads. There are no warnings or errors in the console.
This does work in Chrome.
Note that I am not attempting to access cookies across domains. The cookie is only set by second-site.com on the server side and only read by second-site.com on the server side. The outer parent doesn't need to know anything about the cookie.
Any ideas why this isn't working in Firefox? This issue looks related but isn't super clear.
I have a web application that uses jQuery.ajax to perform a request to another host (right now actually the same because I'm using different ports of "localhost"). The server then returns a cookie.
The cookie value in the HTTP response as shown in Chrome's Dev Tools is
Set-Cookie: MyUserSession=JxQoyzYm1VfESmuh-v22wyiyLREyOkuQWauziTrimjKo=;expires=Sun, 10 Feb 2013 22:08:47 GMT;path=/api/rest/
and so has an expiry of 4 hours in the future.
However, the cookie does not get stored and sent with subsequent requests (tested in both Chrome and Firefox). I first thought it must be "10-Feb-2013" instead of "10 Feb 2013" but that doesn't make a difference. Chrome also shows "Expires" as "Invalid date" on the cookies tab of the response, but that might as well be a Dev Tools bug.
Any ideas?
I think I found the solution. Since during development, my server is at "localhost:30002" and my web app at "localhost:8003", they are considered different hosts regarding CORS. Therefore, all my requests to the server are covered by CORS security rules, especially Requests with credentials. "Credentials" include cookies as noted on that link, so the returned cookie was not accepted because I did not pass
xhrFields: {
withCredentials: true
}
to jQuery's $.ajax function. I also have to pass that option to subsequent CORS requests in order to send the cookie.
I added the header Access-Control-Allow-Credentials: true on the server side and changed the Access-Control-Allow-Origin header from wildcard to http://localhost:8003 (port number is significant!). That solution now works for me and the cookie gets stored.
After struggling with a similar scenario (no CORS) for hours, I found out another potential reason: be sure to explicitly set the path for the cookie.
My front-end app was making a call to HOST_URL/api/members/login, and this was returning the right Set-Cookie header, with no path.
I could see the cookie under Response Cookies in Chrome DevTools, but subsequent requests were not including it. Went to chrome://settings/cookies, and the cookie was there, but the path was /api/members.
Specifying root path when setting the cookie at server-side fixed the issue.
where do you get the date from?
if you add it manually try making it failproof
var exdays = 3; //3 days valid as an example
var exdate=new Date();
exdate.setDate(exdate.getDate() + exdays);
//Now set the cookie to said exdate
document.cookie = "MyUserSession =" + escape(JxQoyzYm1VfESmuh-v22wyiyLREyOkuQWauziTrimjKo=)+"; expires="+exdate.toUTCString());
Am setting Cookie using below code,
document.cookie = name+"="+value+ ";expires="+"domain=xyz.com;path=/";
And session expiration time set in my server is 15mins. If client is idle for 15 mins,
after 15 mins, session will be destroyed. Will this destroy the value set in my Cookie?
I mean, is cookie expiration set in document.cookie related to cookie expiration set in the server?
I think the answer really depends on how the browser handles cookie expirations.
When the server sends the HTTP response, the client (browser) will look for any Set-Cookie headers on the response. If found, it will override the cookies stored on the browser.
Quoting from Persistent Client State HTTP Cookies:
The expires header lets the client know when it is safe to purge the mapping but the client is not required to do so. A client may also delete a cookie before it's expiration date arrives if the number of cookies exceeds its internal limits.
Also, check this:
If a CGI script wishes to delete a cookie, it can do so by returning a cookie with the same name, and an expires time which is in the past. The path and name must match exactly in order for the expiring cookie to replace the valid cookie. This requirement makes it difficult for anyone but the originator of a cookie to delete a cookie.
It means that if the web server automatically sends you a response with the Set-Cookie header, it will override the cookie you manually set.
Related:
http://www.superuser.com/questions/356265/what-do-browsers-do-with-expired-cookies
http://www.stackoverflow.com/questions/1635909/how-do-i-remove-delete-expire-a-cookie-immediately
If cookie is destroyed, then the data also will be desroyed.
I'm porting a client-side library for an API from JSONP to CORS.
I have set all the correct headers in the server and done all the indicated things in the client, but I have a problem regarding cookies.
That API auth method works with cookies. With JSONP, it made a GET request to the API with the API key as a parameter. Then the server set a cookie at api.io.holalabs.com (API URL), so the next time it does a call to the API the server requests the cookie and make the login.
The problem is that, although I see Set-Cookie in the headers, the cookie is not set at api.io.holalabs.com so the login fails.
These are my headers:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:http://holalabs.com
Access-Control-Expose-Headers:X-Api-Version, X-Request-Id, X-Response-Time
Connection:close
Content-Length:13
Content-MD5:RjkY1fW5i5MKifxPk+r4tg==
Content-Type:application/json
Date:Fri, 13 Apr 2012 16:06:56 GMT
Server:nginx/1.0.14
Set-Cookie:apikey.sig=DYyrzLFUfJSjsmK5crkxHQg-rxQ; path=/; httponly
X-Api-Version:1.0.0
X-Request-Id:c78b4223-1caf-42db-a99e-b075bdc10ea5
X-Response-Time:2
EDIT: Using cookies in a API is a horrible idea, so now we are using a header to auth the user. Issue closed!
Issue is supposedly closed, but if anyone encounters this problem and need to use cookies, here's one possible explanation and solution:
Explanation
The session ID is sent as a cookie, and since the request is cross-domain, it's considered a third party cookie by the browser. Several browsers will block third-party cookies, and the session is lost.
Solution
Generate the session ID on the client (in the browser), use Javascript sessionStorage to store the session ID then send the session ID with each request to the server.
(Details: Javascript Cross-Domain Request With Session)
I am interested to see what people are storing in my session and cookies when I visit websites. Is there any way to see what's in there between request and when I'm on pages in Safari, Chrome, or Firefox?
In Firefox you can use among others Firebug to check the cookies being sent forth and back. Check the Net panel for complete request and response headers. The cookies are present as Set-Cookie response header whenever the session starts and as Cookie request header on all subsequent requests in the same session.
Here's a screenshot of the transferred headers when requesting this topic:
(note that I removed the user cookie value from the screenshot, else someone else would be able to copy it and login as myself)
You cannot check in the client side in any way what's been stored in the server side session since that's usually not exposed in the cookie values. Only the session identifier is stored as cookie value. You can at highest make some guesses based on the behaviour of the website across the requests.