// composer.json
{
"require": {
"php": "^8.0.2",
"ext-ctype": "*",
"ext-iconv": "*",
"babdev/pagerfanta-bundle": "^3.6", // v3.6.1
"composer/package-versions-deprecated": "^1.11", // 1.11.99.5
"doctrine/annotations": "^1.13", // 1.13.2
"doctrine/dbal": "^3.3", // 3.3.5
"doctrine/doctrine-bundle": "^2.0", // 2.6.2
"doctrine/doctrine-migrations-bundle": "^3.2", // 3.2.2
"doctrine/orm": "^2.0", // 2.11.2
"knplabs/knp-markdown-bundle": "^1.8", // 1.10.0
"knplabs/knp-time-bundle": "^1.18", // v1.18.0
"pagerfanta/doctrine-orm-adapter": "^3.6", // v3.6.1
"pagerfanta/twig": "^3.6", // v3.6.1
"sensio/framework-extra-bundle": "^6.0", // v6.2.6
"sentry/sentry-symfony": "^4.0", // 4.2.8
"stof/doctrine-extensions-bundle": "^1.5", // v1.7.0
"symfony/asset": "6.0.*", // v6.0.7
"symfony/console": "6.0.*", // v6.0.7
"symfony/dotenv": "6.0.*", // v6.0.5
"symfony/flex": "^2.1", // v2.1.7
"symfony/form": "6.0.*", // v6.0.7
"symfony/framework-bundle": "6.0.*", // v6.0.7
"symfony/mailer": "6.0.*", // v6.0.5
"symfony/monolog-bundle": "^3.0", // v3.7.1
"symfony/property-access": "6.0.*", // v6.0.7
"symfony/property-info": "6.0.*", // v6.0.7
"symfony/proxy-manager-bridge": "6.0.*", // v6.0.6
"symfony/routing": "6.0.*", // v6.0.5
"symfony/runtime": "6.0.*", // v6.0.7
"symfony/security-bundle": "6.0.*", // v6.0.5
"symfony/serializer": "6.0.*", // v6.0.7
"symfony/stopwatch": "6.0.*", // v6.0.5
"symfony/twig-bundle": "6.0.*", // v6.0.3
"symfony/ux-chartjs": "^2.0", // v2.1.0
"symfony/validator": "6.0.*", // v6.0.7
"symfony/webpack-encore-bundle": "^1.7", // v1.14.0
"symfony/yaml": "6.0.*", // v6.0.3
"symfonycasts/verify-email-bundle": "^1.7", // v1.10.0
"twig/extra-bundle": "^2.12|^3.0", // v3.3.8
"twig/string-extra": "^3.3", // v3.3.5
"twig/twig": "^2.12|^3.0" // v3.3.10
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.4", // 3.4.1
"phpunit/phpunit": "^9.5", // 9.5.20
"rector/rector": "^0.12.17", // 0.12.20
"symfony/debug-bundle": "6.0.*", // v6.0.3
"symfony/maker-bundle": "^1.15", // v1.38.0
"symfony/var-dumper": "6.0.*", // v6.0.6
"symfony/web-profiler-bundle": "6.0.*", // v6.0.6
"zenstruck/foundry": "^1.16" // v1.18.0
}
}
8 Comments
Oh man, but why these changes? The old security system methods seemed fine and suitable. Now it looks o er simplified. Is flexibility lost? It looks like readability is reduced.
I think I'm getting the hang of the new security component but stuck on where to do somethings. Our application uses LDAP for authentication which has been successfully moved into CustomCrendentials - no problem there. However, we don't require a user be in the database to successfully authenticate. In Guard Authenticator, we added the user to the database upon successful authentication. The local database is only used to track first names and privilege levels. I see I can use a custom function when a new UserBadge is created where I think I can create and return a new user if the user isn't already in the database. However, how can I access this new user in onAuthenticationSuccess to then persist it to the database? Can I add the passport as an input argument to onAuthenticationSuccess?
I solved this by moving the LDAP lookup and authentication into authenticate rather than doing it in onAuthenticationSuccess. I also had to move adding a new user to the database into authenticate. In my case I could not create a new user when creating a new passport as the user would never get successfully refreshed after adding the user to the database. It worked fine for existing user but not for new ones. So I had to do the LDAP search first, then authenticate the user's password, then add the user to the database and lastly, create the passport and return it.
Hey @CMarcus ,
Woh, that's a complex issue, I'm happy to hear you were able to workaround it. I personally don't use LDAP so it's hard to suggest you a better solution, but IMO this looks solid. I would recommend you to double-check the flows with new/existent users, especially look for possible errors and make sure they all are no edge cases and those are handled well with your solution.
You still may leverage
onAuthenticationSuccess()for non-critical actions like logging, tracking login timestamps, or redirecting users, etc. but keeping the main logic inauthenticate()should do the trick for you, well done.I hope this helps! and thanks for sharing the solution with others. It's definitely useful for our LDAP friends, probably some will leave you feedback or share their own ideas as well.
Cheers!
I also don't like these changes, like Cameron. So much happens automatically under the hood. It's difficult to know what is going on. Now I am not sure how to refactor this, as I'm working on a bigger application with a lot of customisations.
Hey @rzrztrzrtz
I feel you, the change feels overwhelming at the beginning but it was for good. The security component is easier/simpler to use and is designed as an event-based system, which is nice because you can now customize it easily, for example, adding 2FA protection is not a problem at all.
I hope this course helps you upgrade your application without much hassle
Cheers!
Hi, in Symfony 5.4 I can use "Abstract Guard Authenticator" to handle authentication with SSO, but this class is deprecated. Is there an alternative in Symfony 6.1 ?
Hey Tien dat L.
You should just migrate from Guard authentication to standard security authentication, it's very close to Guard, but more flexible and straightforward.
Cheers!
"Houston: no signs of life"
Start the conversation!