fix(index): add preHandler hook

[Fdawgs]

The documentation states that this plugin adds a preHandler hook but the code says otherwise.

I noticed this as I was registering @fastify/bearer-auth before @fastify/cors (which is an onRequest hook) and pre-flight requests were being caught by this plugin, and auth shouldn't be applied to them.

Checklist

• run npm run test and npm run benchmark
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[gurgunday]

Why not preValidation or preParsing for instance? We shouldn't validate anything if the auth isn't there in my opinion

[Fdawgs]

That also works, was just updating the handler to correctly match the documentation. Can be changed!

[gurgunday]

Yeah sure, I was just pointing it out :)

In any case, this would be a major right?

[jsumners]

The change happened in 78adb35

But I cannot find a corresponding issue to describe why it was done. It looks like @delvedor just did it.

[gurgunday]

Can we change it to preParsing if we're going to release a major?

[Fdawgs]

Can we change it to preParsing if we're going to release a major?

I think that would be best. I've just rejigged @fastify/auth's readme and it has this section that supports the use of the preParsing handler.

[climba03003]

I would update the document and make the hook configurable.

[Eomm]

While I do agree that this would be a major, I think the onRequest hook seems right to me.

Whenever we get a request, we want to ensure that it is a valid client to call us.
Example: I have an endpoint with auth configured, if I get a malicious payload of 1GB, with this change we will parse it!

So, reading the issue:

I noticed this as I was registering @fastify/bearer-auth before @fastify/cors (which is an onRequest hook) and pre-flight requests were being caught by this plugin, and auth shouldn't be applied to them.

Isn't switching the cors/auth plugins the solution?
Or at most: fix the documentation

[Fdawgs]

While I do agree that this would be a major, I think the onRequest hook seems right to me.

Whenever we get a request, we want to ensure that it is a valid client to call us. Example: I have an endpoint with auth configured, if I get a malicious payload of 1GB, with this change we will parse it!

I'm leaning more to making it configurable as climba suggested. Both onRequest and preParsing hooks should negate this.

[jsumners]

Seems fair. Make it configurable but default to onRequest.