Welcome Guest, Not a member yet? Register   Sign In
Just a minute, native session library for CI2 ?
#1

[eluser]Arun Joshi[/eluser]
Just a minute,

Everyone is asking for a native session library. But CI core team addicted on cookie based stuff. Some one created a native session library for ci lovers one year ago (for version 1.5+). But I think that is now outdated. Is there any native session library created for codeigniter 2? If so please provide the link to that.

OK. Now you can start debate on native session library and cookie based as happening in uservoice for six months. Smile Smile Smile

-ARun
#2

[eluser]WanWizard[/eluser]
Sigh.

I'll repeat this one more time then. EVERY session solution uses cookies! It is how you maintain state in a stateless environment.
CI's Native Session library even uses the same cookie as the standard session library. and PHP's own session management also uses a cookie.

In case of PHP's session management, it is insecure, and should not be used without additional security measures, and not in a hosted environment. For CI's native session library, the cookie side is more secure, the security issues in hosted or shared environments still stand.

Recommendation: do not use it unless you're not concerned about security, or you know exactly what you do and have taken extra precautions! Use CI's session library with the database backend, not cookie-only. Do not ever store user data client-side.
#3

[eluser]Arun Joshi[/eluser]
@WanWizard,

Does all the mobile phone browsers support cookies? and can you explain your last sentence in more detail? I mean 'Do not ever store user data client-side'?
#4

[eluser]WanWizard[/eluser]
To maintain session state, there are a few things that need to happen.

You need server side storage, that should be secure, only accessable by your application, and accessed via a random session id. Managing all this is the task of the session library.

And you need a link between the user('s http client) and the session storage of that users client. To do that, the random session id needs to be send to the client, so the client can send it back with the next request to identify itself.

There are several options to send this session id back:
* via a cookie mechanism. This is the most secure, since it allows you to add additional security mechanisms that you can validate before using the session id stored in the cookie.
- - obviously this requires a cookie-enabled client
* via a URL GET parameter.
- - If you only pass the session_id (like PHP does with its PHP_SESSID), it is very insecure. Anyone getting hold of that value can hijack your session
- - you could create an array, add extra fields to it, serialize it, encrypt it, and use that as identifier. Chances are it's going to be to big for the URL
* via a POST variable
- - same mechanism as via GET, but not visible to the user. Requires every request to the server to be an HTTP POST though, which is inpractical.

Now storing any data client side is a security best practice. Anything that leaves the server can be captured, analyzed, broken and used. If it not leaves the server, that hacking route is out the window.
There are (in the case of cookies) also pratical issues: a cookie can have a maximum of 4Kb of payload, and you can only have 20 cookies per domain (a few more with recent browsers).

The issue with PHP session storage is that by default they are stored in a central location on the server, and the webserver needs r/w access to them. Which means any script that runs with that webserver's credentials can access the session files, even if they are from other applicatios running on that same host. Now there are ways to make this more secure, but in my experience there are not a lot of hosting companies, and virtually no dedicated server owners, that deploy these measures.

If you also use PHP's session mechanism for the state (so real PHP native sessions), a cookie or GET variable called PHP_SESSID is used (by default), which contains the full unencrypted and unsecured session id. Getting this cookie or appending it to a URL is enough to hijack someone else's session. And trust me, stealing a cookie is quite a simple task.

Hence my statement that using PHP's sessions is not a good idea.

If you don't like storing session data in the database (there are valid reasons not to want that), use a file-based (or mongodb, memcached, redis, ...) driver instead and deploy the same security measures for the session cookie as used in the session library.
#5

[eluser]Arun Joshi[/eluser]
Thanks for the long answer.
#6

[eluser]Arun Joshi[/eluser]
What about cookie disabled clients? I mean possible a mobile browser???
#7

[eluser]WanWizard[/eluser]
As said, if you don't have cookies available, you're left with the other two options.




Theme © iAndrew 2016 - Forum software by © MyBB