Order of execution about auth_handler

[Chida82]

At present, the Auth handler always runs the core/standard version first and the custom version afterwards.
This is the case for the auth_handlers list, which is fixed.

I propose to make the order dynamic.

At the moment, it is possible to use hook factory_allowed_auth_handlers which allows hanging to another list. Now we could not only hang but put before or reorder this list.

My proposal is to apply before or after Core Auth depending on whether the list_auth_handler_default contains the CoreOnlyAuthConfig element first or not.
In some cases it may be more efficient to run the custom version first.
What do you think, can I develop it, would you accept this implementation? I understand I am not the only one who did not expect different behaviour for the 2 lists
ps: it would also be a step to consider disabling the custom version in the future, but that is not the point of the discussion at the moment!

[lucagobbi]

This proposal touches some discussions we’ve had regarding similar issues with the new auth system

Atm, when writing a custom auth handler, you need to lock your instance with two API keys (for http and ws) and a secret for JWT. While this setup may be somewhat opinionated, it’s a necessary part of the current system. This could be clarified better in the documentation

Regarding the execution order of the auth handlers, I understand why you'd want more flexibility. However, in my view, the order is usually less relevant because you are unlikely to use the same keys or tokens for different auth handlers. When a custom handler is implemented, the core handler typically fails since it lacks the necessary credentials, allowing the custom one to take over

More interesting, imho, is the possibility of overriding the entire list of allowed auth handlers. This would allow users to specify only custom handlers. Be aware that this would also exclude the admin panel, which relies on the default core auth handler for authentication. But you only have to worry about your own auth and don't have to manage the internal keys

[Chida82]

also in my opinion it should tend to be possible to have only one way of authentication and in the case of the custom, obviously knowing that I am going to lose admin and other tools, but if I dispense as a service, in my case I don't need the admin part, which I use in development or attack on the data, but I don't expose. the part exposed as a service I like more performance and lighter.
In any case my proposal is to take a step, more in terms of performance, by changing the sorting option, because if I have an authentic custom it is because that is what I will use in 99% of calls

Translated with DeepL.com (free version)

[pieroit]

I propose to make the order dynamic.

@Chida82 let me clarify

The list factory_allowed_auth_handlers is the list from which an admin choses the custom_auth_handler, only one, from the admin or via endpoint; that custom AuthHandler is run on the side of the core_auth_handler. So there will always be:

• a core_auth_handler, instance of CoreAuthHandler (you cannot change it or disable it from the hook)
• an additional custom_auth_handler, chosen from the list in factory_allowed_auth_handlers. If you chose no custom auth, CoreOnlyAuthHandler just blocks everything. If you add via plugin and setup a custom handler, for example a simple JWT validator, that auth handler will run alongside the core one above. A great example is the Catcloak plugin by @lucagobbi to have Keycloak as identity provider.

So to recap, there are 2 handlers: core, always present and a custom one you can choose form a list.

The CoreOnlyAuthConfig (mapping to CoreOnlyAuthHandler) is there just as a placeholder in case no custom auth is chosen; in fact it does not allow any request.

My proposal is to apply before or after Core Auth depending on whether the list_auth_handler_default contains the CoreOnlyAuthConfig element first or not. In some cases it may be more efficient to run the custom version first. What do you think, can I develop it, would you accept this implementation?

Having the custom_auth_handler run before core_auth_handler can be done, agree it is more efficient in most production setups. I hope it is clear that this has nothing to do with the hook, because the hook only allows to list the available custom auth handlers.
You can make a PR about this, just change the order so the custom auth goes first. Please use the develop branch.

I understand I am not the only one who did not expect different behaviour for the 2 lists ps: it would also be a step to consider disabling the custom version in the future, but that is not the point of the discussion at the moment!

There have been lots of discussions about this, and the most debated point was to have a custom auth without sacrificing the admin and a basic auth configuration. So now there is a core auth and a custom auth, side by side. I wanted to have a simpler hook just to list and run all auth handlers, Django style, but community decided it was "dangerous".

Let me know if everything is clear and thanks @lucagobbi for helping the clarification

P.S.: As Luca says, core auth must be secured with env variables in any case, because it will run in parallel with your custom auth
P.P.S.: hopefully in V2 we can simplify this system, it's the best so far

[Chida82]

Thank you for the clarification, it took me several hours to understand these concepts, they were not natural to me and even less so having to configure the core ocn keys not to use it. I recommend putting it into docuemnation in a clear and even redundant way :) .

I can do PR, but I wanted to understand first what would be appreciated. Since the two lists are not closely related, I would say not to follow my first suggestion. However I think it is useful to have a setting to drive the approach, in development it is useful to have the core first, also because you could make big mistakes in custom auth development and you would block admin portal. What do you think of an enviroment key? Something like ccat_Auth_custom_first where by default it is false

[pieroit]

Thank you for the clarification, it took me several hours to understand these concepts, they were not natural to me and even less so having to configure the core ocn keys not to use it. I recommend putting it into docuemnation in a clear and even redundant way :) .

Yes can be greatly simplified, let's see for V2. Documentation has several warnings about this

I can do PR, but I wanted to understand first what would be appreciated. Since the two lists are not closely related, I would say not to follow my first suggestion. However I think it is useful to have a setting to drive the approach, in development it is useful to have the core first, also because you could make big mistakes in custom auth development and you would block admin portal. What do you think of an enviroment key? Something like ccat_Auth_custom_first where by default it is false

If the first handler (the custom one) blocks everything, still the core one will allow access.
I agree on having custom auth handler go first, another env variable seems overkill

[pieroit]

@Chida82 attention in develop and also coming soon to main we have the AuthHandler's methods all sync (see #973 )
Since we run all calls in threadpool, the hassle was not worth it

TLDR: change your auth handlers so they are sync