Bug Report #3159

Session corrupt - handle gracefully

Added by Mathieu Allaire about 4 years ago. Updated over 3 years ago.

Status:ClosedStart date:08/08/2010
Priority:NormalDue date:
Assignee:Kiall Mac Innes% Done:

100%

Category:Core
Target version:v3.2.0
Resolution:fixed Points:

Description

if a session is corrupt / cant be de-serialized, we should try and handle that gracefully, so the developer knows he must clear his session data.


Related issues

Blocked by Kohana v3.x - Bug Report #3100: No way to create a new session after destroying an old se... Closed 07/21/2010

Associated revisions

Revision 55aeed9a
Added by Kiall Mac Innes over 3 years ago

Fixes #3159 - Session corrupt, handle gracefully

History

#1 Updated by Kiall Mac Innes about 4 years ago

See:

It looks like it was caused by trying to unserialize a class that no longer exists (or the session data was corrupted causing it to try and unserialize a class that never existed)

I'll see if I can find a way to re-create this...

#2 Updated by Kiall Mac Innes about 4 years ago

Somewhat recreatable with unserialize('O:9:"Class_ABC":1:{s:3:"bla";N;}');

Internally, session_start() unserialize's any session data it finds - since Class_ABC doesnt exist, we see the same error.

I believe the fix is to catch the ErrorException in classes/kohana/session.php's read() function then, destroy() and recreate a fresh session...

But #3100 prevents us from doing this...

#3 Updated by Kiall Mac Innes about 4 years ago

  • Target version changed from v3.0.8 to v3.1.0

Targetting 3.1.0 per #3100

#4 Updated by Chris Smith about 4 years ago

I've worked around this by calling Session::destroy() and then throwing an exception, user's don't get stuck with a broken session and get a nice error to go with it.

#5 Updated by Chris Smith about 4 years ago

Chris Smith wrote:

I've worked around this by calling Session::destroy() and then throwing an exception, user's don't get stuck with a broken session and get a nice error to go with it.

Like this: http://github.com/cs278/kohana-core/compare/3.0.x...issue%2F3159

#6 Updated by Kiall Mac Innes about 4 years ago

I believe your workaround will do the trick - this combined with a fix for #3100 seems like a good solution.

#7 Updated by Jeremy Bush almost 4 years ago

  • Target version changed from v3.1.0 to v3.2.0

#8 Updated by Jeremy Bush over 3 years ago

  • Status changed from New to Assigned
  • Assignee changed from Woody Gilk to Kiall Mac Innes

#9 Updated by Kiall Mac Innes over 3 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

Applied in changeset commit:55aeed9a208eef9bc1fbc88531e5264f891bb2cb.

#10 Updated by Kiall Mac Innes over 3 years ago

  • Resolution set to fixed

Also available in: Atom PDF