How To:PHP Sessions/Cookies, complete information

[Ninjakreborn]

Here is the entire tutorial again, I deleted the other one, it got too big to fit in a single post, I want to put them side by side though.

[b]PHP Session and Cookie Tutorial[/b]

This tutorial is intented to cover everything related to sessions or cookies in php. It starts off with a simple introduction to cookies, then a simple introduction to sessions. Then it compares and related sessions and cookies. Then we start by introducing the basic structure and uses of sessions, and cookies. And how cookies are used with sessions, and the security issues with each. Afterwards in some of the later sections i will started explaining performance issues and alternatives strictly relating to sessions and cookies IN PHP. I do not cover any other languages in this tutorial, but may if I have time present a few ways in which php session and cookie handling and functions differ from that of other primary languages. Please note this tutorial might change at any time, if you read the whole thing now, chances are in 3 months, bits and pieces would have changed, been updated, or moved around and made more accurate, or even added new sections to the tutorial if this tutorial helped you, check back to it often for new, or updated information. This can happen without any notice, even in the recent updates, I put updates in there as often as possible.

[b]Cookies[/b]

In general a web browser is meant to be able to have the ability to handle 100 cookies from any one site at any one time. This is however unnecessary, as 1 cookie, can hold plenty of information. In general it is said that it is best to keep the file size of cookies down to a substantial amount. 24 kilobytes is what they suggest. As far as in related to php, cookies are very easy to implement, and use. The php module hands allmost all the cookie information. People believe various things about cookies that are the farthest from reality that you can get. Some common misconceptions people can acquire about cookies, that are totally untrue are. Some people believeCookies are like worms and viruses in that they can erase data from the user's hard disks. This is totally untrue because of security reasons, the creators of php, and all the other main languages develop the cookie system in a way to prevent this kind of abuse. The cookie technology on it's own aside from usage through a language also has it's limits, and prevents these kinds of things from happening. Other people end up believing that Cookies are a form of spyware in that they can read personal information stored on the user's computer. Cookies are not programs, there is nothing they CAN do. They can't DO anything. They are simple like a piece of paper to hold information. If it's in relation to session they simply hold a number (usually random) that identifys the person. It can in no way get access to or do anything with your information, or even access your other cookies. The area in the browser that is set aside to hold cookie information also has restrictions to prevent any form of actions being performed from that location as a simple safeguard. Cookies cannot in any way generate popups to or from your computer. If you have popups coming up it could be spyware, malware, or something worse, but it cannot be caused by cookies in any way shape or form. Cookies cannot gather information in any way. They cannot get your email address, or phone number from your computer, or read your ip number in any way shape or form. PHP itself has some uses, that can pull the person's email address from there browser if it's registered, but cookies have no association with this in any way. Cookies are not only if ever used for advertising. They are simply used to save preference or login username and password(which is not recommended, explained later). 90-100% of all browsers have cookie capability. I don't know of any browser in existence that doesn't have cookie capabilities. However the browser makers leave it in the hands of the owner whether or not they are going to use cookies. They allow them to pick settings based on what they need. This includes the special option on most browsers to only accept cookies from selected sites. This was just a rundown on some of the history of cookies, and it's uses. I will go more into detail later. Now let's continue onto sessions.

[b]Negative Aspects of Cookie Use[/b]

A few things can make cookies a little less desirable. The first thing would be misidentification. If someone has more than 1 browser, then if you have a cookie set to them, and they return with another browser it does not pick up that cookie unfortunately. This is because each browser not only handles cookies differently, but they store them in different places and each place is unique for that individual browser. So if they have 3 browsers, they have 3 different areas those browsers store the cookies. Possibly making true identification difficult at best. But this is rarely a problem that is even worth considering, because anyone with basic browser knowledge or regularly runs a browser, would notice if they login to a site with one browser and visits the site again on the same computer with another browser they are no longer logged in. And 90% of the people out there use only 1 browser and use the same browser for everything. Another downfall of cookies is bypassable as long as you don't pass sensitive information to or from the cookie. Cookies themselves can be intercepted with something as simple as a mini-program called a packet sniffer. So it is best to only send fun, or small information using cookies, username's and passwords are not a good idea, because even the username, if someone get's that then they have half the information needed to get a successful login. Another bad thing can also be avoided simply by not passing sensitive information. Cookies can be changed on the computer, so for instance if you have a shopping cart and you are storing saved items in cookies, or the information for them, someone could change the item name, or price, and get charged a less price for it, or get charged 1 penny instead of the original price. This can however be avoided simply by not using cookies for any important or sensitive information. Another severe bad issue with cookies is cross side cookie attacks. To find out more information about this, and to find out ways to prevent it, which are beyond the scope of this tutorial please visit Wikipedia Information for everything you need to know about this issue and how to prevent it. Also for any more in depth information regarding cookies, there history flaws or other information visit the following website. Cookie Information. Don't simply search for cookie, or you get a big picture of an edible cookie which is what I did, and got the first time when I was doing some history research behind it.

