session_destroy vs session_unset & a few cookie questions

[jdlev]

The two functions seem very similar. What is really the difference between the two?  Is there any reason to use both, or does say, session_destroy do everything session_unset does and then some?

 

Is the only way to destroy the session server side to use setcookie("","",time()-3600) to change the cookie expiration time to some point in the past?

 

Is it correct that neither of the two functions deletes the session cookie at the client?  Is there a way to do that?

 

When you logout a user, do you have to use session_start() at the beginning of the page?  That seems to be the only way I've gotten it to work?

 

Now for my really, really dumb, uber noob question.  On my server, I can open up a session text file in notepad and see all the corresponding variables.  In chrome, using inspect element, I can see the name of the cookie and the cookie ID.  Am I correct in saying that the cookie name/id are the only things the end user can see, or do they see all of the information that is stored on my server in the cookie text file?  I assume the cookie ID just acts as a reference to the information server side...cookies seem pretty worthless if they don't hide the information from the end user.

 

Here's something else I'm not getting.  In the code below, why would it treat that statement as false (not having a session)?  I thought: if($_SESSION) and if(isset($_SESSION)) were essentially the same thing?

// Let's say we have an active session

session_start();

 

//Why is this false?

if($_SESSION)

{false}

else
{true}

//And this statement is true?
if (isset($_SESSION))
{true}

else

{false}

 

Edited June 26, 2013 by jdlev

[ginerjm]

This is pretty much all discussed in the php manual.

 

us.php.net/manual/en/function.session-unset.php

[jdlev]

This is pretty much all discussed in the php manual.

 

us.php.net/manual/en/function.session-unset.php

 

I know...but I'm a complete moron.  It's like i'm dyslexic sometimes when it comes to understanding what is in the manual.  These are just some things I read through in the manual that I didn't understand 100% and was looking for some clarification.

[ginerjm]

Decrying yourself as a complete moron when reading is not the way to get ahead.  I just read the manual for the first time (on this subject) and it makes perfect sense to me.  Maybe it's just your lack (?) of understanding of php that prevents you from understanding what these (probably) advanced functions are all about?

 

Why are you so curious about these functions?  I've been into PHP for  3 years, but I've never had use of these.  Give it time and it may make sense.  In the meantime, if you want to succeed in this endeavor you better get used to reading manuals.

 

Just my $.02

 

And as for your question about "if($_SESSION)"  I think you mis-read your test results.  This code:

if ($_SESSION)
  echo "true";
else
   echo "false";

returns true for me.

[DavidAM]

@ginerjm: This is a "help" site, we are here to help people understand and fix things. We do not attack people for admitting they do not understand. If you don't want to be bothered by this kind of question, then move on to the next post. Don't try to pad your post-count by attacking our visitors.

 

@jdlev:

The two functions seem very similar. What is really the difference between the two?  Is there any reason to use both, or does say, session_destroy do everything session_unset does and then some?

From the PHP manual session_destroy:

Only use session_unset() for older deprecated code that does not use $_SESSION.

session_unset() is a holdover from the days of session_register(). I have never used this function (didn't even know it was there until I read your post) -- so, I learned something new from you.

 

Is the only way to destroy the session server side to use setcookie("","",time()-3600) to change the cookie expiration time to some point in the past?

 

Is it correct that neither of the two functions deletes the session cookie at the client?  Is there a way to do that?

The session data is held in the $_SESSION array during script execution. When the script is finished (or you call session_write_close the data is written to a disk file ON THE SERVER.

 

The cookie (as with all cookies) is stored on the client. It contains only a hash (unique id) that identifies the session. The browser sends this cookie whenever it requests a page.

 

The session_start() function retrieves this hash from the cookie (if one is sent by the browser) and locates the disk file by that name. It opens the file and reads the data into the $_SESSION array for the script. It will also send the cookie to the browser for the next request.

 

So setcookie will NOT destroy the session data ON THE SERVER, it simply tells the browser to forget about the session. It will (if the browser is well behaved) expire the cookie so it can be deleted.

 

When you logout a user, do you have to use session_start() at the beginning of the page?  That seems to be the only way I've gotten it to work?

YES. See the manual for session_destroy, the Example they give shows code to completely clear the session.

 

Now for my really, really dumb, uber noob question.  On my server, I can open up a session text file in notepad and see all the corresponding variables.  In chrome, using inspect element, I can see the name of the cookie and the cookie ID.  Am I correct in saying that the cookie name/id are the only things the end user can see, or do they see all of the information that is stored on my server in the cookie text file?  I assume the cookie ID just acts as a reference to the information server side...cookies seem pretty worthless if they don't hide the information from the end user.

Correct. The only thing the client can see is the hash (or ID) of the session. The client cannot directly see the contents of the SESSION. However, as you know, the file can be openned with notepad (or any file utility) ON THE SERVER, to see the contents. Since the session files are stored on the server in an area that is readable and writeable by the webserver, it is possible for someone with access to the server to view these files (especially on shared hosting). This is another reason we never store passwords in the session.

 

Here's something else I'm not getting.  In the code below, why would it treat that statement as false (not having a session)?  I thought: if($_SESSION) and if(isset($_SESSION)) were essentially the same thing?

// Let's say we have an active session
session_start();
 
//Why is this false?
if($_SESSION)
{false}
else
{true}

//And this statement is true?
if (isset($_SESSION))
{true}
else

 

I personally avoid using that kind of if: if ($_SESSION) it is not clear when reading the code at a later time, what you are testing there. And frankly, I'm not sure when that would be true and when it would be false. That makes it unreliable in my mind, so I would just use something more concrete. However, I suspect that if a new session has been started and nothing was ever stored in it, that first IF would be false. If you simply want to know if a session has been started, I believe if (session_id()) is a better test. That function returns an empty string if there is no session or it returns the id (the hash) if one has been started. Looks like PHP 5.4 has session_status which would be a better choice entirely. If you want to know about some specific session variable, if (isset($_SESSION['userid'])) would be my choice.

[ginerjm]

To DavidAM:  My response was not aimed at harming the OP -merely to suggest to him that reading manuals is where ultimate knowledge is to be gained.  I don't think anything I wrote should have been taken in a bad way.

 

  As for my seeking to up my post count here:  That is the second time someone has suggested that to me.  What is up with that?  Do people really care about post counts here?  I don't get it.  What - do we all get a prize when we reach a milestone?  Can I have my points removed and my posts not counted?  That would be great!