[SecurityBundle] Don't normalize username of in-memory users #21718
Conversation
|
That's a BC break (probably just for tests in end-users apps, but still). I would document the change and merge it on master. |
1b4800d to
0e378ef
Compare
|
Change documented and rebased on master. |
|
@fabpot ideally, we should skip normalized for all prototyped nodes (and even remove the explicit config), but this is a BC break. I don't see a way to easily disable key normalization for prototyped nodes in an fully BC way though (even though it would break BC only for people who faced the WTF moment and decided to keep a WTF config files forever rather than using an underscore explicitly) |
cdf1908 to
313e6e8
Compare
313e6e8 to
8d03332
Compare
|
Thank you @chalasr. |
… users (chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- [SecurityBundle] Don't normalize username of in-memory users | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | yes | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a It's common to have e.g. emails as keys in `security.providers.in_memory.users` since keys are username. Actually they are normalized so `foo-bar@gmail.com` becomes `foo_bar@gmail.com` and authentication fails unexpectedly. Commits ------- 8d03332 [SecurityBundle] Don't normalize keys of in-memory users
It's common to have e.g. emails as keys in
security.providers.in_memory.userssince keys are username. Actually they are normalized sofoo-bar@gmail.combecomesfoo_bar@gmail.comand authentication fails unexpectedly.