3

I'm attempting to communicate with Domino via REST via a cross domain request, but I'm encountering an issue. I've setup an Internet Site document with the IP Address, localhost and a server name listed as the host names. The internet site is working as a redirect rule I've setup on that internet site is working. I've also setup a Web Site Rule with the following:

Web Site Rule

Now when I attempt to hit the rest.xsp page via an html GET request I'm getting this error:

    XMLHttpRequest cannot load 
http://192.168.1.104/testing/restService.nsf/rest.xsp/testRest?reqType=UserCanAc…TOP&startId=BA4241EC74912860ED60FD1123473BF7&returnType=ARRAYOBJECTS. 
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 
'http://127.0.0.1:8020' is therefore not allowed access.

Here are the request headers:

Accept:application/json, text/javascript, */*; q=0.01
Cache-Control:max-age=0
Origin:http://127.0.0.1:8020
Referer:http://127.0.0.1:8020/Backbone%20Playground/index.html
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

I can't for the life of me figure out what I've missed. Can someone point me in the right direction?

keithstric
  • 1,053
  • 1
  • 11
  • 21

3 Answers3

3

The CORS header is part of the response, so you need to check if you get a CORS response header with your page. In any case, for an XPage you can get direct access to the servlet response object and set the header in your XPage:

   var externalContext = facesContext.getExternalContext(); 
   var response = externalContext.getResponse();
   response.setHeader("Access-Control-Allow-Origin","*");

You want to replace the * with a little more restrictive setting. Cors doesn't work in all browsers, so you need to check that end too.

stwissel
  • 20,110
  • 6
  • 54
  • 101
  • 1
    My experience, FWIW: As of 9.0.1, when using the control, this technique doesn't seem to work. Neither can I find a "response headers" property nor does adding the header as a Metadata resource. – Grant Lindsay Dec 06 '14 at 03:53
  • You need to add it in code. A rest control is its own URL. Meta data you add to the page has no effect. – stwissel Dec 06 '14 at 03:56
  • What do you mean by, "add it in code"? If you mean the SSJS that is shown in the above answer, I could not get this to work. If you mean something else, can you explain further? If I can't get this to work, I'll switch to a "plain" XAgent design. – Grant Lindsay Dec 08 '14 at 19:53
  • Your TestRest needs to be JavaScript or Java, the ready baked methods won't do it. What is interesting.... why is the website rule not working? What **response** headers do you get in either cases (might be by design) – stwissel Dec 09 '14 at 01:45
  • I did try this recommendation - didn't help. ( – AndrewG10i Dec 26 '14 at 22:27
2

I think your configuration is fine and you can test it using CURL . You should be able to see the Custom Headers by checking any URL different to the one you're using.

The problem, maybe, is due to the XPages Extension Library control, REST Service, you're using. I think the "HTTP response headers" are not applied for this control. I've tested it in Domino 8.5.3

Community
  • 1
  • 1
Miguel Calvo
  • 31
  • 2
1

I know this is kinda old thread but since it's not being answered and there are some news, I think it's worth throwing in my own findings.

  1. Mark Leusink caved into this and discovered that there's a need to accept also return code 204 for GET and 201 also for any write (PUT / POST) operations
  2. There is now a new possibility to include a fourth Response Header to all website rules by the means of notes.ini parameter "HTTPAdditionalRespHeader=", see this technote

However, I'm also struggling on completing a CORS task currently, because Domino always responds with an 401 to the preflight (which seems clear as it comes unauthenticated, at least within Chrome).

Tschenser
  • 347
  • 3
  • 15