Allow `Authentication` header to not be checked systematically

[AtomBaf]

From this line:

caddy-jwt/jwt.go

Line 294 in 9029841

candidates = append(candidates, getTokensFromHeader(r, []string{"Authorization"})...)

We can see that whatever the config is for the headers, the Authorization header will always be checked.
For some purpose, it might be necessary to have 2 different ways for authenticating, one with JWT in cookies, and another with Basic Auth. Playing with directive order does not help much, the only thing I would like is the ability to discard this line.

Thanks for helping. Love your plugin!

[ggicci]

Hey @AtomBaf , I didn't quite get your use case. The check of Authorization header always comes at the last. So it doesn't conflict with your checking JWT in cookies. Which means as long as the token provided in cookie is valid, the Authorization header won't get a chance to be checked. The only use case for this feature request I can think of is that you want to reject using a valid JWT token from the Authorization header. Did I understand correctly?

[AtomBaf]

Hi @ggicci
Sorry I'm probably not clear.
I have some http clients in front of caddy that will send requests containing only a Basic Autthentication header.
The plugin is configuread to look after a cookie to see if the JWT token is set. If not, the client will be redirected to the authentication portal to feed it. This portal will eventually use the basic authentication header, return a cookie and redirect back to the original URL. Then, ths pligin will get the cookie and continue...
The problem today is that when the first call arrives (without the cookie) the Authorization header comes last in the list of candidates and will trigger a parse error and log a warning. The plugin will then return a 401 which will lead to continuing the auth process.

So, my request is just to have a way to tell the plugin to never look at this header, this way avoiding the useless parsing and warning.

[ggicci]

The problem today is that when the first call arrives (without the cookie) the Authorization header comes last in the list of candidates and will trigger a parse error and log a warning. The plugin will then return a 401 which will lead to continuing the auth process.

Even we remove the check of Authorization header, the plugin still returns a 401 in this case. What am I missing?

[ggicci]

Ah, I see your point. The plugin itself works correctly, but the Authorization header check might be unnecessary — right?

Personally, I don't see it as a problem since the check is quite lightweight. In most cases, requests should already be authorized, meaning this check wouldn't even be triggered. That said, I do understand the request — it’s a nice-to-have feature.

If my understanding is correct, I’d suggest adding a boolean option here, perhaps something like NoDefaultCheckOnAuthorizationHeader. Please let me know your thoughts.

[AtomBaf]

You're right we will end with a 401 and everything will be fine at the end. Indeed this is a nice to have.
About your proposal that's exactly it. Another option could have been to set the default value of the From Header config with Authorization, but this would probably break a lot of existing configs.

[ggicci]

This would be a nice feature to have. I’d greatly appreciate it if anybody is willing to help with the code changes.