The problem: Same-origin policy.
One of our customers has our product installed on the cloud. We also sell our own print server that allows customers to print things related to our product, which they typically install on their own network so they can print to their own printers.
My Mistake
Long long long long time ago, before the wind before the snow, I moved the code responsible for making print requests from the browser to the server. The customers server could act as a proxy bypassing same-origin policy restrictions. Perfect! Nope...
Back to square one
This works for most customers, however as I said before, some customers have the app hosted on the cloud, but our print server is hosted on their own network making it not doable to use our app server for making requests. The request needs to be made from the users browser, which brings back same-origin policy problems.
Same-Origin policy
In case you don't already know what this is or have been lucky enough not to have problems with this, this occurs when the browser makes a request to a domain differing from the one the response originated from. It's a security feature. So if I make a request to blueridgedebate.com which returns some buttons and stuff, then click a button which tries to make a request to blueridgedebate.com:7777 (unless you're IE), or http://www.aol.com, my browser will reject the request.
Normally this isn't a problem when using third party APIs because the requests will be made by the server and not the browser. This is how it was for me in the past anyway. If I had to send some web services I'd make an Ajax request to the server and let it handle communicating with whatever third party it was I needed to talk to.
But as I said before - sometimes you can't have your server act as a proxy. You need the user to be able to make a direct call to a different origin. What to do????
Solution - CORS (Cross-Origin-Resource-Sharing)
Cross origin resource sharing is the solution! What you need to do is modify the HTTP headers your server returns in the response.
To do this the server needed to be modified to return the correct HTTP headers to indicate that different origins are ok. If you're using Java you can probably do this in your servlet, or you can probably add some configuration somewhere. For me, our print server is written in .NET, so luckily there's a config file I could modify to handle this for me. I didn't have an option to change the code, but I could change the server configuration file:
Here's what I had to add to the root XML node:
Code: Select all
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type, Access-Control-Allow-Origin, " />
</customHeaders>
</httpProtocol>
</system.webServer>
After adding the configuration above, the appropriate headers were returned in the server response, and i was able to make Ajax requests without any problems.
I will not be happier when Windows XP and IE6-8 get the permanent bit rot.
