In a browser a get request is initiated by fetch('/abc'). The server responded 200 with header Set-Cookie: a=b. Is the cookie in the browser getting set?
Yes it is. You should check the network developer tools tab. Also try checking document.cookie.
Related
I'm using gssapi/Kerberos authentication in my web application, and I want single sign on via the browser.
The problem is, Firefox sends an initial request to the server with no authentication, and receives a 401. But it includes a keep-alive header:
Connection: keep-alive
If the server respects this keep-alive request, and returns a WWW-Authenticate header, then Firefox behaves correctly and sends the local user's Kerberos credentials, and all is well.
But, if the server doesn't keep the connection alive, Firefox will not send another request with the credentials, even though the response has the WWW-Authenticate header.
This is a problem because I'm using Django, and Django doesn't support the keep-alive protocol.
Is there a way to make Firefox negotiate without the keep-alive? In the RFC that defines the Negotiate extension, there's nothing about requiring that the same connection be re-used.
Alternatively, is there a way to make Firefofx preemptively send the credentials on the first request? This is explicitly allowed in the RFC.
That header is HTTP 1.0, wake up, fast-forward 15 years and your problems will go away. Firefox works very well with SPNEGO.
I experience a problem with Firefox while Chrome works fine. Here is the situation:
Website1.com returns an html page in SSL.
This page makes a request to Website2.com in SSL either via img tag or XMLHttpRequest (same issue).
Website2.com returns a cookie to be set for itself
Firefox ignores this cookie. It is never stored even though it shows in the console.
The console doesn't complain about anything.
Client sends:
Origin: https://website1.com
Server returns:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Origin: https://website1.com
Access-Control-Expose-Headers: *
Set-Cookie: ...
What else am I missing about CORS?
Thanks!
Access-Control-Allow-Credentials: true
Is a special flag. If one side declares it other also have to declare it or else it's security failure and browser will not accept data.
So add the same header to client request. (Or if you control server, consider doing without cookies and passing data with other mechanism)
My question is pretty simple. Although while searching over, I have not found a simple satisfying answer.
I am using Jquery ajax request to get the data from a server. Server
hosts a rest API that sets the Etag and Cach-control headers to the GET requests. The Server also sets CORS headers to allow the Etag.
The client of the Api is a browser web app. I am using Ajax request to call the Api. Here are the response headers from server after a simple GET request:
Status Code: 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-transform, max-age=86400
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: application/json
Date: Sun, 30 Aug 2015 13:23:41 GMT
Etag: "-783704964"
Keep-Alive: timeout=15, max=99
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Vary: Accept-Encoding
access-control-allow-headers: X-Requested-With, Content-Type, Etag,Authorization
access-control-allow-methods: GET, POST, DELETE, PUT
All I want to know is:
Do I need to manually collect the Etag from response headers sent from the server and attach an if-no-match header to ajax request?OR the Browser sends it by-default in a conditional get request when it has an 'Etag'
I have done debugging over the network console in the browser and It
seems the browser is doing the conditional GET automatically and
sets the if-no-match header.
if it is right, Suppose, I created a new resource, and then I called the get request. It gives me the past cached data for the first time. But when I reload the page, It gives the updated one. So I am confused that, If the dataset on the server-side has changed and it sends a different Etag, Why doesn't the browser get an updated data set from the server unless I have to reload
Also in case of pagination. Suppose I have a URL /users?next=0. next is a query param where the value for the next changes for every new request. Since each response will get its own 'Etag'. Will the browser store the 'Etag' based on request or it just stores the lastest Etag of the previous get request, irrespective of the URL.
Well, I have somehow figured out the solution myself:
The browser sends the if-no-match header itself when it sees url had the e-tag header on a previous request. Browser saves the e-tag with respect to that URL, so it does not matter how many requests with different URLs happen.
Also, a trick to force the browser to fetch a conditional-get to check the e-tag:
Set the max-age header to the lowest (for me 60s works great)
once the cache expires, thebrowser will send a conditional-get to check if the expired cached resource is valid. If the if-no-match header matches with e-tag. The server sends the response back with 304: Not-Modified header. This means the expired cached resource is valid and can be used.
I'm writing some code that makes an AJAX request to our web server. Our server runs some logic and then responds with some JSON. It may also respond with a set-cookie header:
Set-Cookie: our_organisation=[uuid]; domain=.our_organisation.com; path=/; expires=[soon]
It works in Chrome and Safari as far as I can tell, but not in Firefox. Firefox will accept the cookie if it's an image request instead. Am I doing something wrong here?
I already had a problem where I couldn't read the AJAX response on the client side in Firefox; this was fixed by setting Access-Control-Allow-Origin: * in the response header.
This is a cross-site XMLHttpRequest?
If so, per http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ withCredentials defaults to false so the "credentials flag" used for CORS is set to false, and then per http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html the "block cookies" flag is set during the HTTP get, and per http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch that means Set-Cookie headers are ignored. Sounds like Chrome and Safari are just not following the specs here.
You can set withCredentials = true on the XHR object to send cookies. But note that if you do that you have to list an actual origin in Access-Control-Allow-Origin; you can't just use *.
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.