I know there is an almost duplicate question, but the answer is not satisfactory at all.
I need to do geocoding using the Openstreetmap service which runs over HTTP.
My site runs over HTTPS.
It seems impossible to do JSONP request from https to http, browser (Chrome) complains about insecure content.
Any solutions?
The reason that the browser complains about insecure content is that the content is insecure. The entire purpose with a secure page is that all of it is secure, and can be trusted.
You can set up a proxy page in your secure site that requests the insecure content. There you should verify the content before it's sent to the browser, so that it is actually secure, not just pretending to be secure.
If you want to make a POST request to an external service that runs under HTTP while the initial request is coming from HTTPS it will always be considered as insecure.
There's, as far as I know, no way around it.
What you can do, is POST to your backend which send another POST request to the service that is running under HTTP. From there just return the value returned by the HTTP service.
For whom it may concern, this is how I sorted it out myself.
1) my Javascript code calls an AJAX page on my server with the parameter I need to forward to the service
2) the AJAX page makes a request via CURL using the address
3) I sanitize the response and turn it into JSON
4) with Javascript's callback-on-success I use the data
Related
As you know you can not make http requests to sites that do not have the http header that allows it using JavaScript in browsers because of CORS. I need to make https requests containing sensitive data. I do not want to get in touch with this sensitive data, in fact all this will be client side with javascript, only for the reason mentioned above I need to use a php proxy such as CORS Anywhere or my own, the question is: if I use these proxies to make https requests directly to the direct interested server, will the proxy have any information regarding the data sent? Sorry for my bad english, I use the translator.
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.
I have a WCF web service hosted on Azure as a cloud service. I am trying to send a POST SOAP request from an HTML/JS web application it appears I cannot POST a SOAP envelope across domains. I have tried a variety of POST techniques with no avail. Has anybody experienced this before and/or is aware of a work around?
Any help would be appreciated.
Cheers
No, this is not possible, as per AJAX cross-domain requests cannot be made unless the server says " I'm ready to accept".
Normally, when you make a cross domain request an OPTIONS request is made to the server, to check what all methods and options are given allowed at the server. The server responds with a set of headers which says further communication can be made or not.
So, if you want to do a cross domain AJAX POST/GET, you can do it provided either of the following is possible
-> Server says "I am ready to accept" for your client request - which normally does not happen
-> Use a proxy server in your layer, to forward the request to target server, and revert back the response.
For more info, you can scroll on MDN forums or CORS facts.
I know its violates the Same origin policy, and that is why it is not possible through simple ajax request. I could use JSONP. But using JSONP for login doesn't sound secure ( no post only get ).
So is there a more secure way of implementing login into https through ajax ?
Not only does it violate the same origin policy, but since the page you are calling from is insecure it has the potential to be interfered with and leak all the data you are trying to keep secure.
Use HTTPS for the entire process.
Better yet, keep using HTTPS while people are logged in, otherwise you will have the Firesheep problem.
As we've discussed in the comments below, this is what Facebook does for their registration page, although there are some vulnerabilities to this method. While it won't appear secure to the user (no lock icon), the actual request is done over HTTPS. If you controlled the entirety of the receiving page, there would be nothing less secure about doing a JSONP request over GET. However, a man-in-the-middle attack could modify the receiving page on load, and cause the returned credentials to be sent to an attacker.
On the plus side though, no one that's just sniffing packets is going to be able to get the credentials: an attack would have to be fairly targeted.
Regarding cookies, technically, JSONP could "return" cookies; you'd just return name-value pairs of the cookies you wanted to set, and have a function on the receiving page set them.
But unless the browser treats <script>s differently, and it might, you should be able to set a cookie in the normal way using the Response Headers of your JSONP response.
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.