Zend Framework

Zend_Session doesn't allow you to destory/recreate a session

Details

  • Fix Version Priority:
    Should Have

Description

The following doesn't work:

Zend_Session::start();
Zend_Session::destroy();
Zend_Session::start();

It never writes any session data, because the second start() command is silently ignored.

Here is a patch which fixes the problem:

Index: Session.php
===================================================================
--- Session.php (revision 5124)
+++ Session.php (working copy)
@@ -360,11 +360,6 @@
                . " output started in {$filename}/{$linenum}");
         }

-        // See http://www.php.net/manual/en/ref.session.php for explanation
-        if (defined('SID')) {
-            throw new Zend_Session_Exception('session has already been started by session.auto-start or session_start()');
-        }
-
         /**
          * Hack to throw exceptions on start instead of php errors
          * @see http://framework.zend.com/issues/browse/ZF-1325
@@ -379,6 +374,7 @@
            throw new Zend_Session_Exception(__CLASS__ . '::' . __FUNCTION__ . '() - ' . Zend_Session_Exception::$sessionStartError);
         }

+        self::$_destroyed = false;
         parent::$_readable = true;
         parent::$_writable = true;
         self::$_sessionStarted = true;
@@ -594,11 +590,15 @@
         }

         session_destroy();
+
         self::$_destroyed = true;
-
+               self::$_sessionStarted = false;
+               self::$_regenerateIdState = -1;
+
         if ($remove_cookie) {
             self::expireSessionCookie();
         }
     }

Issue Links

Activity

Hide
Bill Karwin added a comment -

Assign to Darby.

Show
Bill Karwin added a comment - Assign to Darby.
Hide
Ralph Schindler added a comment -

John, I dont follow what the use case is here.

Start
Destroy
Start..

All within a single request, aside from making it "possible", I am interested in the Use case you present for applications to do this.

-ralph

Show
Ralph Schindler added a comment - John, I dont follow what the use case is here. Start Destroy Start.. All within a single request, aside from making it "possible", I am interested in the Use case you present for applications to do this. -ralph
Hide
John Coggeshall added a comment -

The idea here probably was that I wanted to start from scratch with a new session every time that particular controller was called, although I'm pretty sure the code itself has changed to the point where that use-case has disappeared.

Regardless, nothing should just be silently ignored – it should either tell me I'm using the API incorrectly or do what I ask it to.

Show
John Coggeshall added a comment - The idea here probably was that I wanted to start from scratch with a new session every time that particular controller was called, although I'm pretty sure the code itself has changed to the point where that use-case has disappeared. Regardless, nothing should just be silently ignored – it should either tell me I'm using the API incorrectly or do what I ask it to.
Hide
Ralph Schindler added a comment -

Added a check in Zend_Session::start() to throw an exception if destroy was called before start().

In r8010.

Show
Ralph Schindler added a comment - Added a check in Zend_Session::start() to throw an exception if destroy was called before start(). In r8010.
Hide
venu added a comment -

My requirement is, When user agent change session should destroy, and it should start new session. But Zend_Session::start() is throwing an exception if destroy was called before start().

<pre>
try { Zend_Session::start(); } catch (Zend_Session_Exception $e) { Zend_Session::destroy(true); Zend_Session::start(); // breaking here Zend_Session::regenerateId(); }
Zend_Session::registerValidator(new Zend_Session_Validator_HttpUserAgent());
</pre>

I have a global session management in bootstrap, which validates the request and starts session. By that time, request won't be dispatched. Then why to make another request to redirect to another page? As we already knew that session is wrong one? we could easily start new one right?

Show
venu added a comment - My requirement is, When user agent change session should destroy, and it should start new session. But Zend_Session::start() is throwing an exception if destroy was called before start(). <pre> try { Zend_Session::start(); } catch (Zend_Session_Exception $e) { Zend_Session::destroy(true); Zend_Session::start(); // breaking here Zend_Session::regenerateId(); } Zend_Session::registerValidator(new Zend_Session_Validator_HttpUserAgent()); </pre> I have a global session management in bootstrap, which validates the request and starts session. By that time, request won't be dispatched. Then why to make another request to redirect to another page? As we already knew that session is wrong one? we could easily start new one right?
Hide
venu added a comment -

I have posted a new issue here, Please check it once

Show
venu added a comment - I have posted a new issue here, Please check it once
Hide
venu added a comment -
Show
venu added a comment - here it is http://framework.zend.com/issues/browse/ZF-11420
Hide
Artur Bodera added a comment -

IMPORTANT!
session_destroy() will (by design) prevent any further session cookies to be sent.
This means your use case must be avoided if you are using cookies.

Here is more info in php manual comments:
http://www.php.net/manual/en/function.session-destroy.php#85379

Here are my analysis on the issue:
http://framework.zend.com/issues/browse/ZF2-52?focusedCommentId=48042&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-48042

Show
Artur Bodera added a comment - IMPORTANT! session_destroy() will (by design) prevent any further session cookies to be sent. This means your use case must be avoided if you are using cookies. Here is more info in php manual comments: http://www.php.net/manual/en/function.session-destroy.php#85379 Here are my analysis on the issue: http://framework.zend.com/issues/browse/ZF2-52?focusedCommentId=48042&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-48042

People

Vote (1)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
3d
Original Estimate - 3 days
Remaining:
3d
Remaining Estimate - 3 days
Logged:
Not Specified
Time Spent - Not Specified