Advanced PHP Destroying Sessions

Hello again, and welcome back to Educator.com's Advanced PHP with MySQL course.0000

In today's lesson, we are going to be continuing our discussion of sessions, and we are going to learn about how to properly destroy a session.0005

We are going to briefly talk about what the destruction of a session implies--what it actually means.0014

We are going to go over a built-in function to PHP that is used to destroy session data, called session_destroy.0019

And then, we are going to talk about some additional steps that you need to do, in addition to calling this session_destroy method,0027

to effectively end or delete or destroy a session.0033

That is going to involve manually deleting all of the session data and manually deleting session cookies.0039

Then, we are just going to go over a review of all of the steps that are involved in successfully ending a session.0046

And then, we are going to briefly talk about the topic of garbage collection, which talks about what happens0052

if a session is not successfully ended--what happens to that session data.0057

When either a client or a server determines that a session is over (for example, if a client wants to log out,0065

or a server decides that the user hasn't had any activity in a certain amount of time),0070

it can end that session; and that is called destroying the session.0076

What destroying the session does is undoes the two things that a session does:0082

namely, it cuts the link between any previous and any future HTTP transactions (because that is part of what a session does--0088

it links multiple requests together, so that they are considered part of the session between two parties0097

over a specific period of time), and it also gets rid of any of that session data associated with that particular session,0102

because that data is transient data, and when the session ends, it is no longer needed.0111

So, destroying a session is effectively getting rid of that data.0115

In PHP, for example, what that means is getting rid of that session data file in the tmp directory on the server,0119

freeing up that disk space to be used for other sessions.0126

PHP provides the session_destroy method that is used to destroy a session.0132

What it does is ensures that any session data stored on the server will be deleted.0139

All of those session files that we had looked at in previous lessons in the tmp directory (like sess_ and then the unique session ID)--0147

session_destroy, when it is called, deletes that session file, so that data is no longer accessible.0159

One thing to note about the session_destroy method is that, in order for you to call it in a script,0166

it has to already have or know about an initialized session, which indirectly means that, in order to call session_destroy,0174

you have to call session_start on that script before you do it.0181

This is a little counterintuitive, because you think, "OK, I'm destroying the session; why do I need to start it?"0185

But that is part of the process; so, in any script where you call session_destroy, before you call that method, you also need to call session_start.0189

Let's take a look at what session_destroy actually does.0199

We have a script called setSessionVar; this is similar to what we used in our last lecture.0207

What it does is starts a session and sets a username session variable equal to jsmith.0215

And then, it outputs a link to getSessionVar.php, which is a page that allows us to access that session variable.0221

Because it accesses session variables, it needs access to the _SESSION superglobal; in order to get that, it has to call session_start.0230

So, it is going to call session_start, which is going to see the cookie that the client provided with the session ID.0237

And then, it is going to use that to load the _SESSION superglobal.0243

Here, we have done a little bit of error checking to make sure that this username session variable does exist when the user comes to this page.0247

It is just checking: if that username session variable is set, go ahead and set this username variable to the value of that session variable.0259

And if not, we are going to set it to a string that is an italicized string, nonexistent, which means that it doesn't exist.0268

Then, what we do in the body of our HTML is: we are simply outputting that particular username that is part of the session, assuming that it exists.0279

We also output a new link that says to destroy the session; it is going to go to destroySession.php.0290

What that does is call our session_destroy method; now, as mentioned, in order to call session_destroy, you have to call session_start previously.0298

So, it calls session_start and then calls session_destroy.0308

And then, the body will attempt to output this session variable username, if it is still valid.0311

And it has the same ternary operation up here that tests for the existence of that username variable,0319

and will set username equal to that value, if it has been set.0327

And the reason why I have included this here (you might wonder why I am including that in a statement that is destroying the session)0333

is to show you the incomplete nature of what session_destroy does.0340

For example, this is our temporary directory; I'm going to delete all of our current session data files that we have in there.0346

If we go ahead and make sure that any session cookies are deleted, and then if we go to example-1, and we go to setSessionVar,0353

we can see that we have been set a session cookie that starts with r4gla.0361

If we go and look at our temporary directory that stores our session data files, we can see a data file that corresponds to r4gla.0368

The script is going to set that username variable; again, if we look it, a session variable is going to set it to jsmith.0379

So, when we click on nextPage, which is going to go to getSessionVar, we can see0384

that we are able to output and access this jsmith session variable that was set.0389

Again, we can see here that we have our r4gla cookie that was sent from the client to the server,0396

so that it knows that it is continuing this r4gla session, and therefore has access to that session variable that was set as part of that session.0402

Now, if we look here, we can still see that this session file exists.0411

And when we click on destroySession, we are going to notice a couple of things.0417

First of all, we can see that the session data file no longer exists, because session_destroy does that.0422

However, we can see that we are still able to output the username session variable.0430

If we go back and look at destroySession, we can see that, even though we have called session_destroy, we still have access to this session variable.0436

And the reason for that is that, when session_destroy is called, it doesn't destroy that session data file until after the script is finished running.0446

So, because of that, the information stored in that session data file, which has been loaded into _SESSION, is still available for the rest of this script.0454

That is why we are able to access that down here, and that is one of the issues that we are going to talk about, about destroying a session.0462

You want to manually destroy any session data that you already have, so that this can't happen--0467

because, in a way, it doesn't make sense that you are destroying a session, yet down here you are able to access that session information.0471

One thing to note is: if we go ahead and refresh that page, what is going to happen is:0479

if we look back here, when we start the session, it is still going to have that session cookie.0484

It is going to try to load data for that particular session, but because that data file has been destroyed,0490

it is not going to be able to load it, and so this username session variable is not going to exist.0495

And so, we are not going to be able to output anything.0500

If we go ahead and refresh the page, we can see that it shows nonexistent.0504

It shows that it actually did delete that data file, but when that script is immediately run, those session variables are still available.0507

To counteract that imperfection of session_destroy...not necessarily an imperfection, but intuitively, you think that0519

if you call a function session_destroy, it is going to completely end a session, but that is not necessarily the case...0529

As mentioned, one thing it doesn't do is delete the session data immediately.0537

So, it is still accessible in the rest of the script.0540

What we need to do is explicitly delete any session data, so that future portions of that script will no longer have access to that data.0544

And we can do that (as we learned about deleting session variables) using the unset method.0553

If we go and take a look at example-2, it has the same exact setSessionVar script and getSessionVar script;0560

however, its destroySessionVar script is different, in that now it actually unsets this session variable.0570

So, whereas in our last example, we tested for the existence of the variable and then set the variable username0577

to that session variable if it did exist, here we are explicitly unsetting, or deleting, the session variable.0586

Then, we call session_destroy; now, because we have called this unset method, when we go down here0594

to actually try and output the session variable username again, we are going to see that we are not going to be able to do that,0599

because we have unset that variable; so we have eliminated one of the problems with session_destroy.0606

We have now made that session variable inaccessible to the rest of the script.0610

So, we have a test down here that tests to see if that username session variable exists.0614

If it doesn't, it is going to say it is destroyed; and if it does, it is going to output it.0619

And assuming that everything works, we should never reach this else statement, because we are unsetting this session variable up here.0624

If we go and look at this new example, and clear our session cookies, and go to setSessionVar,0634

it is going to start our new session: am1j67 is the beginning of that session ID.0649

If we look at our temporary directory, we have that am1j67.0654

Now, we go to Next Page; we are going to have access to that session variable username, so we are able to output it.0659

Now, when we go to destroySession, it is going to output a message "session destroyed."0664

And additionally, in our temporary directory, we no longer have that...I don't remember what the exact name of that session ID was,0668

but we no longer have that session data file anymore, because session_destroy destroyed that after the script ended.0677

But as you can see now, the "session destroyed" message gets output, because we can see down here that0684

that session variable username is no longer available.0694

Another way (if we go back and look at our slide) to delete session variables: instead of going through0700

and individually unsetting each variable, you can just set the _SESSION superglobal array equal to the empty array,0708

which is going to erase any key/value pairs that it had.0715

So, it is going to delete any session variables that you have already created in that session.0719

And in general, that is the preferred method--the main reason being that it is easier to do,0728

and you don't have to remember every single session variable that you may have set.0733

We can go and update our script: instead of calling unset on username, we can just set _SESSION equal to the empty array.0737

And then, just to confirm that this works, we go back and delete our session cookie, and we run everything again.0751

Create a new session; v1hnaq is our session file; we are able to output that session variable.0761

Now, our session is showing that it was successfully destroyed, so that effectively deleted that variable.0774

And we no longer have that session file, which was v1hnaq; if you look back, it has been deleted.0779

So, we have still been able to delete all of our session data, and we have been able to destroy the session file.0785

Now that we have done that, there is still one more part of the process that we need to do.0794

It is: we have been able to delete our session data, which is part of destroying a session;0799

but the thing we haven't done is: we haven't been able to eliminate the connection between future HTTP requests and previous ones.0804

And that is what a session does: it links multiple requests together.0810

The reason that they are still linked together is because the session_destroy method doesn't actually destroy that session cookie.0813

Every time we continue to make requests to that website, our browser, unless that cookie is expired,0821

is still going to send that session cookie back to the web server.0826

And so, as far as our web server is concerned, it is still part of the same session.0832

And it is going to link those things together; so session_destroy doesn't destroy the session in that sense, either,0836

in that it doesn't cut that link between previous and future HTTP transactions.0842

For example, we have destroyed our session (this is example-2 again), but if we were to go back and...0850

(we can see that our session's name begins with v1hn; that is the name of our session ID)0860

try to start a new session again, setSessionVar, what we can see is that no cookie was set,0872

and we have continued to pass v1hna (that cookie) to the server, saying it is still part of the same session.0880

And that is a problem, because...it looks like when it created it, it re-created the session file, but what is going to happen is:0891

that would be a problem, because...the reason it re-created it is because this setSessionVar script...0904

what it does is goes ahead and, if the session is already created, creates that session variable.0914

So, it is going to go ahead and re-create that session data file.0919

Maybe...what I was trying to get at...a better example would be: if we go and destroy the session,0923

we can see that we still have this cookie that we are being passed.0932

If we look at the tmp directory, our data file has been destroyed, and so when we refresh this page,0937

we are still passing along that same cookie, except no session data exists for that particular file.0949

In order to sever all ties between past and future HTTP transactions, we must explicitly delete that session cookie.0959

And we do that using the setCookie method: we know that we can delete cookies0969

by setting a cookie with the same name of the cookie we want to delete with an expiration date that is in the past.0972

And there are two built-in functions to PHP that can help with destroying a session cookie.0984

One is called sessionName, which is going to return the name of sessions, which as we know is also the name of session cookies.0988

And by default, that is PHPSESSID.0994

And we use that method to load the name of the cookie that we are trying to destroy,0998

because maybe in different scenarios...this is a configurable option, so it could change.1002

Maybe somebody just, instead, decided to have session name equal to just SID.1008

That is going to allow us to load the appropriate name of the cookie to destroy.1021

Then, there is a method called sessionGetCookieParams, which allows us to get parameters of a cookie,1024

such as its domain and path, because also, when we are deleting a cookie,1029

we have to know the domain and the path for that particular cookie.1033

We need to know the name of the cookie, and then domain and path, in order to successfully delete it by setting its time into the past.1037

In our new version, version 3, setSessionVar and getSessionVar are the same.1045

However, in our destroySession, it has been updated.1051

We start the session, as we know that we need to do.1056

We have deleted any session data, and now we are going to delete the session cookie.1059

So, what we do is: we load the parameters for the particular session cookie, using this sessionGetCookieParams method.1064

And then, what we do is make short variables for all of the parameters of the cookie that we are going to be deleting.1072

We load the name of the cookie, which we use the sessionName method to do.1079

We are going to set the expiration of the cookie to expire an hour in the past, so that is going to effectively delete it.1083

We load the path of the cookie to make sure that, when we call the setCookie method,1089

we are deleting the cookie and have the path matched, so that it actually deletes the cookie.1093

And then, we also are getting a domain, so that the domain of the cookie we are deleting is going to match, so we will be able to delete it.1099

Then, we simply call the setCookie function with the name of the cookie, its path, and its domain1107

that we have been able to extract by calling this sessionGetCookieParams method.1114

And then, we are also going to set the expires, which is going to set it to expire in the past.1120

When that gets called, that Set-Cookie header is going to get sent.1125

The cookie is going to be destroyed; then we are also going to call session_destroy,1129

which is going to delete the data on the server after the script has ended.1133

And again, if we try to output the username session variable, we are not going to be able to do that, because it has been unset1138

Up here, when we deleted all the session data by setting _SESSION equal to the empty array.1145

So now, if we go and look at our new version, example-3, and delete any session cookies,1150

if we call setSessionVar, it has been assigned the ID in Set-Cookie 58k7.1161

So, remember that--that is the start of our session ID.1169

And we go to getSessionVar, where we are able to output the username method.1172

And just to refresh my memory, 58k7 is the beginning of the name of our session ID.1178

We look in our tmp directory; we can see that we have a 58k7 data file.1185

Now, when we click on...1191

Also, one other thing to note is that, if we look at our cookies currently, we have a 58k7 session cookie; so note that.1194

Now, when we click on destroySession, it is going to do those three things.1206

It is going to delete all our session data, so that we are not able to output that username variable.1211

It is going to delete the session cookie, and if we look at our HTTP header, we can see that it deleted the cookie.1216

It set PHPSESSID equal to deleted, and it set the cookie to expire in the past.1226

We have deleted the session cookie, and then, if we look at our tmp directory, we have also deleted that session data file.1231

It was 58k7, and if we look back, that file no longer exists.1237

So now, we have essentially, effectively ended our session.1243

We have deleted all the session data, so it is not available in the rest of the script.1246

We have deleted the session cookie, so that any future HTTP requests aren't linked to the session that we have just ended.1250

And then, we have also gone ahead and deleted any session data on the server associated with that session,1256

so that those server resources are available for future sessions.1261

And this is just a review of the steps that you need to properly destroy a session.1268

First, you need to call session_start, because first of all, you need to call that before you can call session_destroy.1273

And it is also going to give you access to the _SESSION superglobal, which is going to allow you to perform step 2,1279

which is to explicitly delete any session data stored in _SESSION.1284

And the easiest way to do that is just to set it to the empty array.1288

We have explicitly deleted the session cookie by calling the setCookie function and setting the session cookie to expire in the past, which will effectively delete it.1292

And then, we have destroyed the session data on the server by calling the session_destroy method.1305

Let's say that our session is not properly ended.1313

Let's say we did part of it--we have unset all of our session variables, and we have deleted our session cookie; but we forget to call session_destroy.1316

Well, what that is going to do is: that means that that is going to leave our particular session data file on the server.1325

And what happens is: in PHP, regardless of the expiration of a particular session's cookie,1333

that session's data file has a particular lifetime associated with it.1340

And it is something that you configure with the session.gc_max_lifetime configuration directive,1344

which is the number of seconds until a session data file is seen as garbage.1351

Even if you have a cookie that a user is passing back and forth to the server, that has a PHP session ID1356

for a session that it was a part of, if this max lifetime has been reached for a particular session data file,1364

then PHP may go ahead and delete that file, and so you don't have access to it.1376

It is another way of managing sessions, in which part of the reason for that is to make sure1381

that your temporary directive doesn't get filled up with all these sessions that were never effectively ended by calling session_destroy.1386

After this set amount of time, PHP considers a session data file to be garbage.1395

And PHP has what is known as a garbage collector process (and that is a term used in programming) to free up memory.1402

And what it does is: it periodically runs, and will remove any session data files that have been marked as garbage.1409

And so, what that does is allows any session data files for sessions that have gone on for too long,1415

and may not have been effectively destroyed, to keep from using up all of your server resources.1426

There are two other configuration directives: session.gc_probability and session.gc_divisor.1432

And they are advanced configuration directives (and in fact, all of these are) that we are not really going to get into the details of.1439

But basically, they describe how long it takes until a file gets marked as garbage.1446

And then also, these two describe what are the chances that that file is going to get deleted at the end of its lifetime.1451

It may continue to last for a little longer than its lifetime, depending on how these are set.1459

But they are all in the name of deleting any session data files that have gone on for sessions that no longer exist.1464

For example, if we go back to our destroySession script in our last example,1473

let's say we delete our session cookie, but we leave out the session_destroy method.1482

If we go back and re-run this example (let's delete any session cookies), and we set the session variable, and we view it;1490

we can see that we have created a session that starts with session ID nouha.1503

If we go and look at our tmp directory, we can see a session data file nouha.1509

Now, when we call destroySession, we can see that our cookie has been deleted by looking at the setCookie method.1515

So, our session cookie no longer exists, so our HTTP requests are no longer linked together.1523

However, if we look back at our tmp directory, we can see that this nouha session data file still exists,1530

because we didn't call session_destroy, and that is the purpose of session_destroy.1536

What that means is that eventually, there are default settings in php.ini that are going to know when that file is considered garbage.1540

And I think the default is about 24 minutes, or something like that.1549

And what it is going to do is check in 24 minutes; and if that file still exists, it will go ahead and delete it.1553

And that eliminates the problem where all your server memory or hard disk space1557

would get used up by sessions that were never properly destroyed.1564

Even if you do delete that cookie, if you don't call session_destroy, that data file isn't going to be deleted.1569

And so, that just talks about how the session data files also have a limited lifetime, as well.1574

In general, though, it shouldn't be something you should worry about, if you always call session_destroy when appropriate when destroying a session.1582

For the homework challenge, I want you to extend the homework challenge solution you made for lesson 25.1589

We are going to be adding a logout script to our application that is going to destroy a user's session.1595

We are going to say, "OK, when you have logged out, your session is over."1604

For example, if you were at a website where you go and log in, it might say your name at the top of each page.1607

And then, when you log out, it no longer does; that is effectively ending your session.1611

We are going to mimic that in our application by creating a script called logout.php.1616

We are going to add a link to logout.php on the members-only page, so that when we are viewing the members-only page,1621

we can click on that, and it will allow us to log out.1626

And in logout.php, at the top of the script, I want you to perform the four steps that are needed to properly destroy a session,1629

which are, again: Call session start. Delete all the session variables.1638

Delete the session cookie. And then, call session_destroy.1642

Then, if the session is successfully destroyed (which it should be, assuming that all these methods have been followed),1645

output a message that the user has been successfully logged out.1651

And then, provide him or her a link back to login.html.1655

If it wasn't successfully logged out, output an error message.1660

And again, assuming that this was done right, you shouldn't have to output that error message.1663

The way that you can test that a user is logged out is by verifying that the username session variable1668

that the user set on login.html is no longer set.1674

And again, that is how we checked to see if a user was logged in before: by just testing if the username session variable was set.1680

And so, you want to employ that test again.1692

And what you can do is: I want you to test your completed solution by logging into the site,1697

going to the members-only page, and then clicking on the Log Out link.1702

When you are on that logout page, one thing I want you to note is: note the SID of your session cookie.1707

By using Firebug, you can look at the cookie header and see what your session ID is.1713

And then, click on the link back to login.html.1717

And when you go back to login.html, I want you to log back in to the site and verify that you see1720

that a new session cookie with a different SID has been set.1726

And you will see a Set-Cookie header in Firebug; and what that is going to show you is that1730

you have successfully destroyed your session, and that you have just deleted your session cookie,1734

so that now, when you log in again and that session_start method is called, a new cookie is generated.1738

Also, verify that the session data file associated with your old SID that you looked at on logout.php has been erased.1744

And then, you also see that a new session data file, matching your new session ID, has been created.1752

One note as far as testing goes: one thing that is helpful in testing is to make sure that you delete any localhost cookies1758

stored by Firefox, before testing your solution, so that you don't run into problems1765

where you are not actually starting a new session when you first log into your website.1769

And the way, again, to do that is: if you go to Firefox, and then Options, if you click on the Privacy tab,1778

Remove individual cookies, you can search for any localhost cookies.1784

And here there are none, but you would just select them and click to remove them.1789

That ends today's lesson; thank you for watching Educator.com, and I look forward to seeing you next time.1795