We are writing a stand alone JavaScript application that has to create Wiki pages in an IBM Connections community via the Connections API. However, the browser blocks the requests to the Connections API because Cross Origin Resource Sharing (CORS) is not configured on the connections API.
Is it possible to configure the connections API to allow requests from all our internal applications eg *.our-company.com? We're running Connections v5.0.
Yes it's possible. You simply have to configure this in the IHS! This config snippet might be useful for you:
RewriteCond %{HTTP:Origin} (.+\.<yourdomain>\.com) [NC]
RewriteRule .* - [E=acceptorigin:%1]
Header set Access-Control-Allow-Origin %{acceptorigin}e env=acceptorigin
Header set Access-Control-Allow-Credentials true env=acceptorigin
Header set Access-Control-Allow-Methods "POST, GET, HEAD" env=acceptorigin
Header set Access-Control-Max-Age 3600 env=acceptorigin
Header set Access-Control-Allow-Headers Content-Type env=acceptorigin
Daniel's answer is a good starting point and works for simple cross-origin requests, but I found a few more obstacles to overcome for state-changing, pre-flighted requests. After enabling the Apache rewrite module by uncommenting the appropriate line in the IBM HTTP Server httpd.conf file, my solution was to add the following to the VirtualHost region:
RewriteEngine on
RewriteCond %{HTTP:Origin} ^(http(s)?://mysubdomain.mydomain.com)$ [NC]
RewriteRule .* - [E=acceptorigin:%1]
Header always set Access-Control-Allow-Origin %{acceptorigin}e env=acceptorigin
Header always set Access-Control-Allow-Credentials true env=acceptorigin
Header always set Access-Control-Allow-Methods "POST, GET, HEAD, OPTIONS, DELETE, PUT" env=acceptorigin
Header always set Access-Control-Max-Age 3600 env=acceptorigin
Header always set Access-Control-Allow-Headers Content-Type env=acceptorigin
RewriteCond %{HTTP:Origin} ^(http(s)?://mysubdomain.mydomain.com)$ [NC]
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* - [R=200,L]
RequestHeader unset Origin env=acceptorigin
(Of course, Daniel used a more general regular expression for the domain: I only needed one specific origin, so configured accordingly.)
The "always set" is important for pre-flighted cross-domain requests, which send an OPTIONS request to the server before making the real request. Here, "always" means "even put these headers on error responses". Connections doesn't know what to do with the OPTIONS request and returns an error; I deal with this by setting the headers anyway and then re-writing the status code to a 200 (the browser still gets text that warns about an error, but doesn't care).
You don't need the final "unset" line to get through the web server, but at least some parts of the Connections API will reject POST requests that have an Origin header on with a 403. To solve this problem, if the header matches my allowed origin, I strip the Origin header out of the request before the IBM WebSphere Application Server gets hold of it.
IBM Connections 5.5 can handle CORS directly. You need to add two custom properties to your LotusConnections-config.xml:
<genericProperty name="CORS.Trusted.Websites">mydom1.com, mydom2.com</genericProperty>
<genericProperty name="CORS.Expose.Headers">Content-Encoding, Content-Length</genericProperty>
Details can be found here:
