Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Security] Automatically register custom authenticator as entry_point (if supported)#39153

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@wouterj
Copy link
Member

@wouterjwouterj commentedNov 23, 2020
edited by stof
Loading

QA
Branch?5.2 (hopefully?)
Bug fix?no
New feature?yes
Deprecations?no
TicketsFix#37068
LicenseMIT
Doc PR-

@weaverryan came up with exactly the same issue as proposed by a contributor before (see referenced ticket). Back then, it was decided impossible to fix: see#37075. However, after some thinking we came up with a way to fix the issue and improve the DX for custom authenticators.

The new authenticators are no longer required to implementAuthenticationEntryPointInterface (required for internal authenticators like theRememberMeAuthenticator and pre authenticated ones). This PR uses a compiler pass to check if a custom authenticator is supported:

security:firewalls:main:# in any case, if an entry_point is already configured it'll not be overriden# (http_basic remains the entry point here)http_basic:~custom_authenticator:App\Security\CustomAuthenticatorentry_point:http_basic# if only one custom authenticator implements AuthenticationEntryPointInterface,# it's automatically configured as the entry pointcustom_authenticator:App\Security\CustomAuthenticatorcustom_authenticators:[App\Security\CustomAuthenticator, App\Security\NoEntryPointAuthenticator]# if no custom authenticator implements AuthenticationEntryPointInterface,# an error is throwncustom_authenticator:App\Security\NoEntryPointAuthenticator# if more than one authenticator implements AuthenticationEntryPointInterface,# the entry point must be configured explicitly (or an error is thrown)custom_authenticators:[App\Security\CustomAuthenticator, App\Security\AnotherCustomAuthenticator]entry_point:App\Security\CustomAuthenticator

I know this is very late for Symfony 5.2. It would be good to decide whether this can be included in the release, in order to smooth out the biggest struggle for people using custom authenticators for the first time.

@carsonbotcarsonbot added this to the5.2 milestoneNov 23, 2020
@wouterjwouterjforce-pushed thesecurity/custom-authenticator-entry-point branch from66eeb90 to8f88fe6CompareNovember 23, 2020 23:35
Copy link
Member

@chalasrchalasr left a comment

Choose a reason for hiding this comment

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

👍 For 5.2

Copy link
Member

@weaverryanweaverryan left a comment

Choose a reason for hiding this comment

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

HUGE thanks Wouter for spending your time with this last-second change. My apologies for not catching it sooner. I do think it's important, as the error if you don't have any entrypoints (but you have some custom authenticators) is poor as is trying to debugwhy one entrypoint is being used (e.g. fromform_login) but your custom authenticator'sstart() method is being ignored.

There is one case that the PR doesn't address yet:

security:  firewalls:    main:      http_basic: ~      custom_authenticator: App\Security\CustomAuthenticatorWithEntrypointInterface

What should happen in this case (where no specificentry_point has been chosen)? Right now, the new compiler pass is written to just usehttp_basic. I think it should throw an exception. I don't think this should be treated any differently than 2custom_authenticators that both have the entrypoint interface. To say it differently, we should collect the entire collection of "potential entry points" (from built-in authenticators and custom authenticators) and if that collection > 1, we throw an exception and tell the user which options they can choose from.

WDYT? I think it's not too difficult - I think we would need to:

A) Do not throw this Exception inside ofSecurityExtension -https://github.com/symfony/symfony/blob/5.x/src/Symfony/Bundle/SecurityBundle/DependencyInjection/SecurityExtension.php#L606

B) InSecurityExtension, we would probably return the entrypoint from-> configuredEntryPoint() as a Reference to some fake service - e.g.security.FIREWALLNAME.entrypoint (this is maybe important the entrypoint is also passed to the security config object -https://github.com/symfony/symfony/blob/5.x/src/Symfony/Bundle/SecurityBundle/DependencyInjection/SecurityExtension.php#L501 ). Then, later in the compiler pass, we'll figure out thereal entrypoint, and set an alias for that fake service that points to the real entrypoint.

C) Also in SecurityExtension, in addition to the'security.'.$firewallName.'_custom_authenticators' parameter, we would set another parameter that held a key->value of all entrypoints for that firewall - e.g.['form_login' => 'SERVICE ID FOR THIS ENTRYPOINT', 'http_basic' => 'SERVICE ID FOR THIS ENTRYPONT'].

