Menu
Right now I'm stuck between using PHP's native session management, or creating my own (MySQL-based) session system, and I have a few questions regarding both.
Other than session fixation and session hijacking, what other concerns are there with using PHP's native session handling code? Both of these have easy fixes, but yet I keep seeing people writing their own systems to handle sessions so I'm wondering why.
Would a MySQL-based session handler be faster than PHP's native sessions? Assuming a standard (Not 'memory') table.
Are there any major downsides to using session_set_save_handler? I can make it fit my standards for the most part (Other than naming). Plus I personally like the idea of using $_SESSION['blah'] = 'blah' vs $session->assign('blah', 'blah'), or something to that extent.
Are there any good php session resources out there that I should take a look at? The last time I worked with sessions was 10 years ago, so my knowledge is a little stagnant. Google and Stackoverflow searches yield a lot of basic, obviously poorly written tutorials and examples (Store username + md5(password) in a cookie then create a session!), so I'm hoping someone here has some legitimate, higher-brow resources.
Regardless of my choice, I will be forcing a cookie-only approach. Is this wrong in any way? The sites that this code will power have average users, in an average security environment. I remember this being a huge problem the last time I used sessions, but the idea of using in-url sessions makes me extremely nervous.
269
session_start() creates a session or resumes the current one based on a session identifier passed via a GET or POST request, or passed via a cookie. When session_start() is called or when a session auto starts, PHP will call the open and read session save handlers.
SessionHandler is a special class that can be used to expose the current internal PHP session save handler by inheritance. There are seven methods which wrap the seven internal session save handler callbacks ( open , close , read , write , destroy , gc and create_sid ).
session_set_save_handler() sets the user-level session storage functions which are used for storing and retrieving data associated with a session. This is most useful when a storage method other than those supplied by PHP sessions is preferred, e.g. storing the session data in a local database.
PHP session is used to store and pass information from one page to another temporarily (until user close the website). PHP session technique is widely used in shopping websites where we need to store and pass cart information e.g. username, product code, product name, product price etc from one page to another.
The answer to 2) is - id depends. Let me explain: in order for the session handler to function properly you really should implement some type of lock and unlock mechanism. MySQL conveniently have the functions to lock table and unclock table. If you don't implement table locking in session handler then you risk having race conditions in ajax-based requests. Believe me, you don't want those.
Read this detailed article that explains race condition in custom session handler :
Ok then, if you add LOCK TABLE and UNLOCK TABLE to every session call like you should, then the your custom session handler will become a bit slower.
One thing you can do to make it much faster is to use HEAP table to store session. That means data will be stored in RAM only and never written to disk. This will work blindingly fast but if server goes down, all session data is lost.
If you OK with that possibility of session being lost when server goes down, then you should instead use memcache as session handler. Memcache already has all necessary functions to be used a php session handler, all you need to do it install memcache server, install php's memcache extension and then add something like this to you php.ini
[Session] ; Handler used to store/retrieve data. ; http://php.net/session.save-handler ;session.save_handler = files session.save_handler = memcache session.save_path="tcp://127.0.0.1:11215?persistent=1" This will definetely be much faster than default file based session handler
The advantages of using MySQL as session handler is that you can write custom class that does other things, extra things when data is saved to session. For example, let's say you save an object the represents the USER into session. You can have a custom session handler to extract username, userid, avatar from that OBJECT and write them to MySQL SESSION table into their own dedicated columns, making it possible to easily show Who's online
If you don't need extra methods in your session handler then there is no reason to use MySQL to store session data
78
PHP application loses session information between requests. Since Stanford has multiple web servers, different requests may be directed to different servers, and session information is often lost as a result.
The web infrastructure at Stanford consists of multiple web servers which do not share session data with each other. For this reason, sessions may be lost between requests. Using MySQL effectively counteracts this problem, as all session data is directed to and from the database server rather than the web cluster. Storing sessions in a database also has the effect of added privacy and security, as accessing the database requires authentication. We suggest that all web developers at Stanford with access to MySQL use this method for session handling.
Referred from http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions
This may help you.
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
