-
-
Notifications
You must be signed in to change notification settings - Fork 415
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
[make:registration] drop guard authentication support #1243
Conversation
2c2468f
to
e66b5b9
Compare
tests/fixtures/make-registration-form/expected/RegistrationControllerNoLogin.php
Show resolved
Hide resolved
tests/fixtures/make-registration-form/expected/RegistrationControllerNoLogin.php
Outdated
Show resolved
Hide resolved
tests/fixtures/make-registration-form/expected/RegistrationControllerFormLogin.php
Outdated
Show resolved
Hide resolved
5c1acfd
to
05078c8
Compare
Co-authored-by: Ryan Weaver <weaverryan+github@gmail.com>
Co-authored-by: Ryan Weaver <weaverryan+github@gmail.com>
4476787
to
ef75722
Compare
} | ||
|
||
foreach ($configData as $customAuthenticatorClass) { | ||
// if (!class_exists($customAuthenticatorClass)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should check if the authenticator exists and that it implements AuthenticatorInterface::class
. Doing so would be a bonus? but it would also require refactoring the test suite to implement a concrete CustomAuthenticatorFixture::class
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually a bit lost in this method. We're looping over the keys under a firewall, right? And the first if statement with tryFrom
will exit unless the key matches the specific set we have in AuthenticatorType
, right? So then, $configData
is represents the values beneath those keys. So if I have:
firewalls:
main:
form_login:
path: /login
Won't $configData
at this point be ['path' => '/login']
? Or am I totally misreading the method?
src/Maker/MakeRegistrationForm.php
Outdated
'redirect_route_name' => $this->redirectRouteName, | ||
'password_hasher_class_details' => $generator->createClassNameDetails(UserPasswordHasherInterface::class, '\\'), | ||
'password_hasher_class_details' => $hasherDetails = $generator->createClassNameDetails(UserPasswordHasherInterface::class, '\\'), | ||
'password_hasher_variable_name' => sprintf('$%s', lcfirst($hasherDetails->getShortName())), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this stuff still need to be dynamic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dunno, I thought it was a good idea 2 years ago :D I'll check haha If it doesn't - ill refactor the template before hitting the big ol merge button nope, i think i was going for "if they use another hasher interface..." but thats their problem to change the hasher signature here...
done
} | ||
|
||
foreach ($configData as $customAuthenticatorClass) { | ||
// if (!class_exists($customAuthenticatorClass)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually a bit lost in this method. We're looping over the keys under a firewall, right? And the first if statement with tryFrom
will exit unless the key matches the specific set we have in AuthenticatorType
, right? So then, $configData
is represents the values beneath those keys. So if I have:
firewalls:
main:
form_login:
path: /login
Won't $configData
at this point be ['path' => '/login']
? Or am I totally misreading the method?
{ | ||
$authenticators = []; | ||
|
||
foreach ($firewallConfig as $potentialAuthenticator => $configData) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh... lost the review comment on push...
@weaverryan:
I'm actually a bit lost in this method. We're looping over the keys under a firewall, right? And the first if statement with tryFrom will exit unless the key matches the specific set we have in AuthenticatorType, right? So then, $configData is represents the values beneath those keys. So if I have:
firewalls:
main:
form_login:
path: /login
Won't $configData at this point be ['path' => '/login']? Or am I totally misreading the method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no I think you're thinking 1 level too deep..
i refactored this to split up iterating over firewalls
, the keys of firewalls
(main, anotherFirewall), and the custom_authenticators
We pass in security.firewalls
-> iterate over each key in firewalls
to give us:
main:
path: '/some-path'
form_login:
- option
....
custom_authenticators:
- some authenticator
anotherFirewall:
dev:
test:
tryFrom($potentialAuthenticator)
checks if the "key" is form_login
, custom_authenticator
, or path
. If it is path, tryFrom()
returns null
and we continue
.
Now $potentialAuthenticator
is either form_login
or custom_authenticator
and $configData
is the array of either of their stuff..
If its form_login
, we create the value object and add it to authenticators[]
otherwiser we now know that $potentialAuthenticator === 'custom_authenticator'
and configData
is either (string) MyCustom
or [MyCustom, NotSureWhyYouCanHave2ButYouCan]
Atleast this is what im trying todo, but i could be missing something myself 🤕
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, it looks clear now 👍
* | ||
* @return Authenticator[] | ||
*/ | ||
public function getAuthenticatorsFromConfig(array $firewalls): array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getAuthenticatorsInFirewallsConfig
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If things are working, let's roll with this 👍
{ | ||
$authenticators = []; | ||
|
||
foreach ($firewallConfig as $potentialAuthenticator => $configData) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, it looks clear now 👍
A wee bit late - but this pr drops the use of the old
guard
authenticators from4.x
DX
Previously we asked which firewall to use -> which authenticator, etc... Now we just grab all of the authenticators available and let the user choose in one question.
internally we iterate through all of the
security.firewalls
to looking for a built in authenticator or acustom_authenticator
. If multiple choices are found, we ask the user which one to use. e.g.If only 1 authenticator was found, obviously don't ask which one to use...
we support
&&
Both of which appear to be valid way to declare a custom authenticator.
Under the hood
an
Authenticator
value object && aAuthenticatorType
enum are introduced to get us away from passing around array's of array's of array's... Goal is to bring better visibility at a glance when reviewing code && get us closer to implementing static analysis without headaches..we generate the code to login a user by calling
Security::login($user, 'name_of_authenticator', 'name_of_firewall')
in the template. Most users do not need the 3rdfirewall
parameter, but I'm pulling the "keep maintainers lives easier by writing less code" card. If this bug's folks, later, we can add in additional logic && conditionals to determine if there are multiple firewalls.refs: SymfonyCasts/verify-email-bundle#126