Hybrid Session - where is it?

[eluser]BrianL[/eluser]
I was taking a look at this before. I didn't like it too much.

1. It seems to call session_start() *before* connecting to a database or setting a session save handler. IMO any session library that does not set a session save handler should *not* call session_start(), or else it will have unpredictable results on different PHP configurations (database? files?)

2. Session identifier is a well known md5 uniqid ip address combination found in many tutorials. As far as I'm concerned anything that doesn't use /dev/urandom or /dev/random should simply rely on PHP configuration, as PHP configuration is often set to read from these truly random devices. And if it's not, better to use a hard coded seed along with a little entropy than data supplied by the user which could be predicted by an attacker with enough knowledge of the user.

3. The wiki says it started as a way to fix the "problem" with IE. Well, if the dev team had hunted a little more they would have found the "problem" with IE is just using underscores in session names. Just setting $config['sess_table_name'] to some different value without an underscore would have saved them writing all that code. It also doesn't look too good for the authors if they missed something so obvious and I would read all the code line by line (if they missed that who knows what else they missed, maybe there's unsafe database queries who knows).

So I would simply write a custom session handler, using the excellent code from the PHP Manual Comments (particularly the "Maria" contributor has a nice solution). Then, if I really needed it I would use that along with the native CI session (in fact CI session is meant to be used in tandem with PHP native sessions according to the manual not replaced).

As far as I'm concerned writing a custom session handler is basic PHP skill that every PHP developer should know.

Anyway if you still want it I found it:
http://www.matthewfedak.co.uk/session_hy...niter.html
___

Finally I would like to add that I see nothing wrong with CI native sessions since CI sessions are not meant to replace PHP sessions. Some people hate the CI session because it stores data in the cookie, which they perceive as insecure. Whether it is or not is besides the point, as the CI session offers cookie based sessions which add flexibility to PHP file or database sessions (PHP storing the sessid in a cookie does not a cookie based session make). Anyone who is truly concerned about security should write their own custom session handler, and for everyone else there's nothing wrong with storing non-sensitive data in encrypted cookies. Hatred of cookies is nothing new, and the fact is the session identifier itself is stored in a cookie and can be used by itself to hijack a session so worrying about cookies in most cases is superfluous.