Creating custom PHP Session handler?

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.

1. Other than session fixation and session hijacking, what开发者_Go百科 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.

2. Would a MySQL-based session handler be faster than PHP's native sessions? Assuming a standard (Not 'memory') table.

3. 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.

4. 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.

5. 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.

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

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.

Most session implementations of languages’ standard libraries do only support the basic key-value association where the key is provided by the client (i.e. session ID) and the value is stored on the server side (i.e. session storage) and then associated to the client’s request.

Anything beyond that (especially security measures) are also beyond that essential session mechanism of a key-value association and needs be added. Especially because these security measures mostly come along with faults: How to determine the authenticity of a request of a certain session? By IP address? By user agent identification? Or both? Or no session authentication at all? This is always a trade-off between security and usability that the developer needs to deal with.

But if I would need to implement a session handler, I would not just look for pure speed but – depending on the requirements – also for reliability. Memcache might be fast but if the server crashed all session data is lost. In opposite to that, a database is more reliable but might have speed downsides opposed to memcache. But you won’t know until you test and benchmark it on your own. You could even use two different session handlers that handle different session reliability levels (unreliable in memcache and reliable in MySQL/files).

But it all depends on your requirements.

They are both great methods, there are some downsides to using MySQL which would be traffic levels in some cases could actually crash a server if done incorrectly or the load is just too high!

I recommend personally given that standard sessions are already handled properly to just use them and encrypted the data you do not want the hackers to see.

cookies are not safe to use without proper precaution. Unless you need "Remember me" then stick with sessions! :)

EDIT

Do not use MD5, it's poor encryption and decryptable... I recommend salting the data and encrypting it all together.

$salt = 'dsasda90742308408324708324832';
$password = sha1(sha1(md5('username').md5($salt));

This encryption will not be decrypted anytime soon, I would considered it impossible as of now.