Bug #6761
Security context in session grows with each load
| Status: | Resolved | Start date: | 2010-03-11 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | Karsten Dambekalns | % Done: | 100% |
|
| Category: | Security | |||
| Target version: | - | Estimated time: | 4.00 hours | |
| PHP Version: | Complexity: | |||
| Has patch: | Affected Flow version: |
Description
Since the latest changes to security it seems something goes wrong with object serialization to the session. It grows exponentially with each page load until the memory limit is hit.
Reproducible by logging in and calling the same page again and again... Even failing login tries have that effect.
sess_j6je3itierlcpkhic6hkgle600.first.txt
- Session file after a few reloads
(63.7 kB)
sess_j6je3itierlcpkhic6hkgle600.second.txt
- Session file after once more reload
(127.1 kB)
Associated revisions
[+BUGFIX] FLOW3 (Security): Fixed the token duplication in the security context, fixes #6761.
History
#1 Updated by Karsten Dambekalns over 5 years ago
The effect continues even after logging out again.
#2 Updated by Karsten Dambekalns over 5 years ago
Ok, it seems the session grows also when not logging in or trying to do so. Only it grows at a much lower speed, in kb rather than mb. So maybe the ObjectSerializer is the problem in general.
#3 Updated by Karsten Dambekalns over 5 years ago
- File sess_j6je3itierlcpkhic6hkgle600.first.txt added
- File sess_j6je3itierlcpkhic6hkgle600.second.txt added
Attached two session files. The file doubles it's size on every page load.
#4 Updated by Robert Lemke over 5 years ago
- Estimated time set to 10.00
#5 Updated by Robert Lemke over 5 years ago
- Assigned To changed from Andreas Förthner to Robert Lemke
- Start date changed from 2010-03-10 to 2010-03-11
#6 Updated by Robert Lemke over 5 years ago
- Estimated time changed from 10.00 to 2.00
#7 Updated by Robert Lemke over 5 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
Applied in changeset r3929.
#8 Updated by Robert Lemke over 5 years ago
- Status changed from Resolved to Accepted
- % Done changed from 100 to 50
- Estimated time changed from 2.00 to 4.00
Seems like I didn't fix this completely
#9 Updated by Karsten Dambekalns over 5 years ago
- Assigned To changed from Robert Lemke to Karsten Dambekalns
- % Done changed from 50 to 90
The problem is caused by seperateActiveAndInactiveTokens() in combination with the way initialize() sets $this->activeTokens.
1. call
initialize
tokens 0
activeTokens 1
inactiveTokens 0
shutdownObject
tokens 1
activeTokens 1
inactiveTokens 0
2. call
initialize
tokens 1
activeTokens 1
inactiveTokens 0
seperateActiveAndInactiveTokens
tokens 1
activeTokens 2 (!)
inactiveTokens 0
shutdownObject
tokens 2
activeTokens 2
inactiveTokens 0
3. call
initialize
tokens 2
activeTokens 2
inactiveTokens 0
seperateActiveAndInactiveTokens
tokens 2
activeTokens 4 (!)
inactiveTokens 0
shutdownObject
tokens 4
activeTokens 4
inactiveTokens 0
#10 Updated by Karsten Dambekalns over 5 years ago
- Status changed from Accepted to Resolved
- % Done changed from 90 to 100
Applied in changeset r3939.
#11 Updated by Bastian Waidelich almost 5 years ago
- Status changed from Resolved to Accepted
- Assigned To changed from Karsten Dambekalns to Bastian Waidelich
- Target version deleted (
1.0 alpha 8)
It seems this issue reoccurs in the current version.. I'll dig into it
#12 Updated by Bastian Waidelich almost 5 years ago
- Status changed from Accepted to Resolved
- Assigned To changed from Bastian Waidelich to Karsten Dambekalns
Bastian Waidelich wrote:
It seems this issue reoccurs in the current version.. I'll dig into it
Apparently the issue occurred because I had configured multiple authentication providers - so it might be just a misconfiguration. I'll check that and reopen the issue in case it is not.