I have a session that seems unkillable. The server runs PHP 4.0.0. It has register_global TRUE and track_vars FALSE. So I'm not sure really when to use $HTTP_SESSION_VARS['user_id'] and when to use just $user_id.

So here's my logout.php

<?php
@$HTTP_SESSION_VARS['user_id'] = "";
$user_id = "";
@session_unset();
@session_destroy();
Header("Location: index.php");
exit();
?>

You logged out.

btw: I have no ability to change the server PHP settings.

thanks for the help,
-j

    Actually, looks like it's PHP 4.0.5 but some of the functions seem missing like array_diff() and fflush().

    so track_vars is supposed to be TRUE. register_globals is also TRUE.

    Why can't I kill this thing?

    -j

      try this:

      unset($HTTP_SESSION_VARS['user_id'])

      I would use $HTTP_SESSION_VARS['user_id'] because $user_id could be passed in via the url, and hence could lead to unexpected results...

      Matt Wade
      codewalkers.com

        I've not seen the use of the @ symbol in php before, of course I could just be hanging out in different waters with my head down doing my own thing. Anyways, I've used the session_destroy function as:

        session_destroy();

        and it works fine. Is that an array notation you're using?

        A problem that I've just run into is that in my session test, when I turn cookies off, the session id variable is passed just fine through the url. But when I do the exact same thing on the page I want it for, the variable is NOT passed through the url at all! I'm tearing my hair out, it's the exact same code, system and browser. ONe will work without cookies the other will not. Any ideas?

        I hope I've helped, and I hope I can GET help! :-)

          ...is there to suppress any error messages that are thrown up by the statement. Usually they don't go in until you've finished debugging and know that further errors won't be important 🙂

          One thing I'll inquire about is: what happens if you session_unset() and session_destroy() alone? That usually works for me; clearing $HTTP_SESSION_VARS and $user_id won't have any effect, because they'll be cleared anyway as soon as the redirect take effect anyway.

            Okay, I think I've found the glitch. If I follow a link on the page, it appends the session id to the url and works fine, but if I reload it before doing anything else, it counts as a new visit. Guess I'll have to look into how to fix that, but chances are most folks aren't going to reload the page when they first get there anyways. This IS with cookies disabled. Works like a hot damn on browsers where cookies are enabled.

            Any ideas on how to fix that reload thing would be great. I'm going to go peruse the world of javascript to see if there's a work around out there.

            Thanks for listening!

              Hayley,
              Well, you're right about the @ causing me trouble. I couldn't figure out why the error message so I just nixed it. Silly me. I've solved the problem by calling session_start() before I go destroying things. That has cured my problem.

              Strangely enough in another script I do:
              session_register('user_id');
              $HTTP_SESSION_VARS['user_id'] = "foo";

              and the value is not passed to the next .php called. It only works if I do:
              $user_id = "foo";

              I've had different results on my home server and the live server. The only difference I can see is that the live server has register_globals set to TRUE. On the home server it's false.

              thanks for the help,

              -j

                Odd - is track_vars turned off? It wouldn't be in versions of PHP>=4.0.3, but perhaps the live server is an older version?

                  Write a Reply...