[5.0.0] new version giving preflight errors about fastify-cors HOT 13 CLOSED

@codyzu ptal

from fastify-cors.

your regex is not good, use:

new RegExp(/http:\/\/localhost/)

from fastify-cors.

RegExp should handle the escaping correctly, no?

console.log(new RegExp('http://localhost'))
// prints:  /http:\/\/localhost/

Which should turn it into: origin: /http:\/\/localhost/

from fastify-cors.

you wrote:

   origin: new RegExp(/http://localhost/),
// not 
   origin: new RegExp('http://localhost'),

from fastify-cors.

oh my bad, that was a copy/paste error for the reproduction on my end. I actually use an ENV variable to fill the RegExp. I edited the reproduction above.

from fastify-cors.

I can't reproduce this on my machine with fastify-cors 5.0.0.

Can you copy the request and response headers for the OPTIONS request in the chrome dev tools network tab (right-click on the OPTIONS request and copy the request/response headers)?

fastify-cors does not return 401, so I would be suspicious of the authentication plugin. What are you using for auth?

from fastify-cors.

Hmm you are right, I found the issue in my own preHandler hook that does the authentication. I was using req.context.config to figure out which route is being called.
This now differs in version 5.0.0 (maybe intentionally? should I be using a different Fastify method to get this?)

4.1.0:

fastify.addHook('preHandler', (req, reply, done) => {
   console.log(req.context.config)
   // { url: '/api/login', method: 'POST' }
})

5.0.0:

fastify.addHook('preHandler', (req, reply, done) => {
   console.log(req.context.config)
   // { url: '*', method: 'OPTIONS' }
})

from fastify-cors.

req.routerPath and req.routerMethod would be the official way to check which router is handling the route (in place of req.context).

The problem you are most likely seeing is that in fastify-cors 5.0.0 processing of a preflight request is done in a route: OPTIONS * and you should not enforce authentication on that route. Try adding this to your preHandler hook:

fastify.addHook('preHandler', (req, reply, done) => {
   // Don't authenticate preflight requests
   if(req.routerPath === '*' && req.routerMethod === 'OPTIONS') {
      return done();
   }

   // Your authentication code ...
})

It could also be resolved by not having a global preHandler hook for authentication and instead authenticating only the routes or plugins that require authentication.

@mcollina I believe this is a side effect of moving the preflight handling into a route (previously the response would have been handled in fastify-cors onRequest hook). Consumers need to be careful not to enforce authentication on the preflight route... Do you see this as a problem? I can add an example in the docs 🤔

from fastify-cors.

In theory, a cors OPTIONS request should include all headers needed for auth/what would be included in the original request. It should be ok to perform auth for those requests.. could you do a quick check with a browser for both jwt and cookie based solutions?

from fastify-cors.

thanks for the pointer to req.routerPath, I've added the preflight skip to the code on my end for now

from fastify-cors.

For simple CORS requests (requests that don't require pre-flighting), the headers are included.

For preflight requests (the CORS OPTIONS request), the browser removes the original request headers. Instead, it includes the name of the headers in Access-Control-Request-Headers header, but not the values. See here.

I tested this with JWT, but not yet cookies. In any case, it seems like it will continue to create problems for anyone who authenticates all requests.

from fastify-cors.

@DRoet this should be resolved with the 5.1.0 release of fastify-cors, returning the pre 5.0.0 behavior and removing the need to not authenticate OPTIONS requests. With the default options, fastify-cors should now automatically reply to preflight requests before the authentication plugin.

AFAIK this can be closed.

from fastify-cors.

thanks!

from fastify-cors.