We have a webservice that is mainly intended to be called from javascript, via jquery's $.ajax(). When we call methods from javascript, we set a security token in a request header. If it's not there, or if it doesn't validate, we return an unauthorized error.
And that's all working fine.
But now we're faced with returning image files. So instead of having javascript call $.ajax(), we're embedding an image tag in the DOM:
<img src='http://mywebservice/imagescontroller/getAnImage?imageid=123'/>
And when we do that, we don't have our security token in the request header. I can think of two "easy" fixes. 1., we simply allow anonymous access to our image URLs, or 2., we pass the security token as a URL parameter.
The first choice is, of course, not a good idea. The second is straightforward enough. But before I settle on this approach, I was wondering if there was some easy way of setting request headers on these sorts of requests, that I was missing.
Ideas?
Easy fix: Use session cookies. That is a cookie without a expiry date. It will automatically transmit with each request and go away as soon as the users closes the browser, or you delete the cookie via javascript.
You simply store your token there and get it delivered for free to your server code.
Have some demo stuff here:
How do I set/unset cookie with jQuery?
If you run the services on another domain, you will need to use CORS to make the AJAX running - otherwise your AJAX will run into the Same Origin Policy. With CORS you can even make the cookies work.
See here: CORS request - why are the cookies not sent?
If you do not want to use CORS, you could also incorporate the service domain into your own via reverse proxying. This will solve the SOP problem as well as make the use of cookies possible. Setting up a reverse proxy within Apache is pretty straight forward.
Related
This is a research question I've been hitting my head on for a while now. I'm not sure if it's possible but it seems like it should be.
How do I make var token that was defined in them.com's javascript to be visible to us.com's javascript WITHOUT sending information to any of the two servers?
The goal is to save information in the browser to be accessible cross-domain? localStorage, sessionStorage are domain-locked. And set-cookie make it visible to the server... So I cannot use those.
You could give CORS Anywhere a shot.
https://cors-anywhere.herokuapp.com/
CORS Anywhere is a NodeJS proxy which adds CORS headers to the proxied request.
Basically, you can prefix the request URL with https://cors-anywhere.herokuapp.com/.
For example:
fetch('https://cors-anywhere.herokuapp.com/http://your-req-url.com/some-endpoint')
You can also host it yourself. Further reading: https://github.com/Rob--W/cors-anywhere/
So a couple of days ago i was looking for something like this and had actually found it but never found a use for it. I know its listed somewhere on mozilla's site but i forget what the function is called.
In anycase i wish to request an external domain that doesn't have cors and does not requir external help from things like proxy's. its a rather recent function added to javascript as when i read about it (before i forgot the name) it was listed as expiremental technology. It's supposedly a safe alternative to CORS the only catch is unlike cors you are not allowed to view the response.
What i want to use it for is to basically see if the status code returned is 404 or 200 so i can tell users whether a specific site is having issues and since the ammount of sites that would be requested is huge if i do it server side id prefer to have it done in a clients browser only on specific pages.
I think you could get by with sending a HEAD HTTP request.
Is it possible it ONLY JavaScript to hit a specified URL and get a reply as to whether it was possible to hit the URL. I do not need the URL content, and any information of the page, all i need is conformation that the URL was reached and it penetrated all custom firewalls that would site in its way.
No. You would hit the Same Origin Policy wall.
You really need to do it in the server side. In the JS side, you can then test it by a simple ajax to the server side which returns some boolean. Note that this only tests the connection between the server and the desired URL, not between the client and the desired URL. Not sure if that may form a potential problem for your functional requirement.
You can make a HEAD request for the URL. That will just return the HTTP header, but not the content.
If this is Javascript in a browser, this should be easy enough using the XMLHTTPRequest object, provided of course that it's in the same domain so that you have access to request the URL at all.
Only if the requested page have the Access-Control-Allow-Origin header.
This feature add crossdomain origins to your document.
BTW, you only can retrieve it with modern browsers, and need the access to requested page (to set this header).
Look at:
http://www.w3.org/TR/cors/
Just wondering if it's possible to use an XMLHTTPReq to login to a website, and store the cookie. Specifically I'm after the PHPSessionID from the website I am logging into.
I then want to pass this cookie into another request to submit a form.
Any ideas of how to do this?
Cheers,
Nick
You will be able to get your own site's cookies from document.cookie. In the AJAX callback, use a library to parse the value and read the cookie you're looking for.
Of course, if the server sets the cookie HttpOnly (which it should be doing), it won't be available in document.cookie.
At this pont, you need to reevaluate what you're doing:
If the form points to your website, your server script would have access to the cookie anyway.
If you're sending the user's session ID to another domain, why? This is a huge red flag that screams security problem.
If you're logging in to another site, then no – the same-origin policy prevents you from accessing another site's cookies.
Edit: Since this is for your own use, you can do this in a way you're not limited by the browser's origin restrictions. Some thoughts:
You could make a Chrome extension. Extensions aren't subject to origin restrictions, and the development model and API is pretty much the same as what you'd do on a regular web page.
You could use Node, which has no restrictions. You'd be able to invoke your script from the command line, but the API is going to be slightly different that what you'd use in a web page.
Use your language and framework of choice to POST to the login page, get the Set-Cookie header in the response, and use it to send a Cookie header in another POST to the form target.
You can only send cross-origin requests using XHR if both the browser and server support CORS. Additionally, the third party site needs to allow your site to send such requests and to receive its responses. If it doesn’t, you aren’t allowed to send the request or receive its response respectively.
I need to use AJAX to get the content of another page located on a different server from the one the AJAX is loaded from. The AJAX needs to send a POST request then return the result. how can i do this?
Set up proxy on your own server. Have your server call theirs and return the result.
if you control both servers, you can use one of the HTTP header fields for cross-origin resource sharing:
http://www.petefreitag.com/item/703.cfm
https://developer.mozilla.org/En/HTTP_access_control
There is no way to go around that policy. This policy is there for very good reasons.
That is also no problem as long as you're in control over the web application. You could simply redirect the call to the other server from your webserver and pass the result. This would work out like a proxy.
If you want to do that on the client and cross browser, you need some cooperation from the other server.
Either by:
1) using JSONP (inject a script tag with a callback function)
Only GET calls are possible though.
Security is an issue as the script has access to all resources in that page(data, cookies, ...).Here's a post that explain how to sandbox them and keep the data in your page safe.
2) POST looks possible using Kris Zip's window.name technique
If the cooperation from the other server is impossible, the server proxy as described in other answers is, to my knowledge, the only option left.