Web applications in today’s volatile Internet environment need to be able to have tight control over their scripts.
Scripts form the backbone of the functionality behind such programmed interfaces, and without them, an application would be little more than a static Web page. User authentication is one of the hallmarks of Web development, and is natively the prime candidate for such strict script control. When developing with PHP, developers have the choice to refine their scripts to maximize workability and efficiency by employing the use of either sessions or cookies.*
* – There various other methods for user authentication such as HTTP authentication and querystrings, however these are largely tools of the past and/or no longer scalable to the functional level of today’s demanding Web applications.
Each method of script control that we described has its pros and cons:
With the advent of PHP 5, it seems that more developers are turning toward session usage in order to authenticate users and to provide for richer Web application experiences. Let’s take a look at why this is so.
Sessions:
- Do not store physical files on the client’s computer
- Files are instead stored on the actual server
- Sessions must be enabled in order to use them effectively
- Can be accessed in the global sense (by using the $_SESSION superglobal)
- Easy to manipulate, update, create or destroy
- Less overhead as session implementation is largely controlled through the initial PHP configuration file
- Can store both simple (string, floats, etc.) and complex data types (entire instantiations of objects)
After viewing this list, cookies seem near archaic.
Cookies:
- Written to a temporary file on the user’s computer
- This file lets applications know if a user is unique
- Potential for various security issues
- Because of these issues, there is a trend for users to not browse with cookies enabled
- If a user happens across a Web application that uses cookies and their browse is set to reject them, the application will not work properly
- Cookies are highly customizable, offering much OOP functionality (ex. you can create your own classes for dealing with cookies)
- Access via $_COOKIE superglobal
I personally recommended that developers use sessions when programming their applications if and only if for the accessibility and usability issues. A Web application need be accessed by the greatest number of users as possible (security matters aside). However, both cookies and sessions are effective ways to tighten the controls of your scripts and each should be in the toolkit of any PHP developer.
Source: http://itknowledgeexchange.techtarget.com/web-standards/user-authentication-in-php-5-sessions-vs-cookies/
There are various work-arounds and settings ofcourse, but by default sessions aren’t that great either:
- The session data is stored in a directory which is accessible by all php scripts on the same server, not very secure.
- You can use url propagation or cookies for sessions to work: cookies are the safer way, since they are temporary (for sessions anyway, usually), don’t show up in your browsing history, and can’t accidently be mailed to someone with the url etc. But then the session does need a cookie.
I’m not sure how cookies are more customizable than sessions, either..
Just use one cookie to store the session id, and then store all the data in a table, with the id as identifier. Much safer, you can store as much data as you like, etc. And if you don’t like the cookie, use PHP’s sessions’ url id propagation for that part.
> Written by hmvrulz
You mean “Jeffrey Olchovy”, right
Comment by MSpreij — October 13, 2008 @ 4:36 am
Sessions generally DO use cookies. The session id is written to a cookie to connect the user to the session on the server. You can also do sessions without cookies, but will need to append the session id to every link and form submission.
The only difference with using the default session method and cookies is where you’re storing the information.
Comment by Lance — October 13, 2008 @ 11:02 am