marklogic-community
middle tier - ensure CORS set properly for front-end requirements.
This is where I'll need a little more help understanding the functional requirements. It seems CORS is not necessary for EA-2 though, since the proxy method will work.
It looks like you may have CORS set up already. That said, proxy will take care of it. Don't worry about it for ea2.
I have headers ready, but the values in them were cribbed from some blog post.
Hi Stu, did you verify that the CORS headers are set correctly? I never researched what needed to be done here, but followed some script. If the headers are as needed, then I'll claim victory on this ticket. Here's the relevant code:
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods",
"POST, PUT, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers",
"x-requested-with, content-type");
Last time we checked I think they didn't work correctly and you turned them off. No? My memory on this is hazy. Should I check again? I can turn off proxying in the browser dev code and point straight at the Java server from the browser if you think it should work.
Well, if I understand what it's supposed to do I'll check -- this is so that, if I configure the angular app to use 8090 for REST services, but is served from 3000, it will work. Otherwise I'll get some kind of error message... ?
Yes, otherwise the browser will refuse to make requests to the REST server.
The last time we had CORS enabled endpoints refused to work altogether if I remember correclty -- that is to say, the middle tier didn't even work with a generic REST client when the client wasn't even concerned with CORS restrictions. If you get the CORS headers and the endpoints continue to function for you in something like CURL then we're making progress.
I get 401 Unauthorized when the OPTIONS request from the browser for CORS is attempted.
OK, I've looked into CORS somewhat -- what I'm seeing. I've cribbed a very simple CORS implemenation, basically wide-open, but I'm curious what other requirement I'm missing...
WIth every request, 401 or not, I'm getting back some headers that specify the CORS configuration. I'm not sure what else is needed.... would you expect OPTIONS to be a 200 on all the endpoints?
(In other words, I think the headers are OK, the body and response are just falling through to an unauthorized handler anyhow -- I think this part is very fixable).
It would still help to understand where to configure the browser so i can see the interactions; I just don't have any experience with this stuff at all
would you expect OPTIONS to be a 200 on all the endpoints
Yes.
I need to add configurability. I thought it was there but it wasn't. (Doh! I had added a comment that I needed to do it but hadn't done it yet!)
This line let's you force it: https://github.com/marklogic/marklogic-samplestack/blob/676d998e64a7b36935a406ecc140d4f52397b199/browser/src/_marklogic/services/data/mlModelBase.js#L130
MlModel.prototype.getBaseUrl = function () {
// return '/v1'; // TODO should come from config setting
return 'http://localhost:8090/v1'; // TODO should come from config setting
};
curl -X OPTIONS -i http://localhost:8090/v1/tags
HTTP/1.1 200 OK
Date: Thu, 22 Jan 2015 00:16:16 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, GET, OPTIONS, DELETE
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: x-requested-with, content-type
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-CSRF-HEADER: X-CSRF-TOKEN
X-CSRF-PARAM: _csrf
Set-Cookie: JSESSIONID=17exr0al7zoyw1nzb5invgkv49;Path=/
X-CSRF-TOKEN: 28abf11a-e1d1-4771-8e1e-bee74a82419a
Content-Length: 29
Server: Jetty(9.2.4.v20141103)
{"status":200,"message":"OK"}
Does this
Access-Control-Allow-Headers: x-requested-with, content-type
need to have the CSRF headers in it too? Is that what this is for?
I think I'm in good shape :) my login failed because of csrf. curious about the above question but will make a commit that fixes this.
The browser would need CORS support on the GET v1/session call, if that's what you're asking.
If CORS is on it should be on for all endpoints (w/OPTIONS on all endpoints, including GET /v1/session).
Theoretically you could restrict CORS to just localhost:3000 instead of *. Is that part configurable or buried in code. For prod deployments * probably isn't what people would want....
I don't have your CSRF branch merged yet, so my OPTIONS failure probably wasn't related to CSRF, FYI...
That's understood (configurability of hosts). I'll make sure that's well documented, that is, that the CORS support in this middle tier is sample code at the moment.
It's pretty clear how to take this code from where it is to a better spot though, so maybe we can get that done.
on CSRF, yes, that's understood. I was trying to login to my csrf-enabled middle tier, with expected ungood results.
You can add. Please just leave a note in cases where you do, so that it's clear that the target moved :smile:
Charles to push code to separate branch for Daphne to look at // Charles to clean it up