The SecurityBundle is responsible for integrating the Security Component into the Symfony framework. In Symfony 3.3 we added some minor improvements to it.
FirewallContext#getContext()
¶
Contributed by
Robin Chalas
in #20417.
The name of this method was misleading because it just returns the listeners
returned by FirewallMapInterface::getListeners()
. That's why we've decided
to deprecate this method and rename it to FirewallContext#getListeners()
.
UserPasswordEncoderCommand
¶
Contributed by
Maxime Steinhausser
in #20677.
The 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?
[0] App\Entity\User
[1] Custom\Class\Bcrypt\User
[2] Custom\Class\Pbkdf2\User
[3] Custom\Class\Test\User
[4] Symfony\Component\Security\Core\User\User
|
Contributed by
Robin Chalas
in #21718.
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 foo-bar@gmail.com
becomes foo_bar@gmail.com
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.
Contributed by
Maxime Steinhausser
in #20516.
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:
The behavior remains unchanged when providing explicitly the firewall key.
What a Symfony developer should know about the framework: News, Jobs, Tweets, Events, Videos,...