
HVAC Marketing: Boost Your Reach Without Melting Your Budget
Ah, the wild world of HVAC marketing—where every season brings new challenges, competitors are practically breathing down your ducts, and…
Read More
As mobile app development exploded over the years, there was a bigger need to share data across domains and platforms. Initially, these cross domain requests were handled via SOAP web services, which can be very heavy in response time and size due to the XML output and additional negotiation time for the SOAP request headers. There became a need for much lighter weight services like AJAX/JSON for mobile development. So the demand for data requests via JavaScript/JQuery grew exponentially, and cross domain requests became even more important.
When browser standards were first implemented, they included what is known as the same-origin policy, which still holds true today. This policy allows for scripts from the same originating domain to be accessed, but for security reasons it denies cross domain HTTP requests. In order to overcome this, many developers had no choice but to implement what is known as a proxy; however, they are difficult to implement and maintain.
Then along came CORS, which is a W3C specification that has added HTTP header standards to allow for cross domain requests. This makes mobile app web service development much more straight forward. You can implement CORS on just about any framework or language such as Java, PHP, or .NET. If you’re a .NET developer and have had trouble developing cross domain services, look no further than the new ASP.NET Web API 2. It comes included in the .NET framework version 4.5. This library makes it a breeze to implement CORS, so you can focus your time on the services themselves instead of trying to find a work around cross domain restrictions. However, when developing cross domain services you must be cautious. You will need to limit the access of the services to trusted domains and also deny HTTP request types that your services don’t implement. I.e. deny POST & DELETE if they are not required methods for your services. CORS services should never make sensitive data publicly available because of the openness of the CORS architecture.
So if you’re going to be developing apps, at some point your going to have to deal with getting around the same-origin browser policy and the best solution is to implement CORS.
Comments
There are currently no responses.