- 🇫🇷France andypost
According to #1561866-98: Add support for built-in PHP session upload progress → upload progress may need separate cookie
If a user sends us a session cookie that contains a session ID that we do not have in our database we should throw away their session id and give them a new one. But we don't.
If a user comes back with an sid that we don't have in the sessions table, we should create a new session ID for them and send that cookie back to them.
None.
None.
Needs work
11.0 🔥
Last updated
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
The patch will have to be re-rolled with new suggestions/changes described in the comments in the issue.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
According to #1561866-98: Add support for built-in PHP session upload progress → upload progress may need separate cookie