Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Security] Require entry_point to be configured with multiple authenticators #36575

Merged
merged 1 commit into from Apr 30, 2020

Conversation

wouterj
Copy link
Member

@wouterj wouterj commented Apr 24, 2020

Q A
Branch? master
Bug fix? no
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR tbd

See @weaverryan's comment at #33558 (comment):

I have it on my list to look at the entrypoint stuff more closely. But my gut reaction is this: let's fix them (or try to... or maybe in a PR after this) :). What I mean is this:

  • It's always been confusing that your firewall may have multiple auth mechanisms that have their own "entry point"... and one is chosen seemingly at random :). I know it's not random, but why does the entrypoint from form_login "win" over http_basic if I have both defined under my firewall?

  • Since we're moving to a new system, why not throw an exception the moment that a firewall has multiple entrypoints available to it. Then we force the user to choose the one entrypoint that should be used.


Before (one authenticator)

security:
  enable_authenticator_manager: true

  firewalls:
    main:
      form_login: ...

# form login is your entry point

After
Same as before


Before (multiple authenticators)

security:
  enable_authenticator_manager: true

  firewalls:
    main:
      http_basic: ...
      form_login: ...

# for some reason, FormLogin is now your entry point! (config order doesn't matter)

After

security:
  enable_authenticator_manager: true

  firewalls:
    main:
      http_basic: ...
      form_login: ...
      entry_point: form_login

Before (custom entry point service)

security:
  enable_authenticator_manager: true

  firewalls:
    main:
      http_basic: ...
      form_login: ...
      entry_point: App\Security\CustomEntryPoint

After
Same as before

@nicolas-grekas nicolas-grekas added this to the next milestone Apr 26, 2020
@wouterj wouterj force-pushed the security/entry-point branch 2 times, most recently from 98b949b to cc876a2 Compare April 27, 2020 12:10
@wouterj wouterj force-pushed the security/entry-point branch 3 times, most recently from 7169af4 to 83c9c3a Compare April 30, 2020 12:24
@wouterj
Copy link
Member Author

wouterj commented Apr 30, 2020

Both test failures appear to be unrelated

src/Symfony/Bundle/SecurityBundle/CHANGELOG.md Outdated Show resolved Hide resolved
@fabpot
Copy link
Member

fabpot commented Apr 30, 2020

Thank you @wouterj.

@fabpot
Copy link
Member

fabpot commented May 1, 2020

@wouterj I haven't had time to investigate further, but this PR breaks auth on my app. I get "Full authentication is required to access this resource." when trying to authenticate.

wouterj added a commit to wouterj/symfony that referenced this pull request May 1, 2020
@wouterj
Copy link
Member Author

wouterj commented May 1, 2020

Oh, I think #36650 should fix it. Sorry, I finished this patch on my Windows PC to get it ready before the weekend. I'll try to add some tests for the DI stuff in SecurityBundle in some weeks.

@wouterj wouterj deleted the security/entry-point branch May 1, 2020 07:52
fabpot added a commit that referenced this pull request May 1, 2020
…#36575) (wouterj)

This PR was merged into the 5.1-dev branch.

Discussion
----------

[Security] Fix bug introduced in entry_point configuration (#36575)

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

Commits
-------

6978471 Fixed #36575
@@ -65,7 +67,7 @@ public function create(ContainerBuilder $container, string $id, array $config, s
}

// create entry point if applicable (optional)
$entryPointId = $this->createEntryPoint($container, $id, $config, $defaultEntryPointId);
$entryPointId = $this->createDefaultEntryPoint($container, $id, $config, $defaultEntryPointId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the BC break that makes my code fail now. AbstractFactory is what we use in Connect Bundle: https://github.com/symfonycorp/connect-bundle/blob/master/src/DependencyInjection/Security/Factory/ConnectFactory.php

/cc @wouterj

So, even if I can probably fix it in Connect, I fear that we won't be alone by this problem. Anyone not using Guard is probably extending AbstractFactory. That means that we cannot mark AbstractFactory as @internal.

Copy link
Member Author

@wouterj wouterj May 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for debugging!
That also means we have to find another method name for the EntryPointInterface interface, to not conflict with the abstract method in this class. I'll do a PR later this evening. See #36661

fabpot added a commit that referenced this pull request May 3, 2020
…d multiple guard entry points (wouterj)

This PR was squashed before being merged into the 5.1-dev branch.

Discussion
----------

[SecurityBundle] Fixed entry point service ID resolving and multiple guard entry points

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | n/a

@fabpot I am not able to reproduce [the error you reported](#36575 (comment)) in any of my demo applications or in the tests introduced in this PR. The error indicates that no entry point is configured in your application, can you maybe try out this patch (given it now makes a hard error when more than one guard is used)? If it still doesn't work, can you maybe share your firewall configuration?

---

_build failures are unrelated_

Commits
-------

c756593 Do not make AbstractFactory internal and revert method rename
6870a18 Fixed entry point resolving and guard entry point configuration
symfony-splitter pushed a commit to symfony/security-bundle that referenced this pull request May 3, 2020
…d multiple guard entry points (wouterj)

This PR was squashed before being merged into the 5.1-dev branch.

Discussion
----------

[SecurityBundle] Fixed entry point service ID resolving and multiple guard entry points

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | n/a

@fabpot I am not able to reproduce [the error you reported](symfony/symfony#36575 (comment)) in any of my demo applications or in the tests introduced in this PR. The error indicates that no entry point is configured in your application, can you maybe try out this patch (given it now makes a hard error when more than one guard is used)? If it still doesn't work, can you maybe share your firewall configuration?

---

_build failures are unrelated_

Commits
-------

c75659350e Do not make AbstractFactory internal and revert method rename
6870a18803 Fixed entry point resolving and guard entry point configuration
vjandrea pushed a commit to vjandrea/symfony that referenced this pull request May 3, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
@fabpot fabpot mentioned this pull request May 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants