Reputation: 2881
I'm trying to understand what I am doing wrong for this basic example of using hapiJS to send CORS headers, allowing me to make XHR calls from another app.
I want to server a header like so, which I understand I would need to accept XHR calls as I outlined in the spec from the W3C
Access-Control-Allow-Origin: ["*"]
When I check the HapiJS docs on CORS support, I understand that I need to add a CORS key to the routing object like so:
const Hapi = require('@hapi/hapi');
const init = async () => {
const server = Hapi.server({
port: 3000,
host: 'localhost',
});
server.route({
method: 'GET',
path:'/',
handler: (request, h) => {
console.log('CORS request.info:');
console.log(request.info.cors);
return 'Hello world! Shis should be sending a CORS header.';
},
options: {
cors: true
}
});
await server.start();
console.log('Server running on %s', server.info.uri);
})
init()
The thing is, I don't see the Access Control Allow Origin header, when I pass in a cors:true
, nor when I pass in a more fleshed out object like this:
{
origin: ['*'],
maxAge: 86400,
headers: ['Accept', 'Authorization', 'Content-Type', 'If-None-Match'],
exposedHeaders: ['WWW-Authenticate', 'Server-Authorization'],
credentials: true
}
What am I missing to get CORS support working here?
As I read the spec, you shouldn't need to pass the 'Origin' header in every request - this is a decision you would make depending on the resource you're exposing
This specification defines how to authorize an instance of an application from a foreign origin, executing in the user agent, to access the representation of the resource in an HTTP response. Certain types of resources should not attempt to specify particular authorized origins, but instead either deny or allow all origins.
A resource that is not useful to applications from other origins, such as a login page, ought not to return an Access-Control-Allow-Origin header. The resource still must protect itself against CSRF attacks, such as by requiring the inclusion of an unguessable token in the explicitly provided content of the request. The security properties of such resources are unaffected by user-agents conformant to this specification.
A resource that is publicly accessible, with no access control checks, can always safely return an Access-Control-Allow-Origin header whose value is "*".
A GET response whose entity body happens to parse as ECMAScript can return an Access-Control-Allow-Origin header whose value is "*" provided there are no sensitive comments as it can be accessed cross-origin using an HTML script element. If needed, such resources can implement access control and CSRF protections as described above.
My use case - making an end point accessible to anyone, without needing any authz/authn seems to satisfy case 2.
What else do I need to do?
Upvotes: 1
Views: 3222
Reputation: 2881
Okay, the resolution for me was to add the cors info on the server, not the route.
So, I had to add to the server declaration like so, and remove it from the route:
const server = Hapi.server({
debug: { request: ["*"], log: ["*"] },
port: 3000,
host: "localhost",
routes: { cors: { origin: "ignore" } }
// this also worked
routes: { cors: { origin: ["*"] } }
})
I'm still not sure how I'd make this work on a per route basis, which is my preferred setup, but this works for the time being.
Upvotes: 3