4

I'm working on an AngularJS app that uses Domino as a backend. Since I want more customization options than Domino Access Services (DAS) gives me, my next choice was the REST Service from the Extension Library.

The app is running on a separate domain from Domino, so I need to add CORS headers to make that scenario work. With CORS, the browser (for some requests) first makes a preflight HTTP OPTIONS request to the server to check what methods are allowed (more on CORS here: http://www.html5rocks.com/en/tutorials/cors/).

The problem I now run into is that Domino throws a Method Not Allowed error (response code 405) on that OPTIONS request. I already added it to the list of allowed methods in my internet site document (although I'm not sure if the REST service will honor that at all). The request comes through fine with DAS.

Looking at the source code of the RestDocumentJsonService in the Extension Library it seems that the OPTIONS method isn't supported at all.

Any thoughts on how to make this work? Or for a workaround? I know that I can write my own servlet or install a proxy in front of Domino, but I don't want to go that route (yet ;-)

Mark Leusink
  • 3,747
  • 15
  • 23
  • Have you tried to overwrite the content type of the POST request to 'application/x-www-form-urlencoded', 'multipart/form-data', or 'text/plain'? This prevents browsers from sending a preflight request. – Sven Hasselbach Apr 07 '15 at 08:57
  • That doesn't work (for the `xe:restService` component): it throws an error saying that the Content-Type has to be `application/json` (for POST requests, as well as PUT and PATCH). – Mark Leusink Apr 07 '15 at 11:19
  • 3
    If you really want to add the OPTIONS method in the RestDocumentJsonService, you could extend it overriding only what you needed and then use it as a custom Service in the Extension Library's Rest Service – Toby Samples Apr 07 '15 at 19:03
  • I'll explore that a bit. It does mean that I can't simply use one of the configurable REST services, set (for example) the correct view and be done :( – Mark Leusink Apr 08 '15 at 11:42

2 Answers2

3

If you are trying to use Authenticated CORS you will need minimum four headers to work

Access-Control-Allow-Credentials: true
access-control-allow-header: X-Requested-With, Origin, Accept, Accept-Version, Content-Type
access-control-allow-method: OPTIONS, GET, PUT, POST, DELETE, PATCH
access-control-allow-origin: http://yourOtherDomain.com

Unfortunately you can only add 3 headers through the Web Site documents

You cannot add anything through a Phase Listener because the ExtLib Rest Services do not go through the XSP Phases

You can use a proxy such as nginx or in my case I used IHS

http://xomino.com/2014/04/20/adding-custom-http-headers-to-domino-r9-using-ibm-http-server-ihs/

Or you can just roll your own REST service and add whatever headers you want

MarkyRoden
  • 1,074
  • 6
  • 21
  • 1
    A Proxy Services is not needed. You can add headers to the `xe:restService` components using a `PhaseListener`. The services will trigger the `RESTORE_VIEW` phase. – Mark Leusink Apr 08 '15 at 11:39
  • @MarkLeusink Could you explain a bit about how you can authenticate in this way ? I don't get how you can post to an xpage (etc) and apply your credentials via ajax - thanks (forgive me if my question makes no sense; I'm finding my way with this stuff) – user2808054 Jun 01 '16 at 16:43
  • There is, since 9.0.1 FP6 an option to add another fourth header to all website rules via notes.ini paramter "HTTPAdditionalRespHeader=", see http://www-01.ibm.com/support/docview.wss?uid=swg21984240 – Tschenser Jul 10 '17 at 16:14
  • Thanks for the update - I do appreciate you taking the time to let me know. – MarkyRoden Jul 11 '17 at 21:12
0

Mark, just a quick comment. I am not sure if this would work for you.

But what I do in a current project is to put the Angular app in the WebContent folder of the NSF. This serves several purposes - one of them being ease of deployment with the right version of the backend code in the same NSF. I have set the database up for source control and edit the Angular part directly in the on-disk project of the NSF and just sync them when I need to run it. As a side effect this setup will also solve any CORS issues as client side code is launched from the same domain as my REST service is called from ;-)

/John

John Dalsgaard
  • 2,797
  • 1
  • 14
  • 26
  • Hi John. Thanks. That would work of course, since I don't have to deal with CORS anymore. But... I want to try to make this work with separate domains and with CORS. I think it makes much more sense to host the Angular app on a separate server in this scenario. – Mark Leusink Apr 07 '15 at 07:11
  • Hi Mark, well I thought so... (as I indicated) ... and it makes good sense :-) – John Dalsgaard Apr 07 '15 at 11:10