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.
Related
I have JMeter test where after one request in response headers is set cookie with Max-Age property.
In following requests I am sending cookie in request body.
After Max-Age time pass I expect that jmeter stops sending cookie in request body. But it stil sends cookie.
I am using HTTP Cookie Manager with Cookie policy: standard-strict
Am I using HTTP Cookie Manager right?
How Cookie Manager handles Max-Age parameter in set-cookie in response header?
HTTP Cookie Manager doesn't send anything in the request body, it automatically parses incoming cookies and generates appropriate Cookie header
Looking into JMeter source code STANDARD_STRICT policy stands for RFC6265CookieSpecProvider with STRICT compatibility level
In its turn RFC6265CookieSpecProvider in STRICT mode invokes BasicMaxAgeHandler
So given you have HttpClient4 implementation of your HTTP Request sampler(s) (or even better in HTTP Request Defaults) the Max-Age check functionality should work (unless there is a bug in the HTTPClient itself)
I listed all cookies with preprocessor and cookie has set expires property to 12:43:12 and current time is 12:45:35 (current time is in milliseconds) ... so it seems that cookie with expires property does not work
PreProcessor: Cookie n° 2: sticky_fo: http://10.64.128.238:30701 expires: 1611146592 Current time: 1611146735233
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());
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)
Can an AJAX response set a cookie? If not, what is my alternative solution? Should I set it with Javascript or something similar?
According to the w3 spec section 4.6.3 for XMLHttpRequest a user agent should honor the Set-Cookie header. So the answer is yes you should be able to.
Quotation:
If the user agent supports HTTP State Management it should persist,
discard and send cookies (as received in the Set-Cookie response
header, and sent in the Cookie header) as applicable.
Yes, you can set cookie in the AJAX request in the server-side code just as you'd do for a normal request since the server cannot differentiate between a normal request or an AJAX request.
AJAX requests are just a special way of requesting to server, the server will need to respond back as in any HTTP request. In the response of the request you can add cookies.
For the record, be advised that all of the above is (still) true only if the AJAX call is made on the same domain. If you're looking into setting cookies on another domain using AJAX, you're opening a totally different can of worms. Reading cross-domain cookies does work, however (or at least the server serves them; whether your client's UA allows your code to access them is, again, a different topic; as of 2014 they do).
Also check that your server isn't setting secure cookies on a non http request. Just found out that my ajax request was getting a php session with "secure" set. Because I was not on https it was not sending back the session cookie and my session was getting reset on each ajax request.
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.