[b]Sessions[/b]

Sessions are a lot easier to deal with, and use than cookies. Not necessarily in use, but in ease of mind, as avoiding a lot of the issues that come from using cookies. There is nothing really to say about sessions, there are 3 rules involed with there use, if they are followed you can use sessions effortlessly, without much of a problem or issue. They are the same as cookies in that they store information, but they store them on the server instead, in one of various ways, and have a way for the browser to simply identify the session when it passes by, using either a cookie containing a session id, or passing them through url's which would be stupid. Here is the thing that makes session simple. I will go into further detail into all of this when I start to explain how to use sessions later on in this chapter.

[b]Sessions Vrs Cookies[/b]

There really is nothing to say or care about saying anything related to this. It's a pointless debate, and pointless conversation. They both are good, they both have there good qualities, and they both have there bad qualities. In my personal preferences, I find cookies useful in a few small situations. Like you have a client with an admin page and ONLY he is going to be loggin in, I just setup a permanent cookie and he can login, that's it. When he revisits he is logged in. I also use cookies on small tasks to save preferences, like website background color or things like that. For sessions it's best with multiple people loggin in, or something similar. They are more secure than cookies by a longshot but they still have there security flaws and issues.

[b]Using Cookies[/b]

Cookies are very easy to use. The first thing to remember when using cookies is there is no way to use cookies instantaneiously, with maybe the except of an ajax application, but I am making this strictly php based. I don't see why you couldn't create cookies without reloading the browser if you were using ajax, but that would be for another tutorial. For now let's keep this simple and to the point. Cookies are not like sessions in any way shape or form as far as there implementation. Honestly I like session implementation a lot more because it is not as strict. If you look at that page from wikipedia near the bottom you see how difficult it can be setting up and using cookies without the aide of a server side programming language. The PHP languages triples the ease in using cookies compared to having to roll them and prepare them yourself. I think I heard it call cookie rolling when you have to build the cookie requests yourself from scratch with no language support. As for PHP it has 100% support for cookies and use of it in all it's forms. As for utilizing them in php it is very easy, as long as you follow a couple of basic, and very important rule. THESE RULES FOR NOW APPLY TO COOKIES ONLY, SESSIONS ARE BELOW. For general cookie usage you can handle everything with php's functions. The thing is you only need 1 function for total cookie handling. The only function for now, actually probably period, that you will need to know for any general and advanced cookie usage is set_cookie(). I want to go over with this for you in a very detailed and controlled enviroment, to try and help you understand each element of how to use a cookie. First of all I will present a full example on how to set a cookie.


<?php
setcookie("password", $password, $expire, "/administration/",
".funnyemailforwards.com",);
?>


As far as this specific code is concerned, I am going to break down the elements so I can show you how they are used fully. I will try to cover as many issues as people generally run across during the use of cookies, as much as I can. The first and main rule of cookies, is that pages can't use cookies on the same page. For instance, there has to be some user action to set the cookie, the setcookie differs from sessions is that for you to set the cookie is to have it at the very, very top of the screen. It has to recieve it's parameters when the page first loads, and on subsequent page visits. So that is the main and first general rule of using cookies. Now let's take a lot at the parameters of the setcookie() php function. There is a possibility of passing this function 7 parameters total. The normal user of cookies will only need to really use 3 max. Maybe the extra 2 if you get a little more advanced, all parameters though can be useful and simply take a few minutes to memorize. They always take the same values and return the same thing. setcookie() is the function name. The first parameter is called the name. As with php if you have a variable "name" that has a value. The NAME parameter for cookie is the name of the cookie you are setting. It's setting that as the key for the cookie. So if you have like what I have above, with the name of the cookie being password. To access this variable it's $_COOKIE['password'] That searches in the cookie array for the password name, and then returns it's value. You have to of course use it for logic purposes, echo it, or capture it for use, however you program that is not covered in this tutorial. As far as the second parameter it's simply the value of the variable. If you say


