Use of HTTP Origin Header with HTTP client connector

Document created by aarthi_sridhar Employee on Jul 16, 2018Last modified by john_yocum067395 on Aug 2, 2018
Version 3Show Document
  • View in full screen mode

This is information about sending an Origin header as part of a HTTP Client connector POST request. While you run process and observe in a Charles proxy traffic tool (How to Configure Charles Proxy to Monitor Advanced Atom Traffic ) the raw request does not contain any Origin. Few settings and recommendations would enable Cross origin from Boomi HTTP connector. 


Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application makes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin. The CORS mechanism supports secure cross-origin requests and data transfers between browsers and web servers. Modern browsers use CORS in an API container such as XMLHttpRequest or Fetch to help mitigate the risks of cross-origin HTTP requests. 



How Origin works in Postman : 

Unfortunately some headers are restricted by Chrome (some browsers) and the XMLHttpRequest specification. The following headers are blocked:

Cookie 2
However sending these restricted headers is easy while using a Chrome postman. Follow the steps below: Install the Interceptor extension either by clicking on the Interceptor icon in the Postman toolbar or through the Chrome Web Store. Once it’s installed, click on the icon again in the Postman app and toggle it on. That’s it! You can now send requests which use these headers from Chrome postman.



The main HTTP request header of note here is the Origin header below postman screenshot, which shows that the invocation is coming from content on the domain https://soagw- 




How Origin works in Boomi Local atom : 


From the above restricted headers, one such header widely used is Origin. This feature of using Origin as request header might be intentionally restricted for security/XSRF prevention.  we initially attempted at passing this header resulted in the request making it to the destination but it was missing the Origin value and payload. A line needed to be added to the atom.vmoptions file to allow restricted headers. So we added a line to allow origin as header. We added this to atom vmoptions :  After this the request was permitted to go through. 




Common Errors : 


1. Access-Control-Allow-Origin : If the call failed with 500 internal server error, check in response header if this is not sent back from Access-Control-Allow-Origin: * which means that the resource can be accessed by any domain in a cross-site manner. If the resource owners at https://api-stage wished to restrict access to the resource to requests only from https://soagw-, they would send back: Access-Control-Allow-Origin: https://soagw-  . If either of the setup is not available in endpoint server while exposing the API , a 500 error occurs. To resolve this issue either * or the allowed origin has to be entered and hosted again.



2. Origin : Adding a Origin header would end up in 401 unauthorized error response code. This is because the atom could redirect to the exact origin as the header is not accepted. The Origin header is added by the user agent to describe the security contexts that caused the user agent to initiate an HTTP request. HTTP servers can use the Origin header to mitigate against Cross-Site Request Forgery (CSRF) vulnerabilities.  Adding just the header request would require allowrestrictedheaders setup in client atom vmoptions of a local atom. This is not currently possible. The headers are restricted for a reason, as they could cause malicious activity. The vmoptions makes the setting for ALL code within that particular atom, which is unsafe. The only way to get this to work is to install on a local atom that has strict access requirements as to processes deployed. At this point, we recommend changing the requirement of a Origin header to a X-Origin header . X-Origin is not a restricted header. This is depicted in above operations screenshot. Change the expected header from "Origin" to "X-Origin". You may no longer need to have the "allow restricted headers" line in the vmoptions file thus alleviating the security concerns.



As the connector uses HttpUrlConnection in the HTTP connector it looks like that doesn't supply a default value for any restricted header. It looks like the connector does not do anything in its code to suppress that header if specified by a user. It is controlled at the JVM so, if you are using a local atom, you could try setting it as a JVM property:
We might not have a solution if the requirement is to do this on the Boomi cloud, however changing "Origin" to "X-Origin" in the endpoint side which hosts the url,  would work as cloud VM options does not require allowrestrictedheaders line for custom header. 


Reference Links: 
The HTTP Origin Header 
HTTP Clientconnection