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.
Related
I have a problem that I got stuck how to receive POST data in angularjs sending from PHP? Let me explain in detail. My project url is http://test.com/callback and other party will use FORM POST to my callback URL. I want to display all FORM POST data inside that callback controller. Please let me know how to do it. Thanks.
To answer you question you must understand these two concepts:
Web server: (PHP, Node, Apache, etc): the server hosting your page
receives HTTP requests
sends HTTP responses
Web agent: (Chrome, IE, FF, curl, etc) displaying/requesting your page
sends HTTP requests
receives HTTP responses
And find out things does not work the way you want.
Is it possible to make a POST request to other domain (say xyz.com) from for e.g. abc.com?, Please consider the following scenario
We have a Login Page on our web application, after login it connects to server.
If someone other than me knows the request/data format for the login request.
Can he create his own web application to connect to a server using my Request format?
My concern here is not the legal issues, but if this is technically possible or not?
PS : We can get the request headers and data payload of any XHR from "Developer Tools" of browser
Thanks,
Rohit
Yes, this is known as a CSRF attack.
Another domain can POST to yours, but not read the response due to the Same Origin Policy.
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.
Except YQL ,Is there any way to get ajax's response and data from other domain without modifying server side's code?
YQL has limit (1000 calls per hour) for free user , but most of people said it's actually less.
If what you mean by "without modifying server side's code" is not modifying the server of the data source, then you can have your own proxy server (basically making your own YQL server) to read the remote data. This is possible because the server-side is not bound to the Same-Origin Policy.
So you can AJAX your server, then let your server read the remote server using some form of wget, curl or fopen, and return what was retrieved:
Remote server <- fopen, curl or wget -> your server <- AJAX -> browser
You can use a HTML 5 feature which is postMessage to do cross domain calls. Again it is not supported in all the browsers. Look at the following link for implementation:
Cross domain call using postMessage
You can use the iframe receiver pattern. It's an old technique. See Secure Cross-Domain Communication in the Browser by Danny Thorpe on MSDN. You dont have to use JSONP but still can make cross-domain calls
For our APP we have a Web App and a API service, On A certain event the Web app polls the api service for the state of the event using Javascript. Both the apps run on a separate HTTPS sub domain and with a self signed certificate(as it is still in alpha). The problem occurs that the polling is aborted because the https api connection is untrusted. Is it some way for the Javascript request to override the untrusted certificate issue?
Is it some way for the Javascript request to override the untrusted certificate issue?
No, it's because of the same origin policy restriction.
In your case I suppose that you have a page hosted on https://foo.bar.com and you are trying to send an AJAX request to https://baz.bar.com which is not allowed.
You may take a look at the following guide which covers the different possibilities to circumvent this restriction. They range from JSONP, server side script bridges, Flash proxies, screen scraping with YQL, ...
No, you have to add the self-signed certificate to your machine/browser's trusted certificate store.
You also have cross-domain origin issues (the different subdomain), which is separate from any certificate issues. If you're already using JSONP, you're fine; but if you're trying to make an XHR request to a different domain, it's not going to work.