I think I'm fighting the Same Origin Policy

[Shadrack]

Hi!

About 10 years ago I basically LIVED in this forum. Now I'm returning to web development for a small project of porting my application that I've written in LabVIEW to be used over the web. The fact that I am using LabVIEW isn't really important. What is important is that my LabVIEW application is running a REST service on my port 8080, and I'm trying to consume that service using some Jquery in an html page running on IIS on port 80.

The service I'm using to get things going is a simple adding service that takes the form:

http://localhost:808...:input1/:input2

Where the output is the summation of the two inputs. So for example if I were to do a GET request for http://localhost:8080/add/1/2 the return would look like:

<Response>
<Terminal>
<Name>Output</Name>
<Value>3.000000</Value>
</Terminal>
</Response>

I can't even get this basic checkout to work:

	   	 $.ajax({
				type: "GET",
				url: "http://localhost:8080/add/1/2",
				success: function(data){		
					alert(data);
				}
			});

Doing some searching reveals that I'm up against the old "Same Origin Policy" because my script is being accessed through port 80 (where IIS lives) and is trying to place a call to port 8080 (where my web service lives).

So many friggen solutions out there! But I'm having trouble getting any of them to work. It would be great if my alert box would popup and give me the correct response. I think that some kind of reverse proxy might be a good solution, but the manner of setting that up in IIS 7 on Windows 7 Pro isn't sitting well (I'm thinking of switching to Apache just because it does this more gracefully I think).

Ultimately I do not think a reverse proxy will work on the production server because I am not the admin. And what I give them as a web service installation will be running on a different port (and possibly a different domain) than the front end javascript client.

Thanks for your time.

[Tuishimi]

You could try running a server in a VM? But otherwise, I am not sure...

[tim_s]

Hi,

Do you have a public facing IP?

I.e. how can I see your results to debug?

--

When you refer to the origin policy I am assuming you mean that you are sending the request from http://localhost(:80)/ to http://localhost:8080/?

[Shadrack]

Hi,

Do you have a public facing IP?

I.e. how can I see your results to debug?

--

When you refer to the origin policy I am assuming you mean that you are sending the request from http://localhost(:80)/ to http://localhost:8080/?

Sorry, I do not have a public facing IP right now (and do not have the authority to enable that).

Yeah, sending the request from http://localhost:80/ to http://localhost:8080/

I'm reading about CORS as a possible solution. But there is a requirement to echo back the origin in the HTTP header which I do not think is possible with a LabVIEW web service....

-Shad

[tim_s]

Sorry, I do not have a public facing IP right now (and do not have the authority to enable that).

Yeah, sending the request from http://localhost:80/ to http://localhost:8080/

I'm reading about CORS as a possible solution. But there is a requirement to echo back the origin in the HTTP header which I do not think is possible with a LabVIEW web service....

-Shad

This could be done in a 100 different ways depending on your level of access. How many calls a second would you be looking to instantiate? I.e. would an extra step provide an efficiency issue?

[Shadrack]

This could be done in a 100 different ways depending on your level of access. How many calls a second would you be looking to instantiate? I.e. would an extra step provide an efficiency issue?

I don't see any extra steps providing efficiency issues...

the number of calls is pretty low...as in a user would really only be expected to issue 1 call.

My end product (not this trivial addition one) will have the following work flow

Present user with web form -> User fills out web form and hits submit -> Contents of web form are compiled to a POST response and pushed to my REST service on port 8080 via javascript -> REST Service returns an image URL -> Javascript updates an image tag on the page with the URL returned from the REST Service.

The REST Service takes the data, does some calculations, produces a plot, saves the plot as a PNG image somewhere, and returns a URL for the image file.

In addition the end product will be behind a username/password and access will be limited to a small number of people.

[Shadrack]

I just spoke to our web guy who says he is already having to do some proxies with PHP so I'm going to go that route...

[Shadrack]

Is there a graceful way to write a PHP script that will perform the proxy like:

http://localhost/LV/* --> http://localhost:8080/*

For all POST/GET requests?

[Guest pgxl]

You could use the PHP fsockopen functions http://www.php.net/manual/en/function.fsockopen.php , but sockets extension needs to be enabled in the php.ini file. You could have your php script call the socket directly and pass parameters to it and have the application return results back to the php script, then the script can return data to the end user as the rest response.

If your port 8080 application is running its own webserver or can be loaded from a browser than use CURL within php as it is easier than using fsockopen.

[tim_s]

Is there a graceful way to write a PHP script that will perform the proxy like:

http://localhost/LV/* --> http://localhost:8080/*

For all POST/GET requests?

Sockets or mod rewrite.

[Shadrack]

Thanks guys. I have one PHP proxy worked out, but am not happy with the lag...lol (at least not on my development machine).

I found a way to incorporate my static HTML/Javascript/Image/CSS files inside the web service executable (it's compiled) so that my static files are served on port 8080. Doing this alleviated the same origin policy issues and everything is snappy.

[tim_s]

That is awesome :)