If you are making client-side Javascript request to SData from a domain that is different than where your SData portal is deployed, you’ll like be seeing the requests blocked with errors showing in the console that say “Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource”. What this means is that the browser is blocking the request as a possible security risk because the code is executing on a different domain than where the request is being made. The same-origin policy prevents Javascript from making requests across domain boundaries and is something built into your browser. The point of this policy is to prevent malicious scripts on one page from obtaining access to sensitive data on another webpage through that page’s document object model (DOM). However, for an API, such as SData, there’s completely valid reasons for enabling these sort of requests. For SData, it’s entire purpose is to serve up requests to other websites. It’s purpose is to allow for integration.
If you’re using server-side code, such as C# or VB.NET, this is a different story since the browser is not where the code is executing. That is happening on the server. For client-side Javascript, however, the browser is executing the code and the requests will be blocked by the browser. This article will outline the steps needed to enable these sort of requests, meaning we will be enabling cross-origin resource sharing or CORS.
First of all, why would you want to do this? Lets say you have Infor CRM Mobile deployed on a server that is a different location than where your SData is deployed. Maybe you have a local development site for mobile that you need to be able to access SData on the server. Or maybe you have integrated SData requests onto a completely separate portal or website. If you’re using Javascript to make these requests, you’ll need to enable CORS for the SData portal.
There’s several different ways you can enable CORS on a IIS website (in our case the SData website in IIS). You can see several different ways to do this on the Enable CORS website. The approach we will be taking here is to create an ASP.NET Module that we can easily add in Application Architect and even bundle up as needed. This module will add headers to tell the browser that we’re OK with it accessing resources from different origins.
Enabling CORS for the SData Portal
1. Open a text editor, such as notepad, and paste in the following code and save the file somewhere as CrossOriginSupportModule.cs:
using System;
using System.Net;
using System.Web;
namespace FX.Modules
{
public class CrossOriginSupportModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += delegate
{
if (context.Request.HttpMethod == "OPTIONS")
{
context.Response.StatusCode = (int)HttpStatusCode.OK;
}
};
}
public void Dispose()
{
}
}
}
2. Now, open Application Architect. In the Project Explorer expand the Portal Manager and double-click the “SData Integration Host” portal to open it.
3. On the Support Files tab, right-click the very top node and select “New Folder”. Enter the folder name as “App_Code” (it must be named this exactly).
4. Right-click the new App_Code folder and select “Add Existing” and browse to the CrossOriginSupportModule.cs file you created in step #1.
5. Now, locate the web.config file in the Support Files and double-click to open it. We’re going to be merging in the following changes:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="GET,POST,PUT,DELETE,OPTIONS" />
<add name="Access-Control-Allow-Headers" value="Authorization,X-Requested-With,X-Authorization,X-Authorization-Mode,Content-Type,If-Match" />
<add name="Access-Control-Allow-Credentials" value="true" />
<add name="Access-Control-Expose-Headers" value="Location,Content-Disposition" />
</customHeaders>
</httpProtocol>
<modules>
<add name="CrossOriginSupportModule" type="FX.Modules.CrossOriginSupportModule" />
</modules>
</system.webServer>
To do this, we’ll locate the corresponding sections in the web.config and paste in the changes as outlined above. Start with locating the system.webServer section. Somewhere inside that section, paste in the following:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="GET,POST,PUT,DELETE,OPTIONS" />
<add name="Access-Control-Allow-Headers" value="Authorization,X-Requested-With,X-Authorization,X-Authorization-Mode,Content-Type,If-Match" />
<add name="Access-Control-Allow-Credentials" value="true" />
<add name="Access-Control-Expose-Headers" value="Location,Content-Disposition" />
</customHeaders>
</httpProtocol>
Inside the system.webServer section, you’ll see an existing section for modules. Inside that modules section, paste in the following:
<add name="CrossOriginSupportModule" type="FX.Modules.CrossOriginSupportModule" />
In my system, the complete web.config file looks like this (don’t use this to copy & paste into your system. Your web.config could be different depending on your Infor version and things like whether you have windows auth turned on or not, etc).
6. The last thing to do is deploy your SData portal and you’re all set.
With the changes above in place, you should now be able to make client-side requests to SData from other websites. As I mentioned before, all of the above changes can be bundled up and moved to production as you would any customization.
