New in Symfony 3.3: SecurityBundle improvements
Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.
The name of this method was misleading because it just returns the listeners
FirewallMapInterface::getListeners(). That's why we've decided
to deprecate this method and rename it to
security:encode-password command is useful to encode user passwords while
developing the application or for users stored in the
security.yml file. In
Symfony 3.3, this command is smarter and it displays the full list of the user
classes available in your application, so you just need to pick one instead of
typing the full user class name:
1 2 3 4 5 6 7 8
$ ./bin/console security:encode-password For which user class would you like to encode a password?  App\Entity\User  Custom\Class\Bcrypt\User  Custom\Class\Pbkdf2\User  Custom\Class\Test\User  Symfony\Component\Security\Core\User\User
It's common to use properties such as emails as the username of the application
users. However, Symfony normalizes the values of the keys defined under
security.providers.in_memory.users, so an email such as
firstname.lastname@example.org and authentication fails unexpectedly.
In Symfony 3.3 we changed this behavior and those keys/usernames are no longer normalized or modified in any way.
When using helpers like logout_path() without providing any argument, Symfony generates the logout URL for the current active firewall. In Symfony 3.3 we improved its behavior to better solve some edge cases. This is how it works:
- Try to find the key from the token (unless it's an anonymous token);
- If found, try to get the listener from the key. If the listener is found, stop;
- Try from the injected firewall key. If the listener is found, stop;
- Try from the injected firewall context. If the listener is found, stop.
The behavior remains unchanged when providing explicitly the firewall key.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.