-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[Security] Allow enums in SignatureHasher::computeSignatureHash()
#60302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 8.1
Are you sure you want to change the base?
Conversation
|
Tests? 🙃 |
SignatureHasher::computeSignatureHash()
SignatureHasher::computeSignatureHash()SignatureHasher::computeSignatureHash()
|
Only option 2 makes sense to me. If you need your enum to have a canonical scalar representation, you should use a backed enum (that's what they are about).
that's not something we need to detect IMO (your DB would also have issues in such case, and this would require an insane architecture IMO) |
3815106 to
d13454c
Compare
|
@chalasr @derrabus @stof Ready for review. I've split the PR into 3 commits:
|
d13454c to
184663b
Compare
|
Rebased onto 7.4. |
184663b to
cec52d9
Compare
nicolas-grekas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR.
I'd rather remove the new interface and keep the current inline calls.
The reason is that we likely won't want to open a new API for hasher. Also that's unrelated to the purpose of the PR.
About the added deps, it should be moved to require-dev: the feature is optional.
Last but not least, we don't use strict types ;)
Currently, using
remember_me.signature_propertieson a property holding an enum fails with:We can add support for enums in one of three ways:
int|string)In the current PR I went with option 2, but I'm thinking that option 3 could be better:
Pros:
Cons:
I would welcome feedback here.