| 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.
[eluser]WanWizard[/eluser]
[quote author="BrianL" date="1278528135"]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.[/quote] Where did you get this idea from? The CI session library can use cookies, or use a database for session data storage. The cookie way is handy for simple sites without databases, for all others use database storage. No need whatsoever to revert to PHP sessions.
[eluser]BrianL[/eluser]
[quote author="WanWizard" date="1278538145"]Where did you get this idea from? The CI session library can use cookies, or use a database for session data storage. The cookie way is handy for simple sites without databases, for all others use database storage. No need whatsoever to revert to PHP sessions.[/quote] Here. Quote:Note: The Session class does not utilize native PHP sessions. It generates its own session data, offering more flexibility for developers. By the way there are many reasons why you would want to use PHP sessions. It is not "reverting" but dependent on what you need (the flexibility part). If you aren't using shared webhosting, the primary concern of PHP default file sessions (the session file being shared and accessible to other clients) is gone. It is also wasting bandwidth at the least and insecure at the worst to store session data client side, encrypted or not (anything that can be encrypted can theoretically be decrypted), and whether or not you set CI sessions to database it still stores all session data in the cookie. The choice to use a database should not just be based on whether the server supports a database, but whether you need to validate the data (as stated in the CI manual). Finally there is nothing wrong with PHP file based sessions in certain conditions (example: you have root for the box and you do not care about file locking problems), or with using any type of session handler at all. It very much depends on what the requirements and the environment is like. "Because it is there" is not a good enough reason to use databases. Neither is perceived "complexity" of a site. It is a choice related to security, which is dependent on many factors.
[eluser]crikey[/eluser]
@BrianL - Thanks for your help and your comments (which have made me reconsider using the library). For anyone else, the code is actually available if you click the 'Edit This Page' button on the Wiki page (assuming you're logged in). Not sure why it doesn't display otherwise. Cheers, Grant
[eluser]GPSTrackit[/eluser]
I just got the code and placed it where instructed. How, it's throwing an error that the database table doesn't exist! Correct me if I'm wrong but isn't the ENTIRE POINT of this library to remove the reliance upon cookies and databases??? I really would like to use the standard PHP sessions. Our database is taxed enough and I don't trust cookies. Please advise. |
| Welcome Guest, Not a member yet? Register Sign In |
