in reply to Session Problems

Are you saying the problem is just that $session is always there? This code is creating a new session if there isn't one already. You aren't setting $session{userid} anywhere in this code, so I don't know what you're doing with that or how you expected it to behave.

One thing that I don't like about this code is how it doesn't always clean up if something goes wrong during handling the request. I think it would be better to put your session in $r->pnotes() than in a global, because pnotes is always cleaned up at the end of the request, even if Mason dies on something. If you haven't used pnotes before, see the docs that came with mod_perl or the Guide.

Replies are listed 'Best First'.
Re: Re: Session Problems
by Anonymous Monk on Aug 15, 2001 at 19:33 UTC
    $session{userid} *should* only exist if the person has a cookie from logging in. When they logout, $session{userid} is set to undef, and (as I understand it) the row in the DB is deleted. $session is a tied hash, so when someone connects they should get a new (empty) cookie if they don't have one; if they have one, then $session{userid} is whataver is stored in that.

    However, apparently doing $session{userid} = undef; *does* get rid of the info in the DB, but does not keep the child from remembering the value of $session{userid}.

    I don't know what's going on.

    dstar (forgot to log in)

      Okay, first off $session{userid} is not set anywhere in your sample code, and unless you're setting it somewhere else it will never get set to anything.

      Second, there is no concept of "loggin in" and "logging out" in this code. It assigns anyone who comes along a cookie with a session ID, and creates backend storage for that session. It never makes any attempt to delete anything from the database. Are you talking about some other code that you didn't post?

      There is a session ID, $session{_session_id}. Is that what you're talking about?

      Note that Apache::Session stores all data as a BLOB serialized by Storable, so removing a value from the session should not cause anything to be deleted from the database, it would just update the row for that session. Values are not stored as separate rows.

        Yes, there's some code I didn't post (sorry):

        the login code takes a username and password from a form, looks up the username in the DB, and checks to see if the password matches. If it does, it sets $session{userid} to the users userid.

        The logout code simply sets $session{userid} to undef.

        I may have discovered the problem. As I understand it, there should be a row in the sessions table for each cookie issued, right? I have *no* rows in my sessions table.

        I can't shake the feeling that I've completely missed something in how the sessions code works.