<?php
echo $_COOKIE['password'];
?>


What is going to happen is it's going to echo out whatever you had the second parameter of setcookie too. If the second parameter was dave. Then it would echo the word dave when you did that. I am unsure if you can pass an array as the second parameter and don't have the time to check but it's worth testing purposes, if someone has time, fill me in and I will credit the information from whoever submits it. Now this pretty much explains the first and second parameter except for one thing. If they are in the form of a variable, for instance if you are passing a php variable containing information into the setcookie() for purposes like doing things dynamically you do not need quotes for that. If you pass a raw string out of nowhere, it's best to use "" around whatever you put. Also ALWAYS use comma's after each parameter except the last one. When you put your last parameter just put the closing brace. ALL PARAMETERS don't have to have values just 3, I am about to introduce the 3rd one now, the rest are optional and not required, leavin them blank they result back to there original defaults, they aren't anything you have to concern yourself with for average uses, but I will explain them in the future anyway just for your benefit, some of them can save you lot's of time. The third "and final required parameter" is the timelimit of the cookie. Basically when you have food or something it expires after a certain date, and you throw it out. That is the same for the third parameter. Now this is almost the same thing for setcookie(). It runs off of seconds, after that amount of seconds goes by the browser automatically deletes the cookie completely from the server. It accepts an integer, so you can do 2 things, pass it straight into the function or set it in a variable and pass the variable instead. Either way you choose you DO NOT need quotation marks around the third parameter. Also if it's your last parameter you do not put a comma after it but instead immediately close the function after that with the ) symbol. As far what it takes, You know, NO MATTER WHAT don't include quotes around the third parameter. No matter how you pass it to the function. You can pass it either directly or through a variable. Either way it can be done in a variety of ways. You can pass a straight number, it is seconds, so this tends to be useless. So what you end up wanting to do is make it automatically create a higher number of seconds without having to worry about it. time()+3600 that sets it to expire in one hour. Just increase the number of seconds to add more time. Replace 3600, to 10000 will be over 2 hours. It is said that using PHP_INT_MAX sets it to infinite. This works "Only occassionally" so it's not recommended, as errors can surface later. If you want it to work to where you never have to deal with it again, set it to something outraegious like this.


<?php
$expire = time() + (6000000*30);
?>


I can almost guarantee you with that, you will never have to care about the cookie expiring, I suppose you would be dead before it ever expired.

This is were I explain the final 4 parameters of setcookie() The last 4 parameters are finicky and a little tricky to explain. The first 2 in line are fairly common, and straightforward. The 1 after that is used only under certain conditions and the final one is only available in php 5.2.0 For starters the first 2 generally go together. They have to do with what domain name the cookies are valid for. The fourth parameter picks a sub-directory, the fifth picks the domain itself. There are a lot of things you can do with these, in order to ignore the first parameter(basically make it good for that whole specific domain, set the fourth and fifth parameters to


<?php
"", ".domainname.com")
?>


That should make it work throughout the whole current site, but then there is no point because by default it does this anyway. So this is only useful to set it to a specific directory. In the fourth parameter you just specify the directory, like /uploads/ or whatever that means everything on and below the uploads directory, if you aren't specifying a specific directory then leaving them alone achieves the same thing.

