Another suggestion - provided by@althaus:

What if the listener would add a info/warning to the log before converting it instantly into a HttpEx? Like "Hey there's no entry point set, so I make this an error now. You could set the.config.value to change my behaviour."

cc@weaverryan do you have an opinion on how to handle this? (you're often better in recognizing the difference between "too magic" and "DX-friendly" than I am)

My first impression was: yay! But... when I think further, I realize that eventually, you might have ugly config like this:

main:form_login:~entry_point:form_logincustom_authenticators:services:[App\Security\CustomAuthenticator, App\Security\AnotherCustomAuthenticator]entry_point:App\Security\CustomAuthenticator

In this case, theform_login entrypoint would win... which is fine, but it means that theentry_point config undercustom_authenticators is 100% pointless 🙃 . I really don't like that.

So, I can think of 2 options:

1. On a missing entrypoint, we throw a better exception - basically the suggestion from@althaus. Though... instead of registering a listener to do this, the "authenticator" system could add a "dummy entrypoint" service to the system that would throw this error when called. The idea would be that if (A) you have at least onecustom_authenticator then the dummy entrypoint is added and (B) if you haveno other authentication mechanisms, then it would be used (and you would see the error).

2. Or... probably do (1), but also go a step further. If there is ONEcustom_authenticator (that is an entrypoint), then we automatically register that as an entrypoint. If there are no other authentication mechanisms that provide an entrypoint, it will be used. Yay! As soon as there are TWOcustom_authenticators (that have an entrypoint), then we register the fake entrypoint described in (1) and tell people to configure the top-levelentry_point under the firewall. We can even tell them what their options are (i.e. list the 2/3/4 custom authenticator service ids).

So... probably 2 is best. In both cases, I'd like to avoid theentry_point that's belowcustom_authenticators as this is really a duplicate of theentry_point that's under the firewall (and this was my mistake from the original Guard implementation).

@weaverryan 2 notes and that's why I think improving the log message is the best we can do:

• It's perfectly fine to not have an entry point. This will result in an HTTP Unauthorized response, which is perfect for e.g. APIs
• An authenticator does not have to implementAuthenticationEntryPointInterface. So we can't blindly register any authenticator configured usingcustom_authenticators

Closing, see my previous comment on why I no longer believe this PR can ever work. I'll create another one that improves logging.