Freitag, 24. Februar 2017

IBM Verse On Premise - problems with integration of IBM Connections Files



I just setup an testing envoirnment for Verse On Premise.
To get the full features I also tried to integrate IBM Connections which enables you to use business cards, photos & also let you use your Connections files for your mail correspondence.


After performing all required steps based on the official documentation it seems to be working fine:






 But when I tried to attach a file from IBM Connections I got the error message "service unavailable".
Checking the IHS access logs the following error is printed:

 [24/Feb/2017:10:00:55 +0100] "OPTIONS /files/basic/api/people/feed?self=true&xhr=1&sq=1 HTTP/1.1" 403 162
[24/Feb/2017:10:00:55 +0100] "OPTIONS /profiles/atom/profile.do?mcode=5b65e3542ff4be446f8cd1db987ac3df HTTP/1.1" 403 162

I tried to find a cause why the access should be "forbidden" but I couldn't find any indicator in theSysOut logs and also accessing the referenced URLs directly was working fine - so I asked Google for a solution.

Luckily I found this article from Roberto Boccadoro. He also had the same error and one of his buddies found a solution:
Instead of using the provided IHS configuration of IBM add the following lines to your configuration in the VirtualHost section:


RewriteEngine on

# Minor change to adjust for Cloud vs On-Premises API variation of parameter name
RewriteCond %{REQUEST_METHOD} PUT
RewriteCond %{QUERY_STRING} ^(.*)uid=(.*)
RewriteRule ^/profiles/photo.do /profiles/photo.do?%1userid=%2 [L]

# Added necessary CORS headers when Origin header present
Header unset Access-Control-Allow-Origin
SetEnvIf Origin "^https://(vop_server_hostname\.)?(domain_name)$" origin_is=$0
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is
Header always set Access-Control-Allow-Credentials "true" env=origin_is
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, slug" env=origin_is
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" env=origin_is

Header always set Access-Control-Max-Age "1000" env=origin_is
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" env=origin_is
# Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding, slug" env=origin_is
Header always set Access-Control-Allow-Headers "X-Requested-With, Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma, slug, X-Update-Nonce" env=origin_is
Header always set Access-Control-Expose-Headers "Content-Disposition, Content-Encoding, Content-Length, Date, Transfer-Encoding, Vary, ETag, Set-Cookie, Location, Connection, X-UA-Compatible, X-LConn-Auth, X-LConn-UserId" env=origin_is

# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* - [R=200,L]

# Remove the Origin header if it exists for other requests (POST, GET, DELETE, PUT). Causes problems with Connections returning 403 response.
RequestHeader unset Origin env=origin_is

....I would have never expected a RewriteRule to be the workaround for a 403 error but now I finally got my envoirnment running 😌


Keine Kommentare:

Kommentar veröffentlichen

Sometimes there is no next time, no second chance, no time out. Sometimes it is now or never.


- Alan Bennett