There are 2 final parameters, these are pretty straight forward. SECURE, this is simply a true or false. True means yes false means no. Leaving it blank defaults to false. What this has to do with is ONLY in related to something called https, "Secure Socket Layers". If the parameter is set to true it will only allow the cookie to set if it's over a secure connection, if it's set to false "default" it doesn't matter whether it is secure connection or not. The final parameter is called httponly. This is limited on how much you will see it or use it at this point, it's only available on php version 5.2.0. The parameter decides whether the script can be used with scripting languages like javascript, or vbscript or other like languages. If true then other scripting languages can't touch it, if false they can. Defaults to false, non-existence when non-applicable "have an earlier version, before it was added.". Also some side notes pointed out on php.net are, that you can't pass a true or false as the second parameter, if you need to pass booleans, for values use 0 for false or 1 for true instead. Also another point is If you want to delete a cookie, use the same parameters you use to delete it as you did to create it, as well as teh exact same number of parameters, or it won't detele correctly. Please note "speculation only" I have heard if you want cookies to work totally correctly (as far as expiration dates, you have to specify all parameters, I don't see the point because I never encountered these problems myself.

[b]Sessions[/b]

Sessions are considerably easy, and even more fun than cookies. I love sessions and use them most of the time, they are easy to use, easy to manipulate and even easier to deal with. Following a few rules will make it good and good thing with sessions, on a basic level, absolutely no extra parameters to deal with. The first and main, unbreakable rule is called session_start() before I tell you what it is, or how to use it, let me give you a good example on the concept of it's use with a few examples.

Examply 1: You have a baby. The baby, given freedom, is created at the hospital. It moves from place to place, as it get's older it even get's more freedom. That freedom isn't without limits for the baby to actual move freely, the parent has to go ahead of time to each room and prepare the way by "baby proofing" the area the baby is about to visit BEFORE the baby can there there, the parent also watches over it, to make sure everything goes smoothly WHILE it is there.

Example 2:Someone is going to build a house, the framework needs built BEFORE the house can. Say someone is building a subdivision, every house has to have framework on every lot, BEFORE the house can be built. Each house has to have the area prepared first.

Now from a programming perspective, The sessions can be created anywhere, more on this later. Say they are created on page 1. Before page one creates them, the area has to be prepared. We do this, by "AT THE VERY TOP OF THE SCREEN", I can't specific this enough, very top of the screen, we call the session_start function, above the page that we are creating the session. When the session start is called it alread prepared everything ahead of time to recieve any new sessions that might be created. Now after the session is created, it is probably going to want to move around some, between pages. For instance if it wanted to go to page 2, if it just goes there, then the session itself, doesn't die, but it doesn't exist on that page. so it has to get created again, or reidentified on page 1, depending on the situation, more on this later. Now in order to prepare page 2 session start needs to be there too. Session start is an easy function, it's so mobile you can copy and paste whatyou see here on every page of your website, and that completely takes care of all the preperation work associated with using sessions. That is all that needs to be done BEFORE actually working with the sessions themselves.


<?php
session_start();
?>


After you have done that, the step one, which is preperation is now complete. The only other 3 steps, and one is optional is creating the sessions, and using and working with the session information. The third thing is destroy them with logout pages, that is only 1 function call with no parameters, more on that later. As for creating session "ALL tutorial information in this section is based on php's default session handling methods. I will give you detailed information on working with the php.ini settings and working on alternative session handling in another section. For now it is assuming that everything is default, php is using cookies to pass session id's and sessions are saved in temp files, as set by default. Following this on default will teach you sessions THEN we can move onto doing custom session handling, and what everything in the php.ini in relation to sessions mean, and what all you can possibly pass anything into the ini file, more on that later. As for now, the bottom line is sessions can be created anywhere in the page, it doesn't matter, session start sends the headers out ahead of time, so you can call them anyway, this is a hell of a good alternative to cookies. You can set sessions based on user action instead of on page load, making it very compatible with ajax programming methods. Session register is the old way, it's deprecated now, and in my opinion deprecated sucks so I am not covering that here. The new way is much simpler and funner. You simply declare a session variable in the same way you would declare a php variable.


<?php
$_SESSION['variable1'] = "test";
$_SESSION['username'] = "dave";
$_SESSION['password'] = "die";
$_SESSION['controller'] = true;
?>


I just declared 4 session variables. Now I will explain what controller itself does later on, it's my own personal creation, giving me total controller over what is visible and invisible to the person logged in. It makes it to where if they are logged in, I can make the register page, and links disappear, and everything. I feel more in power when I use it. As far as calling php session variables that's it the variables are now set with the values. Php sessions are access the same way as any other array explained earlier.


