Generate function never called when Vision route has CORS enabled

[hapijs]

Generate function never called when Vision route has CORS enabled

[hueniverse]

I'm not following the flow. Why are vision routes acting differently?

[stongo]

sorry @hueniverse you're right, it's not limited to vision routes, but to any route being access directly from browser when CORS is enabled.

so if CORS is set globally and one tries to access a route directly in browser for example, request.info.cors.isOriginMatch is always going to be false because the origin header isn't there.

this makes it so that a route can't be used in both CORS and non-CORS contexts when using crumb. maybe this is okay though, and I just need to clearly state that in crumb readme?

[hueniverse]

Directly you mean CURL?

[stongo]

CURL or in a browser

Here's the headers from chrome dev tools from a Vision route with CORS enabled

Request URL:http://localhost:8001/
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:8001

Response Headers
cache-control:no-cache
Connection:keep-alive
content-encoding:gzip
content-type:text/html; charset=utf-8
Date:Tue, 09 Aug 2016 18:02:02 GMT
Transfer-Encoding:chunked
vary:origin,accept-encoding

Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:localhost:8001
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

vs

curl -vv -H "origin: http://localhost" 127.0.0.1:8001
* Rebuilt URL to: 127.0.0.1:8001/
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8001 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:8001
> User-Agent: curl/7.43.0
> Accept: */*
> origin: http://localhost
>
< HTTP/1.1 200 OK
< vary: origin
< access-control-allow-origin: http://localhost
< access-control-expose-headers: WWW-Authenticate,Server-Authorization
< set-cookie: crumb=xxxxxxxxxxxxxxxxxxxxxxxx; HttpOnly; Path=/
< cache-control: no-cache
< content-type: text/html; charset=utf-8
< content-length: 1638
< accept-ranges: bytes
< Date: Tue, 09 Aug 2016 17:38:16 GMT
< Connection: keep-alive
<

[stongo]

If I disable CORS for the same route, then crumb generate is called and crumb works as expected.

This came up when I was debugging someone's setup where the crumb cookie wasn't being set or added to the view context, and it was because CORS was enabled globally

[hueniverse]

Why isn't the browser sending the CORS headers?

[stongo]

I don't know honestly. Probably the root issue. I'll dig in to that

[stongo]

@hueniverse the browser will never use CORS for a single api request or for an initial html page as served by a Vision route for example.
"A resource makes a cross-origin HTTP request when it requests a resource from a different domain than the one which the first resource itself serves" - https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
So that explains a route not being able to qualify a valid CORS request vs a same-origin request, as currently implemented.
I'm wondering if the lack of a origin header is enough to confirm it's a same-origin request in the context of crumb, but need to dig in to the implications of that a bit more.

[stongo]

this page outlines when the header origin is served https://wiki.mozilla.org/Security/Origin

[hueniverse]

I think that's the right change. Enforce CORS where Origin is present.

[stongo]

Closed by a11b358

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.