Chapters
47 Chapters
|
4:41:51
|
Login to bookmark this video
-
Course Code
Subscribe to download the code!
Subscribe to download the code!
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Subtitles
Subscribe to download the subtitles!
Subscribe to download the subtitles!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Subscribe to jump to this part in the video!
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
This tutorial also works great for Symfony 6!
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": ">=8.2",
"ext-ctype": "*",
"ext-iconv": "*",
"babdev/pagerfanta-bundle": "^3.3", // v3.3.0
"composer/package-versions-deprecated": "^1.11", // 1.11.99.4
"doctrine/annotations": "^1.0", // 1.13.2
"doctrine/doctrine-bundle": "^2.1", // 2.6.3
"doctrine/doctrine-migrations-bundle": "^3.0", // 3.1.1
"doctrine/orm": "^2.7", // 2.10.1
"knplabs/knp-markdown-bundle": "^1.8", // 1.9.0
"knplabs/knp-time-bundle": "^1.11", // v1.16.1
"pagerfanta/doctrine-orm-adapter": "^3.3", // v3.3.0
"pagerfanta/twig": "^3.3", // v3.3.0
"phpdocumentor/reflection-docblock": "^5.2", // 5.2.2
"scheb/2fa-bundle": "^5.12", // v5.12.1
"scheb/2fa-qr-code": "^5.12", // v5.12.1
"scheb/2fa-totp": "^5.12", // v5.12.1
"sensio/framework-extra-bundle": "^6.0", // v6.2.0
"stof/doctrine-extensions-bundle": "^1.4", // v1.6.0
"symfony/asset": "5.3.*", // v5.3.4
"symfony/console": "5.3.*", // v5.3.7
"symfony/dotenv": "5.3.*", // v5.3.8
"symfony/flex": "^1.3.1", // v1.21.6
"symfony/form": "5.3.*", // v5.3.8
"symfony/framework-bundle": "5.3.*", // v5.3.8
"symfony/monolog-bundle": "^3.0", // v3.7.0
"symfony/property-access": "5.3.*", // v5.3.8
"symfony/property-info": "5.3.*", // v5.3.8
"symfony/rate-limiter": "5.3.*", // v5.3.4
"symfony/runtime": "5.3.*", // v5.3.4
"symfony/security-bundle": "5.3.*", // v5.3.8
"symfony/serializer": "5.3.*", // v5.3.8
"symfony/stopwatch": "5.3.*", // v5.3.4
"symfony/twig-bundle": "5.3.*", // v5.3.4
"symfony/ux-chartjs": "^1.3", // v1.3.0
"symfony/validator": "5.3.*", // v5.3.8
"symfony/webpack-encore-bundle": "^1.7", // v1.12.0
"symfony/yaml": "5.3.*", // v5.3.6
"symfonycasts/verify-email-bundle": "^1.5", // v1.5.0
"twig/extra-bundle": "^2.12|^3.0", // v3.3.3
"twig/string-extra": "^3.3", // v3.3.3
"twig/twig": "^2.12|^3.0" // v3.3.3
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.3", // 3.4.0
"symfony/debug-bundle": "5.3.*", // v5.3.4
"symfony/maker-bundle": "^1.15", // v1.34.0
"symfony/var-dumper": "5.3.*", // v5.3.8
"symfony/web-profiler-bundle": "5.3.*", // v5.3.8
"zenstruck/foundry": "^1.1" // v1.13.3
}
}
20 Comments
Reminder for Windows users -- if you get the following error you have to switch the single and double quotes around:
"Too many arguments to "doctrine:query:sql" command, expected arguments "sql".
Use this as the command:
symfony console doctrine:query:sql "UPDATE user SET password='foo' WHERE email = 'abraca_admin@example.com'"
I have to start remembering to do this by default to help our Windows users :).
Thanks for the note!
as per explanation, when I put some other properties like firstName in signature_properies, and update it's value ( i.e. first_name column's value ) in database , the cookie is still working, should not that be invalidated ? at 3:54 you said "for any properties in this list, if even one of these changes in the database on that User, all remember me cookie for that user will instantly be invalidated."
Hey @sujal_k
Yes, you're right. The remember me cookie should be invalidated. It's explained in the docs https://symfony.com/doc/current/security/remember_me.html#using-signed-remember-me-tokens
I wonder why is not working for you. Is your first_name field accessible?
Yes, I'm using Symfony 7, and I've added those properties in my Entity class along with getters and setters, but the cookie is still being utilized, and it's not invalidated. But if I change the password, it invalidates and logs out.
Hey @sujal_k, sorry for my slow reply. In theory, that functionality should work out of the box, perhaps you found a bug on Symfony. Would you mind asking about this issue in the Symfony support Slack channel?
Cheers!
It seems like this: When we've both the REMEMBER_ME and SESSION cookie set on the browser, and when the app is utilizing the SESSION cookie ( i.e. relying on SESSION one ), then it seems it's not invalidating the "REMEMBER" one even if the signature_properties data is changed, the REMEMBER ME cookie is only invalidated if we delete the SESSION cookie.
Now, isn't it necessary that Symfony should check for signature even when utilizing the SESSION cookie ? because let's say some user can take advantage of a user account if somehow using the browser, no ?
I think you're right but I don't know if that behavior is by design or just a silly bug. If it is the former, it should be documented; if it is the latter, it will require a PR to squash the bug. Perhaps someone in the Symfony Slack channel may know more and may give you further assistance. Let me know about your findings!
Cheers!
The signature_property password seems to be default in symfony 5.4, at least it shows up in my debug (list of all settings) without me mentioning it in my config file =)
Hey @MattWelander!
Yes, good catch! The
passwordwas added by default in a security patch - https://symfony.com/blog/cve-2021-41268-remember-me-cookie-persistance-after-password-changes - because it's actually SUPER important for the user to be logged out when the password changes. So now, that part is done for you nicely :).Cheers!
Hi!
Is it possible to also invalidate all other (without Remember Me) active user sessions when password is changed?
Hey Aigars,
Actually, this is exactly how things should work in Security component. As soon as user's password is changed - it would invalidate and automatically log out the user everywhere. IIRC that's should be possible thanks to serialize/unserialize User method where you include the password, email, etc. fields that are sensitive for the security.
Cheers!
Thank you for very fast response!
It seems, that I mixed up users when performing tests.
Hey Aigars,
Yeah, most probably so :) Anyway, I'm glad my tips helped.
Cheers!
I see
`signature_properties:
- password`
is the default now, it works even if not set in the yaml. But this is useful for other properties such as the status, you don't want them to keep logging in after they are banned.
But is this the same as doing it in the User::isEqualTo() method?
if($this->status !== $user->getStatus()) {
return false;
}
Hey The_nuts,
Nice, good to have it by default :)
Yeah, good question! Well, the purpose of isEqualTo() and signature_properties are a bit different, but they have kinda similar behaviour. Personally, I think I'd probably keep status in isEqualTo(), and if user object "changed" - it would be logged out anyway.
Cheers!
I was curious about remember me's being invalidated on password change with the old auth system. Appears they are - I believe this is because of the refresh user process and the
AbstractToken::hasUserChanged()method. I assume this would be the same with the new authenticator but usingsignature_properties, it would "fail earlier" (before authentication). Am I off-base here?Yo Kevin B.!
The old system invalidates the remember me cookies when the password changed? Are you positive about that? It's possible... but it's not what I would have expected. Yes, you're totally correct that the
hasUserChanged()would "fail" when the user's password changes. That should invalidate the User object that's stored in the session... so it should have basically the same effect as deleting the "session" cookie. But then, the "remember me" system would take over: it would read the cookie, grab the "user identifier" from that, query for a refresh user, authenticate them and then store that new user in the session.So let me know if you're seeing something different - that would be very interesting. I did test the new system for this behavior while I recorded (I changed the user's password BEFORE adding signature_properties and the result was that the user was still logged in, but suddenly via the remember me cookie instead of the original "token"). But, if you get a different result, we should look deeper :).
Cheers!
Figured it out. The old auth system uses <a href="https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Security/Http/RememberMe/TokenBasedRememberMeServices.php">TokenBasedRememberMeServices</a> and this hashes the cookie with the user's password (because
UserInterfacehas thegetPassword()method still). The new auth system uses <a href="SignatureRememberMeHandler">SignatureRememberMeHandler</a> which, becauseUserInterfacedoes not have agetPassword()method anymore, can't* know to create the hash with the password.*It could if it checked if the user implemented
PasswordAuthenticatedUserInterfacethough...Glad I have a test covering this for when I upgrade to the new auth system!
Ah ha! Good digging! So in the old system, there was almost a "hardcoded" signature_properties, which included the password. With the new system, you need can control the signature.
"Houston: no signs of life"
Start the conversation!