• 1 Vote(s) - 1 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Native Sessions

#1
I have just downloaded the CI 3 release candidate 2 copy and I have noticed that application/config.php > session settings hasn't got "native" option. I am using another CI dev copy where I am able to use php's native session using "native". Can you please tell me if it is possible to use php's native? if yes, how?
Reply

#2
Hi,
change from native to 'files'

--
janusz
Reply

#3
The 'files' session handler is not a compatible replacement for the 'native' session handler. There are libraries and middleware that may interact with the PHP native session functions and global $_SESSION directly. The AWS DynamoDB session handler, for example, worked by injecting itself into native handler without having to write a driver class.

Additionally, the removal of the "sess_expire_on_close" config setting prevents us from controlling the native session configuration of the cookie. There are many use cases where an application might need the session to survive a browser restart, etc.

I feel like we should support the old 'native' session handler with the new SessionHandlerInterface.
Reply

#4
(02-13-2015, 10:41 AM)lvrkln Wrote: The 'files' session handler is not a compatible replacement for the 'native' session handler. There are libraries and middleware that may interact with the PHP native session functions and global $_SESSION directly. The AWS DynamoDB session handler, for example, worked by injecting itself into native handler without having to write a driver class.

Additionally, the removal of the "sess_expire_on_close" config setting prevents us from controlling the native session configuration of the cookie. There are many use cases where an application might need the session to survive a browser restart, etc.

I feel like we should support the old 'native' session handler with the new SessionHandlerInterface.

Well, you have to have in mind that the "old" 'native' session handler was never a released feature. It was merged as an alternative to the old cookie-based implementation, which had countless flaws.

However, an alternative is not a real solution, hence why the whole thing was rewritten from scratch and each of the available drivers registers itself as a real, PHP-level session handler (interacting with PHP native functions, $_SESSION and such). The four drivers that are available by default cover the needs of no less than 95% of our users (that's an educated guess), and for the rest of you - you can still write your own handler.

That being said, I've thought ot adding a 'native' driver to the current implementation, for the sole purpose of allowing the users to pick one of the handlers that are available in PHP as extensions. There's a slight problem with that however ... in order to provide the 'sess_match_ip' functionality for real (at the storage level, not by setting it as a session variable), we'll have to rely on extending the SessionHandler (that's a PHP class exposing its underlying implementation to userspace) class, which in turn has its quirks. SessionHandlerInterface has nothing to do with that ... that's an also an interface provided by PHP itself (that is implemented by the SessionHandler class), so it would be irrelevant to a possible 'native' driver.

In general, I'm not opposed to the idea, but so far nothing has justified the effort. In any case, it won't happen in time for the 3.0 release.

And a note about 'sess_expire_on_close' ... the setting's removal prevents you from nothing. Smile
Judging by what you wrote, you don't really understand what it does either ... It's not for allowing a session to survive a browser restart (that's how sessions work by default), but to force a session's expiration once the browser is closed.
It is a very simple concept - don't give the cookie an expiry time value, so the browser will keep the cookie until you close it, after which the garbage collector will take care of deleting it. Only ... the GC doesn't know anything about cookies, so you may have your browser open for days and still have the session cookie, but the garbage collector doesn't keep stuff in storage for that long and will invalidate it.

TL;DR: 'sess_expire_on_close' is the equivalent of 'sess_expiration' = 0. It's the exact same thing and having two settings for it is just pointless.
Reply

#5
Narf: First. Thank you for your thoughtful response, and continuing contributions to the community.

And, thank you for the clarification on the 'sess_expire_on_close' configuration. It was not immediately clear how this change impacted handling the cookie_lifetime (in reference to the native PHP documentation). Setting a distant future expiration will accommodate.

I can appreciate that core set of drivers covers the vast majority of use cases, and matching the user IP address presents some challenges.

Would a 'native' driver be something you would entertain a pull request for in the future? Leveraging the session to store the IP address, like: http://goo.gl/p8tjyh
Reply

#6
I'd write it myself, given that there's enough demand for it ...

But the technique that you've linked is exactly what I want to avoid. I've went great lengths in the other drivers trying not to do that (otherwise the 'files' driver would only be an ini_set('session.save_handler', 'files') call), because unless the check is at the storage level, it doesn't prevent an attacker from messing with your session - it prevents fixation, but still allows either destruction or extending its lifetime artificially.
Reply

#7
While we're on the subject I need to upgrade my app to the latest version of CI3 and one of the latest changes is the new session drivers. Originally I started using the dev branch to fix an issue in 2.x with AJAX calls not updating the session. The main section of our app is a single page that's all AJAX and after 2 hours (or whatever your session expire is set to) calls would start failing.

Now that native is gone, does files have this limitation? If yes, what is the suggested driver for single page apps?
Reply

#8
Now that CI 3.0 is stable, I'd like to bump this topic back into the discussion. Since this has been posted, more people have been exposed to the upgrade process, and maybe we can generate some support for a native session driver.
Reply

#9
(04-14-2015, 11:12 AM)lvrkln Wrote: Now that CI 3.0 is stable, I'd like to bump this topic back into the discussion. Since this has been posted, more people have been exposed to the upgrade process, and maybe we can generate some support for a native session driver.

I would like to see this as well.

We have an application that we're porting to CI, and we make heavy use of sessions.

We have installed Cassandra (NOSQL) as the PHP Native session handler, as the application is actually deployed across 4 different servers behind a load balancer. This allows all of the servers to have access to same session data, without having to do any special magic.

Since there are many DB systems that have already been adapted to work with Apache/PHP, access them from CI using a 'native' option seems like a very positive idea, compared having to create yet another driver port. There are far more people using PHP+Cassandra, than are using CodeIgniter+Cassandra, so there is a larger community able to maintain the driver.
Reply

#10
(04-30-2015, 08:18 AM)I would vote for this as well. This allows us to use php extension such as memcached that relies on php native functions. coredumpster Wrote:
(04-14-2015, 11:12 AM)lvrkln Wrote: Now that CI 3.0 is stable, I'd like to bump this topic back into the discussion. Since this has been posted, more people have been exposed to the upgrade process, and maybe we can generate some support for a native session driver.

I would like to see this as well.

We have an application that we're porting to CI, and we make heavy use of sessions.

We have installed Cassandra (NOSQL) as the PHP Native session handler, as the application is actually deployed across 4 different servers behind a load balancer.  This allows all of the servers to have access to same session data, without having to do any special magic.

Since there are many DB systems that have already been adapted to work with Apache/PHP, access them from CI using a 'native' option seems like a very positive idea, compared having to create yet another driver port.  There are far more people using PHP+Cassandra, than are using CodeIgniter+Cassandra, so there is a larger community able to maintain the driver.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.