SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Zend_Auth -> session already started issue

    Hello,

    I'm integrating the Zend_Auth component to one my app. The authenticate method uses Zend_Session. My problem is: my app uses session_start(), and I get an error message telling me that the session is already started using session_start(), which I need.

    Is there a way to work around this issue without tweaking php.ini or providing my own storage class to Zend_Auth?

    Regards,

    -jj.

  2. #2
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,788
    Mentioned
    151 Post(s)
    Tagged
    3 Thread(s)
    Hi JJ,
    Apend the session_start with the @ symbol.
    This will suppress the error and you will be able to carry on

    PHP Code:
    @session_start(); 
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  3. #3
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for your reply.

    It doesn't change a thing unfortunately. The problem is that Zend_session tries to start the session, but it's already started, even with the @ approach.

  4. #4
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,788
    Mentioned
    151 Post(s)
    Tagged
    3 Thread(s)
    Looking through the documentation for the Zend_session, it appears that anything to so with session_start() will throw an error. http://framework.zend.com/manual/en/...ting_a_session

    If you call session_start() after using Zend_Session_Namespace or calling Zend_Session::start(), an error of level E_NOTICE will be generated, and the call will be ignored.
    So if its ignored then but you must have it (?) then you will have to disable the error_reporting on the live site
    PHP Code:
    ini_set("display_errors"0); 

    // or

    // Turn off all error reporting
    error_reporting(0); 
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  5. #5
    SitePoint Member
    Join Date
    Oct 2008
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jjshell View Post
    Thanks for your reply.

    It doesn't change a thing unfortunately. The problem is that Zend_session tries to start the session, but it's already started, even with the @ approach.
    Is there a chance that you can edit your code so that you use the Zend_Session component in your entire application? That would solve the problem. Or, just delete your own session_start() call and then instantiate a Zend_Session object first thing you need sessions.

    @spikeZ: You're like Speedy Gonzales.. you were a few seconds earlier with your post

    In reaction to your post, I'd say that for a development website, turning off the display of all the errors isn't the best thing to do when you're developing an application. In my opinion, you should always try to make it work, even with error_reporting set to the highest degree. I would see your solution as a quick fix, which can be quite convenient for production websites sometimes.

    Just my $0.02 though..

  6. #6
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    blahblahblah
    Posts
    1,447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks guys

    I'll keep a strict error reporting until I reach developpement.

    It's sad Zend_Session doesn't accomodate with other approaches to sessions. It makes it hard to use the component by itself.

    Here's what I'll do:

    1. search for another session component in another framework.

    2. If 1. fails, I'll use Zend_Session throughout my whole application (it won't be hard to edit my code, a bit of extending here and there and the trick will be done. But then my entire application will depend on this particular ZF component, which I wanted to avoid...)


  7. #7
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,788
    Mentioned
    151 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Martin.Green View Post

    @spikeZ: You're like Speedy Gonzales.. you were a few seconds earlier with your post


    Quote Originally Posted by Martin.Green View Post
    In reaction to your post, I'd say that for a development website, turning off the display of all the errors isn't the best thing to do when you're developing an application. In my opinion, you should always try to make it work, even with error_reporting set to the highest degree. I would see your solution as a quick fix, which can be quite convenient for production websites sometimes.

    Just my $0.02 though..
    I agree completely, if you can produce your code error free and fix rather than fudge then that is far better
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  8. #8
    SitePoint Member
    Join Date
    Oct 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Errors, warnings, and notices show for a reason and should only be commented out only if an immediate fix is not available. In this case, the fix is easy. Just like ob_start() which kills "headers sent already" errors, session_start() must proceed all output and show once per instance.

    @ = lazy coding
    Need high quality, fast, and secure coding?

  9. #9
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,788
    Mentioned
    151 Post(s)
    Tagged
    3 Thread(s)
    but surely ob_start is a fudge and not a fix for the problem. You are not fixing the problem but masking it by sending the output to the buffer instead of suppressing an error message - same thing really.
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  10. #10
    SitePoint Member
    Join Date
    Oct 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by spikeZ View Post
    but surely ob_start is a fudge and not a fix for the problem. You are not fixing the problem but masking it by sending the output to the buffer instead of suppressing an error message - same thing really.
    No it isn't actually. It sticks the data into the buffer. It is a fix, a workaround, not a cover up. It hides nothing and it is a fix recommended by Zend. By going into the buffer, the data is organized properly before being parsed to the browser.
    Need high quality, fast, and secure coding?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •