symfony
symfony copied to clipboard
symfony
[SecurityBundle] Set translator in AccessTokenAuthenticator in Security bundle config
| Q | A |
|---|---|
| Branch? | 6.4 |
| Bug fix? | yes |
| New feature? | no |
| Deprecations? | no |
| Issues | |
| License | MIT |
The AccessTokenAuthenticator doesn't get configured with the translator service. This appears to be a bug, as this class's setTranslator is unused and the translator can't be injected anywhere else.
It has been removed as a fix: https://github.com/symfony/symfony/pull/50819
It has been removed as a fix: #50819
I have amended this branch to an alternative solution; we try to translate, but revert the translation if the result contains any non-ASCII characters. I don't think the linked fix is the right one, really - it's just making it impossible to do any translation here at all, even if the result would be valid and RFC compliant.
What is the use-case for translating this message if - according to the RFC 6750 - it must not be displayed to the end user?
Also, this means we'll have deprecated translation strings in the repository (like Spanish as mentioned in #50811). I'm not sure how we are supposed to fix this, given you probably have to use non-ANCII characters in those languages. This message is also used by other authenticators where the message is meant to be shown to users (like login form), so compromising the translations to fit only one specific authenticator also doesn't seem like a great option to me.
I'm still leaning towards not using the translator here for these arguments.
What is the use-case for translating this message if - according to the RFC 6750 - it must not be displayed to the end user?
"Not displayed to users" isn't quite the same thing as "never seen by a human"; easy to imagine the reasons for authentication failures supplied in headers may end up in logs and as such the information may aid with various inquiry and analysis. It's also not necessarily the case that every system respects the RFC, as not every access token system is OAuth2 compliant, so we don't know this message won't be displayed.
Also, this means we'll have deprecated translation strings in the repository (like Spanish as mentioned in #50811). I'm not sure how we are supposed to fix this, given you probably have to use non-ANCII characters in those languages. This message is also used by other authenticators where the message is meant to be shown to users (like login form), so compromising the translations to fit only one specific authenticator also doesn't seem like a great option to me.
I would argue that allowing some translation, even if limited to ASCII characters, is useful. The case for translation may not necessarily be to another language, but e.g. alternative or simplified English for example.