POST and Cross-domain problems

I am using AJAX to consume a webservice. I am sending a soap xml message via the post body in the xmlHttpRequest object. The WM server is on another host in the same network, but whenever I try to access it through Firefox, Safari, Opera, or Chrome, I get a NS_ERROR_DOM_BAD_URI error.

Internet explorer is the ONLY browser that is allowing me to access the service. Is there a way to set an option on either the client or the server (or both) to allow the two hosts to communicate over the same network?

Thanks!

A Google search of cross-domain AJAX techniques might turn up some useful tips/hacks/libraries.

Probably the easiest is to use a proxy approach on web server–have it call the wM IS-hosted web service for the client. Client phones home, home calls wM IS and returns the results.

I’ve googled until my head is about to pop! LOL
I have seen several pages that mention making a change to firefox’s options, but I shouldn’t have to require that all my users do that in order to use our webpage.
I’ve also read a lot about the cross-site policies, but don’t think that most browsers are adhering to it appropriately.

This is the way to go, better architecture, better security.

Doesn’t using a proxy basically convert a POST to a GET? If I am sending confidential info (such as SSN or ID numbers), wouldn’t that make it more accessible?

That is indeed an issue–there isn’t a standard for this so there are lots of approaches to choose from. :cool:

Don’t know why that would be the case, you javascript client would just be invoking(post) to the the web server hosted service(proxy service) and the web server would post to webMethods hosted service. At any rate whether using Post or Get, you have SSL involved for confidential info, from Server to Client and from Server to Server(client). Post is just security by obscurity right?

So how does a proxy help if it’s just relaying a post to the WM server?

That’s kind of the point of the proxy, do work on your behalf because you can’t or shouldn’t do it directly.:smiley: It will get you around your cross-site problem. You can also lock down your web service(webMethods Hosted) so that it can only be accessed by the web server cluster(becomes the client) and not each individual browser client.

For me I’d want my javascript interaction to be limited to the context of the web application I’m running. I like a service layer separated from my presentation/GUI layer. The service layer interacts with other services outside of the context of the web application. The service layer is logical and can be split across many physical tiers. That’s just one suggestion though.

So I need a proxy on the same host as my web server or on the same host as the WM server?

Web server.

Ok, tried the proxy.
I got a soap fault back from webMethods saying, “[ISS.0088.9109] SOAP is only supported using HTTP POST protocol”

What now?

Can you elaborate on the details of “tried the proxy?” In the code that does the call to Integration Server have you tried using post?

I am using a php proxy script on my webserver to send my data across to the webMethods server. I basically tranlates the POST into a GET and passes to the webMethods server.

I have indeed tried POST. I am sending a POST request via AJAX sending a SOAP message as the post body. (FYI: I am using prototype.js framework to send the ajax)

You might consider writing your own module on the web server instead of relying on a standard proxy. In my suggestion, I was using the term proxy in the general sense, not necessarily a “real” proxy.

Have the client code post to your module on the web server, have your module post to IS and marshall the results as needed. Don’t use anything that translates the post to get–as you’ve seen, that doesn’t do what you want/need it to do.

The problem with that (or with me) is: how do I get it from my host to the IS? What should my module do to get around the same-origin policy?

Via a new HTTP post from your module to IS. Your web server module would have its own session to IS. There would be no domain issue.

Client does HTTP post to your web server.
The module to handle that post is kicked off.
Within that module, you get the post data, open a session to IS and do a new HTTP post.
IS returns the response to your module.
Your module gets the response and creates a response to the client.
Client processes response.

The problem is getting from the client to the IS host. Browsers will not even send a pre-flight request if the URL of the current page isn’t the same as the destination of the POST request.

My setup:


| Client | | WebServer | | IS |
| Browser | | (Host# 1) | | (Host# 2)|


The client tries to HTTP POST from WebServer on Host #1 to the IS on Host #2, but the browser blocks the HTTP request because the URL for Host #2 is not the same as Host #1. So, it’s not a matter of getting the data to the IS, it’s a matter of getting the data out of the browser. I can currently test in Internet Explorer, but no other browser will let me. I get policy errors from the browser and using Ethereal to sniff the packets, I never see any data leaving the browser on the client machine.

But the client should not be referring to host #2 at all. It makes a request of host #1. The URL in the page/JSP from the browser should/must connect to host #1.

The server-side code of host #1 makes the HTTP post call to host #2. The browser will never know that happens.

I see what you’re saying. I’ve been playing around with that concept a little, but haven’t fully implemented it yet.

Do you know of any examples out there that I can use?