Welcome Guest, Not a member yet? Register   Sign In
CI native PHP sessions, why not?!?
#1

[eluser]MVUG[/eluser]
Hi everybody,

first I have to say, CI is the best...

The only thing I find very weird is that the session library doesn't support native PHP sessions... Why is this? I think a lot of people (including myself) use these PHP sessions... I think it is a must have for CI 2.0!

What do you guys think?
#2

[eluser]WanWizard[/eluser]
Sessions should become driver based, so you can have multiple backends, and even make your own if you want.
#3

[eluser]pbreit[/eluser]
CI sessions are fine. No need to use PHP Sessions.
#4

[eluser]MVUG[/eluser]
[quote author="pbreit" date="1289989698"]CI sessions are fine. No need to use PHP Sessions.[/quote]

why? I think cookies are fine for storing flashdata etc., but what about when you want to store more data? And are cookies secure enough?
#5

[eluser]Dennis Rasmussen[/eluser]
[quote author="tuurtnt" date="1290001691"][quote author="pbreit" date="1289989698"]CI sessions are fine. No need to use PHP Sessions.[/quote]

why? I think cookies are fine for storing flashdata etc., but what about when you want to store more data? And are cookies secure enough?[/quote]

Save your session in the database if you need more than 4KB.
http://ellislab.com/codeigniter/user-gui...sions.html
#6

[eluser]DChill[/eluser]
[quote author="WanWizard" date="1289968354"]Sessions should become driver based, so you can have multiple backends, and even make your own if you want.[/quote]

I must concur. Having a unified session API with interchangeable storage mechanisms makes the most sense. This is effectively how CI_Session works now, except that it only supports cookie and database session storage.

The primary reason for using the native PHP session mechanism, in my view, is efficiency. This method should consistently have less overhead than either serialized (and possibly encrypted) cookie storage or database storage. For higher-volume sites, this can add up to a significant performance savings, especially when you consider the increased network traffic involved with particularly large cookies or database transactions.

I think native PHP sessions offer a significant enough advantage that I will be building a native option into a CI_Session-based library for my projects. I really hope to see such a mechanism included in 2.0. Maybe I will work up a driver interface for CI_Session and submit it for consideration...
#7

[eluser]MVUG[/eluser]
[quote author="DChill" date="1290024992"][quote author="WanWizard" date="1289968354"]Sessions should become driver based, so you can have multiple backends, and even make your own if you want.[/quote]

I must concur. Having a unified session API with interchangeable storage mechanisms makes the most sense. This is effectively how CI_Session works now, except that it only supports cookie and database session storage.

The primary reason for using the native PHP session mechanism, in my view, is efficiency. This method should consistently have less overhead than either serialized (and possibly encrypted) cookie storage or database storage. For higher-volume sites, this can add up to a significant performance savings, especially when you consider the increased network traffic involved with particularly large cookies or database transactions.

I think native PHP sessions offer a significant enough advantage that I will be building a native option into a CI_Session-based library for my projects. I really hope to see such a mechanism included in 2.0. Maybe I will work up a driver interface for CI_Session and submit it for consideration...[/quote]

Yeah let's hope so... I think CI must offer native PHP sessions support... Until then I will use a DB backend...
#8

[eluser]Dennis Rasmussen[/eluser]
[quote author="DChill" date="1290024992"][quote author="WanWizard" date="1289968354"]Sessions should become driver based, so you can have multiple backends, and even make your own if you want.[/quote]

I think native PHP sessions offer a significant enough advantage that I will be building a native option into a CI_Session-based library for my projects. I really hope to see such a mechanism included in 2.0. Maybe I will work up a driver interface for CI_Session and submit it for consideration...[/quote]

Already done a couple of times.
I believe there's a library in the wiki aswell.
#9

[eluser]DChill[/eluser]
[quote author="Dennis Rasmussen" date="1290027325"][quote author="DChill" date="1290024992"]I think native PHP sessions offer a significant enough advantage that I will be building a native option into a CI_Session-based library for my projects. I really hope to see such a mechanism included in 2.0. Maybe I will work up a driver interface for CI_Session and submit it for consideration...[/quote]

Already done a couple of times.
I believe there's a library in the wiki aswell.[/quote]

I saw Session objects in the wiki which mimicked the CI_Session interface, and ones that use native sessions, but didn't notice a setup with interchangeable drivers. Did I miss something? I'm not interested in reinventing the wheel, but I'm happy to write some code that fills a gap for myself and others.
#10

[eluser]WanWizard[/eluser]
No, but CI 2.0 supports drivers, so I siggest that sessions are rewritten for 2.0 using the driver library, which allows you to easily slot in other session backends.
Driver support must be improved to make this work properly, currently it's still missing functionality (for example available drivers are hardcoded).




Theme © iAndrew 2016 - Forum software by © MyBB