D) Finally, this would give us everything we need in the compiler pass to get a full list of the entrypoints and, if there were more than 1, throw a really nice exception with all the possible keys :).

Let me know if you'd like to chat with this or need any helping pushing it through!

Thank you!

@wouterj
Copy link
MemberAuthor

wouterj commentedNov 24, 2020
edited
Loading

I've completely changed the implementation of this PR to simply the implementation suggested by@weaverryan. If you want entry point to be configured by default, you should now implementAuthenticationEntryPointInterface on the authenticator. This already used to be a requirement with Guard and also the core authenticators were almost all supporting this already. If only one entry point is found, it's registered automatically. If you need another class to be the entry point, you would need to configureentry_point explicitly.

I'll add some tests for the new compiler pass tomorrow evening.

@wouterjwouterjforce-pushed thesecurity/custom-authenticator-entry-point branch 2 times, most recently fromb3d71a7 to54ea6a9CompareNovember 24, 2020 22:45
Copy link
Member

@weaverryanweaverryan left a comment

Choose a reason for hiding this comment

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

I just tested this extensively - it works perfectly. The internals to get this working are a bit complex, but I'm super happy with the end result: if more than 1 authentication mechanism supplies an "entry point", then you get a clear error instructed you to choose one.

Copy link
Member

@chalasrchalasr left a comment

Choose a reason for hiding this comment

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

Some tests are failing

@fabpot
Copy link
Member

@wouterj Can you have a look at the failing tests and apply fabbot's patch which seems relevant?

@wouterjwouterjforce-pushed thesecurity/custom-authenticator-entry-point branch from54ea6a9 to43543caCompareNovember 27, 2020 09:18
@wouterj
Copy link
MemberAuthor

@wouterj Can you have a look at the failing tests and apply fabbot's patch which seems relevant?

Fixed. The remaining failing test seems to be due to outdated dependencies for some reason. If I apply the patches in this PR toFormLoginAuthenticator andGuardBridgeAuthenticator in thevendor/ of SecurityBundle, the tests pass. However, I do require^5.2 in thecomposer.json. So I think (hope) these will be fixed automatically after this PR is merged.

@fabpot
Copy link
Member

Thank you@wouterj.

@fabpotfabpot closed thisNov 27, 2020
@fabpotfabpotforce-pushed thesecurity/custom-authenticator-entry-point branch from43543ca tocab0672CompareNovember 27, 2020 10:25
@fabpotfabpot merged commitdf7099c intosymfony:5.2Nov 27, 2020
@wouterjwouterj deleted the security/custom-authenticator-entry-point branchNovember 27, 2020 12:52
@fabpotfabpot mentioned this pull requestNov 30, 2020
fabpot added a commit to symfonycorp/connect that referenced this pull requestApr 8, 2021
This PR was merged into the 7.x-dev branch.Discussion----------Fix compatibility with SecurityBundle 5.2The `EntryPointFactoryInterface` interface has been removed in 5.2 (symfony/symfony#39153)from SY'mfony's changelog>  * [BC break] Removed `EntryPointFactoryInterface`, authenticators must now implement `AuthenticationEntryPointInterface` if they require autoregistration of a Security entry point.The ConnectAuthenticator already implements the `AuthenticationEntryPointInterface` interface, so I think this patch should be enough, but I'm not sure.@wouterj could you please have a look?Commits-------858861e Fix compatibility with SecurityBundle 5.2
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@stofstofstof left review comments

@chalasrchalasrchalasr approved these changes

@fabpotfabpotfabpot approved these changes

@weaverryanweaverryanweaverryan approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

5.2

Development

Successfully merging this pull request may close these issues.

6 participants

@wouterj@fabpot@weaverryan@stof@chalasr@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp