Bug #6761

Security context in session grows with each load

Added by Karsten Dambekalns over 11 years ago. Updated about 11 years ago.

Status:
Resolved
Priority:
Must have
Category:
Security
Target version:
-
Start date:
2010-03-11
Due date:
% Done:

100%

Estimated time:
4.00 h
PHP Version:
Has patch:
Complexity:

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.


Files

sess_j6je3itierlcpkhic6hkgle600.first.txt (63.7 KB) sess_j6je3itierlcpkhic6hkgle600.first.txt Session file after a few reloads Karsten Dambekalns, 2010-03-10 14:00
sess_j6je3itierlcpkhic6hkgle600.second.txt (127 KB) sess_j6je3itierlcpkhic6hkgle600.second.txt Session file after once more reload Karsten Dambekalns, 2010-03-10 14:00
#1

Updated by Karsten Dambekalns over 11 years ago

The effect continues even after logging out again.

#2

Updated by Karsten Dambekalns over 11 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.

#4

Updated by Robert Lemke over 11 years ago

  • Estimated time set to 10.00 h
#5

Updated by Robert Lemke over 11 years ago

  • Assignee 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 11 years ago

  • Estimated time changed from 10.00 h to 2.00 h
#7

Updated by Robert Lemke over 11 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r3929.

#8

Updated by Robert Lemke over 11 years ago

  • Status changed from Resolved to Accepted
  • % Done changed from 100 to 50
  • Estimated time changed from 2.00 h to 4.00 h

Seems like I didn't fix this completely

#9

Updated by Karsten Dambekalns over 11 years ago

  • Assignee 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 11 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 90 to 100

Applied in changeset r3939.

#11

Updated by Bastian Waidelich about 11 years ago

  • Status changed from Resolved to Accepted
  • Assignee 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 about 11 years ago

  • Status changed from Accepted to Resolved
  • Assignee 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.

Also available in: Atom PDF