I have created an Open Layers 3 Map which loads its tiles from my server, i dont transmit the user id, it's recognized server side, so the map does not work if there is not user logged in.
So far so good, everything working. If someone clicks on a feature in the map i would like to send some request to the server as well, also without sending the user id, cause there should be a session anyway. But if i send an AJAX request to the server, then the JSESSIONID will be missing from the request and i get a new session id every time i send a request.
I know this is due to HttpOnly flag, but what bugs me is, how can Open Layers have the JSESSIONID in its requests, but i dont get it for my own Ajax requests.
See also the picture for the difference:
-- GetTile is a request generated by Open Layers
-- GetStarMapData is a request generated by own written Ajax call
Both requests just access a servlet on the Server
Cross-origin XHR requests (the Origin in your screenshot indicates you are making one) only include cookies if you explicitly turn credentials support on.
xhr.withCredentials = true;
This will make it a preflighted request so you will have to configure the server to correctly respond to OPTIONS.
Related
So I have been developing a webpage the would give random quotes whenever a user clicks on a button by calling an API.
Please refer to my previous question for more information Not able to get values (quotes) from the API using jquery
I was told that the reason I couldn't get the response from the API is because my ACAS(Access-control-Allow-Origin) is not set properly in my server and I have to debug it.
Now that I don't much about ACAS or CORS. I have some questions. SO here they are:
1. What exactly is ACAS and how is it related to CORS?
2. How do I debug my page and set the ACAS?
3. Does that have to do anything with my jQuery? Or should I configure only my browser.
You can find many documents on the internet
,so I'll just briefly talk about CORS.
When you're sending request to different domain
for example from a.com to b.com, or localhost:8080 to a.com......
your're making a cross-origin HTTP request ,
sometime this is not allowed, for example Ajax (as you're doing) requests.
Because XhttpRequest, Fetch (both are Ajax API) follow same-origin policy, which means by default you can only make requests form the same domain, ex: from site.com to site.com/users.
The reason they follow the same-origin policy is to prevent CSRF attack (Cross-site request forgery).
1.So basically you cannot get the result of cross site Ajax request, it will block by browser because of the security issue, unless the response header Access-control-Allow-Origin is set to allow client's site to send cross site ajax request. ex: Access-control-Allow-Origin:*allow all sites form different domain; Access-control-Allow-Origin:www.b.comonly allow www.b.com domain.
2.Take Chrome for example If the cross site request's result is blocked, it will show on browser's console:
You need to set the response header in your server, for example I set Access-control-Allow-Origin:*, then in browser's "network" console you can see the header is set, and now I can get the Ajax result.
I think nothing should do at client side, all is at server side.
Refer to this post as it makes this clear
Note also that there are some techniques frequently used in order to bypass CORS like setting up a proxy which acts as a relay for your request or using JSONP instead of JSON.
My website returns a JSON string contains database result when you call the URL through ajax. It's actually public. I mean everybody can send an ajax request to my website and simply get the result neatly (currently my website acts like a free API).
Now all I'm trying to do is authenticating all requests and just response the known ones. So I think I need to pass a token with along each request for identification.
My question: How should I make that token (that no one else can)? And how should I identify that token on server side?
If your "website" and the "app" that calls your website reside on the same domain. Then this can be done server side.
First CORS will stop any java-script app from replicating your client code on another server and calling, or the lack of.
Second. On your server just check that all incoming calls are from the same HOST or the host you want to permit. This would reject any calls that did not originate from the same domain - which you control.
I don't know what language you are using so i can't post code.
I suggest you use jwt to authorize. U can achieve this by requiring that a user log in first and respond with a token on successful request. This token will then be used for subsequent requests
The situation is as follows:
I am logged into a web application and there is an HTTPOnly-Cookie stored with a JSESSIONID. The backend I am sending requests to is running on the same website/url as the frontend application. Now while I am logged in as User A (identified by the cookie with the JSESSIONID), I need to do a single request to the same backend but without this cookie! Whenever I send a request to the backend, this cookie is automatically sent too though.
So how can I tell an AJAX request to NOT automatically send this certain HTTPOnly cookie - or even any cookie at all. I know that this can be achieved for Cross-Origin calls (see "withCredentials" flag). But this does not help since it is no Cross-Origin call...
Can anyone help me with this one?
Thanks and best regards
I've observed that my express server sends a Set-Cookie header in response to every OPTIONS request made by my front-end Angular.js project.
The cookie has a new value on each of the OPTIONS requests, but is never actually stored by
Chrome.
When I use passport.js to authenticate a user, the response to the POST request has the same header (again with a new cookie), but this time I can see that it is stored, and sent with subsequent requests in the Cookie header.
Which express module is doing this, and why? And why does Chrome not store the cookie?
This is more curiosity than anything, as it's not causing any problems (just caused a lot of confusion when trying to track one down).
The method OPTIONS are not supposed to have a side-effect. See this HTTP 1.1 documentation
OPTIONS is a request for information to the server. Such request is not considered as real interaction between a user and server. The server likely makes the information available to all users.
The browser respects this and chooses to ignore the cookies, conforming to the specification. That said it is security risk passing cookie data to user openly. Even if it is not valid, it can reveal server-side internals, which can allow hackers to exploit it.
pretty sure this is a bug with the current session module. if you're using the new cookies session, then you won't hit this problem. feel free to file a bug: https://github.com/expressjs/session
This is a concept that I thought I understood, but recently found out I had all wrong. I've looked all around the internet and find plenty of examples of small details and code snippets, but I still lack an understanding of what it prevents and why it prevents it and for whose sake. So this is more of a request for a high-level explanation than a question.
Anyways, here's what I THINK I understand about it:
Let's say I have domain A.com and domain B.com. Each on their own apache servers with their own IP addresses.
I load an html file from domain A.com into a browser. The browser executes a POST XMLHttpRequest to B.com/doStuff.php, which fails because the same-domain-policy was set.
So:
Who's same-domain-policy is relevant? I think the answer is B.com/doStuff.php's... right? So when A sends the request, B checks the request headers for an origin and says "whoops, different domain, won't listen to you". Or does A send the request, B responds with headers that specify "same-domain-policy", and then the browser checks that because same-domain-policy was specified, and the domain from the headers of the A request don't match the one from the B request the BROWSER refuses to send out the xhr?
If that's the case, it seems that the point of not allowing cross-origin-requests is because "I don't want anyone other than me accessing my API". Is that all? Because wouldn't you want to solve that with some kind of authentication instead? Couldn't someone just construct an HTTP request with a fake origin header (simply lie)?
Or is this somehow supposed to protect the user? If that's the case, how is preventing them from calling your API ever going to protect anyone?
I'm so confused...
Who's same-domain-policy is relevant?
The server receiving the request decides.
... the BROWSER refuses to send out the xhr?
No, the server refuses to respond. To be more exact, in modern browsers it is done by preflighted requests. It means that for each cross-origin request, first an OPTIONS request is sent automatically by the browser whose headers are the exact same as the intended request will have but with no request body. The server responds also with headers only. Access-Control headers in the response will let the client browser know whether the request would be fulfilled according to the server's policies. In a sense the browser is preventing the request, but only because it already exchanged a request/response pair with the server and knows that there would be no point to attempt the request. If you forge a request in such a case, the server will still deny serving it.
The idea is that you don't want to access server b from server A via Javascript. If you're interacting with an API, you would use javascript to make a call to your own server's backend code, which would then make a call to the other server.