April 19, 2017 Javier Eguiluz

The SecurityBundle is responsible for integrating the Security Component into the Symfony framework. In Symfony 3.3 we added some minor improvements to it.

Renamed 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() .

Improved 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 \E ntity \U ser [ 1 ] Custom \C lass \B crypt \U ser [ 2 ] Custom \C lass \P bkdf2 \U ser [ 3 ] Custom \C lass \T est \U ser [ 4 ] Symfony \C omponent \S ecurity \C ore \U ser \U ser

Don't normalize usernames of in-memory users¶ 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.