Tip for multiple authentication mechanisms

[chapay]

In the Form login chapter of the Cookbook there is an example of security.yml configuration:

# app/config/security.yml
security:
    # ...

    firewalls:
        default:
            anonymous: ~
            http_basic: ~
            form_login:
                login_path: /login
                check_path: /login_check

In this example two different authentication methods are used in the same firewall. There was a small section in book/security/authentication.rst with the following explanation:

When the user is not authenticated and if there is more than one authentication mechanisms, Symfony2 automatically defines a default entry point (in the example above, the login form; but if the user send an Authorization HTTP header with wrong credentials, Symfony2 will use the HTTP basic entry point).

But in this commit it was deleted and now I can't find anything about the behavior of such configuration in Symfony documentation. This example is a bit confusing for novices, so it will be great to restore a small tip about how it works.

[javiereguiluz]

@chapay thanks for reporting this missing explanation. I agree that it should be restored. But before doing that, I'd like to ask something: the explanation says that, in this case, Symfony picks the login form as the default auth mechanism. Why?

[wouterj]

I've just tested this code in a local test project with exactly the same config as in the cookbook article. Secured path is /demo and username is admin and password is adminpass. The results:

curl --header "Authorization: Basic YWRtaW46YWRtaW5wYXNz" 127.0.0.1:1234/demo
Result: Access is allowed (correct authorization header)
As expected

curl --header "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" 127.0.0.1:1234/demo
Result: Access is not allowed (incorrect authorization header) and redirected to /login
Expected result: Access is not allowed, fallback to http basic

curl --header "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" -u admin:adminpas 127.0.0.1:1234/demo
Result: Access is not allowed and redirected to /login
Expected result: Access is allowed (incorrect Authorization header, but correct values for http basic)

curl -u admin:adminpass 127.0.0.1:1234/demo
Result: Access is allowed (correct credentials for http basic)
As expected

curl -u admin:wrongpass 127.0.0.1:1234/demo
Result: Access is not allowed and redirected to /login
Expected result: Access is not allowed

Conclusion: The code seems to no longer work as described in the quoted paragraph. It seems to always use form login, except when there is no Authentication header sent and the HTTP basic credentials are correct.

---

Btw, @iltar also said this on IRC about the config proposed in the article:

it seems like putting that piece of text back makes sense to me (assuming it still works like this). I'm just a bit concerned regarding the anonymous: ~
I'm not able to predict this behavior because (A) it will login, always, triggering the authentication success... But (B) it still goes to http_basic and form_login
So in any case, I also suggest to define the behavior of anonymous here: mentioning that it will trigger the authentication success of anon on every page; Mentioning the behavior of anonymous: ~ when authentication fails and when it doesn't fail
as anonymous is a bit of a weird case as provider

I wonder why we suggest to use 2 authentication mechanisms in an article that should just explain a form login?

[wouterj]

@weaverryan you introduced this code and article in #4606 Can you please explain why you used 2 authentication mechanisms (introducing some behaviour that almost nobody exactly knows)?

[weaverryan]

Hey guys!

I was just showing how you could have multiple authentication providers on a firewall - kind of showing that there could potentially be many ways to authenticate. I'd probably not include that now - if we want to doc how to support multiple auth providers, then we could do that elsewhere.

The "entry point" stuff is super confusing. Basically, each "authentication provider" (e.g. http_basic, form_login) adds their own authentication entry point, and via a very abstract "ordering" process and depending the actual code of each "auth provider", one of those "entry points" finally wins. You can create a custom entry point at the firewall level (config: entry_point), but it's not doc'ed anywhere (other than mentioned in the config reference).

So, +1 for removing http_basic and also for adding a note somewhere about this "entry point" business and a bit on how it works. It could even be a cookbook article - "How can I control what happens when the user needs to authenticate".

[xabbuh]

Sounds like a good plan to me. 👍

[javiereguiluz]

Closing as "fixed" because after our big content refactorization, this was reworded and we no longer show two authentication methods in the login form example: https://symfony.com/doc/current/security/form_login_setup.html Thanks!