-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Added retainer for current session token in order to not break checkToken functionality if getToken is called before. #12518
Conversation
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.
Update CHANGELOG.md
please too
56a0b1d
to
9f27773
Compare
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.
@gguridi We use the 3.0.x
branch for bug fixes that do not break backward compatibility. I changed the base branch to 3.0.x
from 3.1.x
. But now your PR has conflicts that must be resolved. So could you please rebase the PR onto 3.0.x
branch?
…ate fields after regenerating the token. Added string casting to userToken.
9f27773
to
28e2c44
Compare
e63249b
to
821011d
Compare
14919a9
to
13ce09f
Compare
This has been implemented with PR #13642 |
Hello!
In raising this pull request, I confirm the following (please check boxes):
Small description of change:
Security::checkToken functionality doesn't use the regenerated session but uses the one that was set at the beginning if it existed. This will prevent that if we call getToken and the session token is regenerated, the checkToken method will fail because the session token has changed.
I've also cast to string the userToken coming from the request::getPost method as it could be null and I was receiving an E_WARNING when passing it to hash_equals.
Thanks
This change is