<?php
echo $_SESSION['variable1'];
echo $_SESSION['username'];
echo $_SESSION['password'];
echo $_SESSION['controller'];
?>


That echo's out all the values. You can also use those inside control structures or wherever else to test to see if there logged in, or use the control one to hide stuff from logged in people or reveal stuff they get to see that non-logged in people don't including full blown page accesses(access to pages that would otherwise be inaccessible without being logged in). Now you should know how to use sessions, in the next sections i will explain a few things, like the programmatically differences between sessions/cookies, and security issues, with session. As well as php.ini information as pertaining to session related use.

Now you know how to prepare the way for your sessions, and you know how to create session variables, and use them in code. Now I am going to explain a self-created technique I use. A lot of people probably use a lot of different techniques, that's what being a programmer is about. I love creating things myself from scratch, A lot of people probably invented this before me, but it's still a good thing to me that I created this from scratch. I call it the session controller technique. When someone has a login area, and they set up there sessions, there may be times they want to show things to people logged in, and even take things away. For instance, if someone registers, and logs in, the programmer doesn't want to allow the person to see the login page anymore, or the session page. With the controller technique, I can make it to where it shows things to people who are logged in that it normally wouldn't and if there is something you want to disappear once they log in, it does that as well. This is a technique that allows you to control all of that. Also if you are in the situation where you have login panels that must accompany multiple user permissions this can work in a modified manner. Normally I like creating the website. Then I normally create a smaller version of the site that deals with administration purposes. I normally create an interface for the admin. When I create it, I have a mini-site, in basic html, with no css or any type of formatting, just links to various pages, that do various things. THey can control everything there, I can create a 20 page admin system in 9 hours, compared to spending 20 setting up user permissions on a previous site. There are a few exceptions, for instance if you have a site that the user's have different level of membership, this controller method can be applied to allow some user's see some things, while other's can see even more and so forth. I do this using the step level method I created. I create my sessions, and It depends on the number of different types of users. I call level 1 the base level, they have the basic, smallest amount of access to the site, then the highest level has the highest. For instance in a forum users have different levels, say there are 5 ranks. I will have the levels 1 through 5 set as sessions, depending on there permission level, if they have total permission I know to set that user (on login) to level 5. Total access if they have less access level 4. if they are just a new sign up, they start at level 1. Then I can also add to that later in the future, if I want for instance guests to have read only status for 30 days, I can set up the session to a temp controller. I call them all controllers, I would set a temp controller, this allows me to have full control over what they are doing temporarily. I like programming, I like creating techniques, this part of the tutorial is still open to submission. If you have a technique that you use, that is secure, then I will put it here wherever is appropriate under your own section that say's (insert name here's) technique.

[b]Special Considerations[/b]

There are always special issues when it comes to things like special considerations. One for instance is occassionally people run across issues like the session delete's itself, this is sometimes caused by the |symbol. Sometimes if the session name, or value has a pipe symbol it kills the session, just a note incase if you were encountering similiar problems, there is a note about it, I have heard, in the documentation somewhere.

[b]PHP.INI Related Information[/b]

A lot of places tell you a list of information on php.ini preferences. None of them however seem to go into detail enough to explain in plain english what each php.ini option is for, how to find them and what to do with them when you find them if anything. I am going to try and be very thourough here. I will start with a brief explanation on how to find the ones, I will tell you what to do. Then I will cut each option in the php.ini into a different section here so they are easy to find. There is no need to take each one and translate it in 4 different languages. Some are not even of use to you, and some of the areas I haven't even started playing with yet, I want to try avoid feeding you bad information, if I left one out which I will try not too, it meant it's either irrelevant, or at the last, something I didn't understand, but I will try to put down I don't understand one if I don't. Let's get started on breaking up this information.

[Ninjakreborn]

[b]Php.ini primer(primer means beginning tutorial, to prepare you)[/b]

Here is a breakdown of how to use, what is, and what to do with a php.ini. The php.ini file is fairly large, so I am only speaking here of things that directly relate to sessions or cookies, messing with anything else without needing to, or without knowing what it is, is something best left to situations. If you are using sessions/cookies, you are automatically in a situation where you need to know and possibly use the php.ini to change preferences as to how your sessions/cookies function. This is common sense, but when using sessions/cookies only you aren't going to need to know about, or really care about, what preferences, are related to change the max_upload size for the server, it has nothing to do with sessions or cookies, so it's best to leave everything not related out. As far as php.ini itself. What is hard, is I didn't find anything on these a lot of this I had to create from experience, so forgive me if some of it is wrong, or slightly off, or a little incorrect. I will list them in order as far as the php.ini file itself, it's simply a configuration file that controls the behaviour of php. It controls every little detail. There are some web server's for web hosts that do not allow access to the php.ini file, and I find this stupid. This is the most idiotic thing they could do, how the hell do they expect a developer/programmer to develop/program and it gives a bad name to whatever hosting company it is. The history of the php file is I think it's been around since the first version, I know it has for quite some time. As far as the file itself it is very helpful here are the different parameters below, that have to do with sessions/cookies, what there for, what they are used for and how to change there parameters to do what you want to do. As far as finding these, all you have to do to find these files is open your php.ini file. CLick find and copy the title of whatever sections I am showing you and paste it in find, and it will find it in your ini file. I made it a point to set the headers below to match it exactly so you can just copy and paste it to find them quickly in the php.ini file. By the way, the . within the names of the configuration options are references. Like the one below it is telling you, it's a session config option, in reference to save_handler. It's the way they show how it's related. It's how the php processor knows what is what.

[b]session.save_handler[/b]

This one is to do with where the SESSIONS themselves are saved. It has nothing to do with anything but how they are saved, and this is very, very important. This is also something that is not recommended, unless you are more advanced with php, and that more advanced would be to the point where this tutorial won't be able to help you anymore. So for now, there are a few things you should know. Files is this default, and it goes the best with the original default settings. What it does is, it stores the sessions in a temporary file. Then by default cookies, identify those sessions. This is the recommended way, you can do it other way's but this is recommended by most programmers. It's easy, efficient, and it's obviously set to the php default options for a reason. As far what other options you can use here,. Actually I can't seem to find a list of them anywhere, even on php.net, unfortunately it's hard to find a list for them all. I got some something about, writeable, or putting in a database, and one called user. If anyone has any more information on this please inform me so I can update this section.

[b]session.save_path[/b]

This is simply where the session is saved. If it's set to files, then in this situation, it's default to a temp folder somewhere, it saves them in that folder. If you are getting really advanced with it, and want to start putting it in a seperate folder I guess it could be helpful, but I don't ever see a reason to ever need to change this one, atleast not yet.

[b]session.use_cookies[/b]

This is a simple on. This tells the sessions whether or not to use cookies. It either does or does not use cookies. If it does it simply uses cookies, if it does not, it uses url's to pass around the session id. There is a 0 or a 1, 1 means it uses cookies, 0 means it does not use cookies.

[b]session.name[/b]

This one tells the module what the name of the sessions are. It is by default called session id. There is never really a need to change this even if you are doing your own custom session handling unless you just have this uncanny urge to feel different for some reason, or special, I don't really ever see the need to change this one, if you decide to you can change it to whatever you choose.

[b]session.auto_start[/b]

This is by default no. It is best to not use this What auto start does, is it starts the sessions automatically, or prepares the way automatically. Meaning you never have to call session_start(). This sounds very inviting, and something that could really get used, something that would be very helpful. but in reality it can be very dumb to use this, but I could be wrong and would like to be corrected if I am. I have heard that this is severely less secure, as well as it takes up to many resources if you weren't using sessions at all. I also heard it was messy. Any advice or input on this would help. The values are 0 for no, 1 for yes, it defaults at 0.

[b]session.cookie_lifetime[/b]

By far one of the most important, and perhaps my favorite choices in the php.ini file period. This set's (in seconds) the amount of time until the cookie that holds the session id on the browser, stays on the browser before it expires. The thing is, I know I will get alot of heat from this, but I don't care, I know this for a fact. The bottom-line fact(it is stated in the manual a thousand times), yet I have had multiple arguments with multiple friends who refuse to believe sessions save the sessid by default in cookies ON THE BROWSER. They are called session cookies and it is NOT 100% set in stone that they die after the browser closes. You can set the parameter to as high as you want in seconds, and it stays active even after they close the browser for the specific amount of time. It is 100% fact, and far from subject to opinion, it does send a session cookie to the browser to be able to retrieve it later when they visit, this is using cookies, it can also do links, but that's not default, that's explained in another section. Now as far as this, it can be set using seconds. It doesn't matter how many seconds, so however many you want. If you want a quick way to calculate sections then go to good, and type in seconds in whatever. Like seconds in 5 hours, it calculates how many seconds are in 5 hours. Also seconds in 1 year, it gives you the number of seconds within a 1 year time period. This option kicks ass more than any other thing you can modify in the php.ini it's one of my favorites, and I modify it to whatever I want on every site I try and use sessions with.

[b]session.cookie_path[/b]

This section I am keeping simple. This is one of those parameters, that seem frighteningly similiar to the cookie parameter that you pass the function. This one and the one after it are the same. They set the session cookies, (basically the sessions), to be valid in only certain areas of the site if needed. Here is where the issue comes in, and it's best not to mess with these. If you are running 2 systems on the site, an admin section actual website, you are actualling running 2 different session systems if you really think about it. So setting this to something specific could restrict you later, if you want to add onto your site and realize you have sessions all used up and based on a specific area of the site.

[b]session.cookie_domain[/b]

Same as the thing for the cookie, it just set's the same thing that you would put for the setcookie function, what this is for is to make it to where you decide what domain the cookie is active for. If you leave this one and the on above alone, then by default the purpose of it is to allow it to run throughout the entire site, and that's it's default settings so you shouldn't have anything to worry about with it.

[b]session.serialize_handler[/b]

To tell you the truth I have no idea what this was any advice would be best, all I know is the default is set to php. It states in the manual this is the best and saffest choice, so I will recommend it remain on php, I am supposing, just a guess, that if you were using 2 programming languages close together, if you wanted the php programs you write to create teh sessions and everything, but you wanted another language like the module for asp, or jsp to actual handle the session serialization you could use that instead, or if you had a third party program maybe that had more features than php's or something, I have no idea. I know it can also be set to wddx, this is something that serializes them all in xml or something, you will have to check up somewhere to find more information about that.

[b]session.gc_probability[/b]

This one is pretty important. This one, I learnt awhile back what it was, and didn't until recently find out what it actually is used for. Setting this to the right setting can mean the difference between getting hacked or not getting hacked. It can also mean the difference in whether or server crashes or does not crash. Now this one is and can be a little tricky so let me explain how it works, what you can set it to, and what situations are best to set it to and when they are not. To make the explanation short, it's called garbage collection. Sessions stay inside the file until they are hit with a garbage collection routine. You can pass any number to this between 1-100%. To often can cause damage, not enough can be dangerous. The more people that visit the site, the higher the number needs to be set. If it's set to 50 then it's 50%, that means 50% of the time someone uses sessions, it will clear it, if there are very few people coming to the site this might be ok, but 50 is way to high. If you have a very high traffic site, 5 percent is normally pretty good, more information on this can be submitted to me if needed.

[b]session.cookie_secure[/b]

This is the same thing I explained earlier with cookies, if this is set to 1 it's true 0 it's false, on 0 it can be used anyway, if it's set to one however, then the session on sends the cookie, with the session id, or attempts to retrieve the cookie if it's over a secure ssl connect. "Secure Socket Layers" in case if you want to look up more information about this elsewhere.

[b]session.gc_maxlifetime[/b]

This is a counteractive up there for the one I told you I liked. There are 2 components to a session, the session and the cookie containing the session id(the default means in which php runs sessions. As far as the lifetime, each one has there own lifetime, the one I spoke about way up there, has to do with how long the cookie, stays before it expires, this one here decides how long the session itself expires. The thing is a session can expire before a cookie and vice-versa, so it's best to try and keep this at the same level as the one that controls when the cookie expires.

[b]session.referer_check[/b]

This set's it to the sessions can only be created when it's from an http request. Meaning get and posts aren't accepted. A good thing when sessions should activate based on coming frmo a specific link, like if you want to say hey google users to everyone coming from good, or similar or other programming things with it, this is one of the many methods you can use to achieve such things. The values are either 0 for false, which is default or 1 for true, meaning it has to be http only to create the session.

[b]session.entropy_file[/b]

This is something you can use to add more randomness to a session id, it helps keeping them from being guessed, I am unsure how to use it, check around for it some, I am not totally sure how to use this one.

[b]Other paremeters[/b]

There are probably tons of others, there are some related to every database platform to deal with how they handle various types of stuff, but these are all for heavily advanced programmers, who find it fun to do there own session handling, me personally I like sessions, there fun but I would never do custom handling until I am much more advanced, that's why they made the default setup very easy to use, and very easy to understand I will probably go total database, later and handle all my session id's using that, but it'll still need to send a session id in a cookie, so I don't really see the point.

[b]Cleanup[/b]

That is about it, everything you will hopefully ever need to know about sessions. You know what they are, what they do the parameters and configurations for each, how they related, security issues and risks, and countless other things. If someone can think of something I forgot, then I can add it, or if I think of anything later, I will update it as my experiences change, or as I think of new stuff I forgot to add, even smaller pieces of helpful information.

[b]Credit[/b]

*Some information used from wikipedia.com but modified into my own words, as well as various other online resources. But nothing that I took totally I took it and rewrote everything in my own words. If I recieve contributions from various readers, the contributions are listed within the original text with a annotation(submitted by (insertnamehere)).

[trq]

I really dont think this is the place for these (besides the fact there very hard on the eyes). Why not try and submit them as articles or something?

[Ninjakreborn]

I possibly will, I want to see if people complain about it much or like it, if they like it I will occasionally post them, I think they can be very helpful, the last time, I have about 4 people say it helped, I find it a good place for people to get all the answers in one place, then obviously if they ever have any cookie/session related issues, they can always post them in the post that has the tutorial, then me and other people who want to help can try address all the problems simultaniously.  It will remove hte need for everyone posting lots of posts about sessions and cookies, mostly for the fact, that I will try and make sure that everyone here has help whenever I have any spare time.

[jayR]

I agree with thorpe.  This isn't really a good place for this, and I about fell out of my chair having seizures when I tried to read through it.  :)  I'd submit it and see if they'd put it in their articles or tutorials section instead.

[bpops]

I understand these guys are just trying to keep phpfreaks organized, but I for one appreciate the work you put into this. I'm in the middle of really trying to understand cookies and php better and will be reading your post over the next few minutes. Thankyou :)

[Ninjakreborn]

Some people will agree, some will not.  I don't want to offend anyone.  What I will do is, I have this how to here, hopefully it can help someone, if someone needs help, as long as this post is here, then whenever I have a few minutes away from work, I am looking over anything here, if it's related to sessions/cookies in anyway I will try to get them help as fast as possible.  As far as people disliking this, some may like it some may not.  If they do not, and I found out at some point a moderator, moves it, atleast it's still posted somewhere, if they delete it, then I have no choice but to forget the idea, I might post other how-to's later, but I am only getting them posted here for major issues, I know enough about to help with, and that I think might help people understand specific issues more.

[hitman6003]

Holy crap, that's a lot to say about a not-too-complicated subject.

Anyway, I think it's great that you posted it, and I'm sure it will help some people.  However, I don't think that this particular forum is the place.  One, it's not a request for help, so a lot of people will get upset about that, and two, there is already two places for tutorials:  the main phpfreaks.com tutorial repository, and the tutorial/faq repository in the forums (http://www.phpfreaks.com/forums/index.php/board,41.0.html).  You can usually get your stuff posted there just by asking one of the mods about it.

Posting it here also means that it will fall down the pages quickly, and most people aren't going to do a search for a tutorial in a general help forum.

[Ninjakreborn]

I don't know, it's here for now, if a mod get's aggravated and moves it, I am definitely not brave enough to repost, I just hope people post for help here and get help.  That's all I can say about the issue of whether it should be here or not, I am sure that if it's in the way, or aggravating too many people a mod will come by and delete it.  If not then hopefully people will start asking questions and getting help.