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:
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?
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.
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
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.
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
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).
Related
I have a project, It's a web application that requires Windows Authentication.
I've setup an Active Directory at home using my NAS virtualization. Then I've created a VMWare Server for IIS which is a member of that domain on my desktop which I also use for development. I've created the Web API and installed it into that VMWare server. When I call a routine directly, it works and return results but when I use the Web API routine from my javascript web application I keep on getting 401 error. I then put the code on the IIS server and the web application works.
I've seen a lot of solutions like changing the sequence of the Provider in IIS Authentication. Added Everyone read/write permission on the folders. I've also added entry on the web.config. But none of them work.
*****Update as per request on the comment *****
Below is when I run directly from Web API
Calling the Web API from Javascript
Here's the error I'm getting
Just FYI, I tried running the web api from Visual Studio on the same machine but also with 401 error
Is there anything I could add to AD to make my development machine as trusted?
********************A new issue after the code change **********
****************Another Update******
This is definitely weird, so I installed Fiddler 4 to see what's going on. But still no luck.
Then I made changes on the IIS HTTP Response Header
The weird thing is when I run Fiddler the error is gone but when I close it it comes back.
There are two things going on here:
A 401 response is a normal first step to Windows Authentication. The client is then expected to resend the request with credentials. AJAX requests don't do this automatically unless you tell it to.
To tell it to send credentials in a cross-domain request (more on that later), you need to set the withCredentials option when you make the request in JavaScript.
With jQuery, that looks like this:
$.ajax({
url: url,
xhrFields: {
withCredentials: true
}
}).then(callback);
These problems pop up when the URL in the address bar of the browser is different than the URL of the API you are trying to connect to in the JavaScript. Browsers are very picky about when this is allowed. These are called "cross-domain requests", or "Cross-Origin Resource Sharing" (CORS).
It looks at the protocol, domain name and port. So if the website is http://localhost:8000, and it's making an AJAX request to http://localhost:8001, that is still considered a cross-domain request.
When a cross-domain AJAX request is made, the browser first sends an OPTIONS request to the URL, which contains the URL of the website that's making the request (e.g. http://localhost:8000). The API is expected to return a response with an Access-Control-Allow-Origin header that says whether the website making the request is allowed to.
If you are not planning on sending credentials, then the Access-Control-Allow-Origin header can be *, meaning that the API allows anyone to call it.
However, if you need to send credentials, like you do, you cannot use *. The Access-Control-Allow-Origin header must specifically contain the domain (and port) of your webpage, and the Access-Control-Allow-Credentials must be set to true. For example:
Access-Control-Allow-Origin: http://localhost:8000
Access-Control-Allow-Credentials: true
It's a bit of a pain in the butt, yes. But it's necessary for security.
You can read more about CORS here: Cross-Origin Resource Sharing (CORS)
I've got a Web app on Django that makes a bunch of asynchronous calls to the server.
It works perfectly well from all browsers except Safari, specifically on iOS where users are reporting at least an intermittent problem.
It seems the problem might stem from Safari sending an OPTIONS request. This is a snippet from the Apache log (edited for anonymity):
172.31.34.143 - - [20/Jun/2017:14:12:46 +0100] "OPTIONS /asyncservice/ HTTP/1.1" 500 245 "http://www.example.com/app/" "Mozilla/5.0 (iPhone;
CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like
Gecko) Version/10.0 Mobile/14F89 Safari/602.1"
Has anyone experienced this, and is there a solution?
I may have solved this.
There is a request header set by the JavaScript that sends the Django CRSF ( Cross Site Request Forgery) protection header.
Safari sees this header, doesn't recognise it and sends what is referred to as a preflight request, the OPTIONS request.
Apache refuses this request on the grounds that Safari has not sent the correct origin over with the OPTIONS request (why it doesn't is hazy - it looks to me like a bug in Safari, really.)
Safari gets a 500 and concludes the POST request is fraudulent and refuses to make it.
Given the reason that the request is made is because Safari doesn't recognise the Django CRSF header, allowing Apache to receive from any origin and trusting Django to handle the bad requests with CRSF seems reasonable.
So, I've configured Apache to allow from any origin, like this:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
So far, none of these 500s since, but its early days.
If I have configured Access-Control-Allow-Origin: http://mydomain correctly, should it be listed in the response headers if I view them using the web developer plugin? I don't see it. Should it be there?
I have tried viewing the response headers after submitting my post request, and just calling the page.
Background
I need to transfer a couple of values from mydomain to receivingdomain via XMLHttpRequest POST request and am trying to troubleshoot
XMLHttpRequest Page1.asp cannot load https://receivingdomain. No Access-Control-Allow-Origin header is present on the requested resource
If I turn on the Allow-Control-Allow-Extension plug-in my post requests work correctly. However, when this plug-in is disabled, my post requests are being received ok (the data is inserted into the database) - I'm just not getting any result back from the receiving server.
I'm trying to get Wireshark output that is as close as possible to using a browser
manually, via wget or urllib.
The output is different, and I was wondering why, and how do I overcome this?
Thanks!
wget is used primarily to grab whole or partial web sites for offline viewing, or for fast download of single files from HTTP or FTP servers instead.
A browser request contains HTTP headers like User Agent, Referer, etc.
If you want to mimic wget to a browser like request, you can pass HTTP headers with your wget request.
Something like this-
# wget http://www.remote.co.in/images/myimage.jpg --header="User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0" --header="Accept: image/png,image/;q=0.8,/*;q=0.5" --header="Accept-Language: en-US,en;q=0.5" --header="Accept-Encoding: gzip, deflate" --header="Referer: http://www.mywebsite.com"
There are a couple things...
A browser:
May have several specific headers (useragent, cookies, referer, misc. pplugins, no-track)
Requests all child elements/scripts/resources, possibly on the same connection (keep-alive)
May request gzipped datastream in return
WGet:
Has minimal headers by default (useragent), but can use/alter others with parameters
Is generally a 1-off, requesting only the main html only and not its child resources
It may be if you are seeing different main HTML that the site is server-side scripting tailored content based on useragent and/or cookies (e.g. "logged in")
I'm working on a chrome app and finally got to the point of issuing a PUT to the node.js server. My GET logic is working fine. My PUT however gets hijacked into a OPTIONS request. My requests are made to
http://localhost:4000/whatever
I read about the OPTIONS pass asking permission to do the PUT. I was under the impression that BROWSERS issue OPTIONS when CORS is requested, but didn't realize that a chrome app would also do this for me.
Is the app doing this because I didn't and I'm supposed to, or is this SOP that chrome will issue the OPTIONS request and I just issue my PUT that triggers it?
My PUT never makes it to the server. I've tried issuing my own OPTIONS just ahead of my PUT but so far nothing is working. The OPTIONS request makes it to the server (the default one or mine), but that's the end of the conversation.
At the server, all I'm doing to satisfy the OPTIONS request is as follows:
case 'OPTIONS':
res.writeHead(200, {'Access-Control-Allow-Methods': 'OPTIONS, TRACE, GET, HEAD, POST, PUT',
'Access-Control-Allow-Origin': "*"});
break;
When I try issuing my own OPTIONS & PUT requests, I'm doing them with separate XMLHttpRequest objects. I don't see where the permission hand off from OPTIONS to PUT is made.
This is called "preflighting", and browsers MUST preflight cross-origin requests if they fit specific criteria. For example, if the request method is anything other than GET or POST, the browser must preflight the request. You will need to handle these OPTIONS (preflight) requests properly in your server.
Presumably, your page is hosted on a port other than 4000, and the call to port 4000 is then considered cross-origin (in all browsers other than IE). Don't issue the OPTIONS request yourself. Chrome will then preflight your request. Your server must respond appropriately. The browser will handle the response to this OPTIONS request for you, and then send along the PUT as expected if the OPTIONS request was handled properly by your server.
There is an excellent article on Mozilla Developer Network that covers all things CORS. If you plan on working in any cross-origin environment, you should read this article. It will provide you with most of the knowledge necessary to understand the concepts required to properly deal with this type of an environment.