CI 1.6 sessions

[eluser]coolfactor[/eluser]
[quote author="EugeneS" date="1202838506"]
native sessions was so expected in this release
why not to include native sessions support as option ?
[/quote]

Eugene, nothing is stopping you from using native PHP sessions within your CodeIgniter applications. Are you hoping for a session API that uses native sessions internally?

You can always just work with $_SESSION directly as you would with raw PHP. That still works. Can you clarify your concerns?

Example:

Code:

session_start();
$_SESSION['name'] = "Eugene";

There, I just stored your name into the native session, with 2 lines of code. CodeIgniter doesn't stop you from doing this.

[eluser]systemsos[/eluser]
And there is many Native PHP custom libraries out there *cough*RA_Session*cough*.

^_^

[eluser]FlashUK[/eluser]
Is there really any benefit to using native sessions other than performance?

Personally I would prefer to use db sessions for security reasons because you can never trust the information that a browser sends back (hijacking sessions)

AFAIK many large scale apps will run both sessions with db sessions.

[eluser]systemsos[/eluser]
Glad you asked FlashUK.

CI session (the normal session library from the core) is driven by cookies. Meaning a bit of the important data sits on your viewers. If you want to remember your viewers username, it's stored on their computer. Which means they can open up their cookie (in _any_ text browser) and edit the contents. Login = FALSE, change that to TRUE. etc.

Using CI's session library, and enabling the use of a database doesn't do exactly what you'd think. It still stores the user's data you declare on their own computer. Again, they can modify it. All CI's database checks is the IP, and that their browser is the same.

Of course you can use encryption but they still have that info on their computer.

Native session use one cookie, store just one item on the viewers computer. Session-ID 34SDF2134123SDF123123SADF - or something similar.

EVERYTHING else is stored on the server itself, and relates back to what the session ID is that is stored on the session ID on their personal computer.

If a viewer were to try and change their session ID - well the server just generates a new session for them (unless that session already exists, in which case yes - you could browser hijack).

For the completely security conscious - you can check that the IP is the same (which is again stored on the server), and browser agent. Because the IP and Browser is stored on the server, they'd have to hack into the server itself to change it. There are other ways of course to do this but we're missing the point.

A database session application - has no ability what so to determine who's visit is who - without some sort of ID for this person. It would be stored in a cookie or passed through the URL.

Passing SID's through the URL however again, isn't secure as anyone can copy/paste - and get access to your site.



Large scale applications don't run sessions with a database "normally". What I think gets everyone confused when dealing with "sessions" and "logins" is the two are very different.

For example, I want to check for my viewers session (stored on their computer). I then want to check that their IP and Browser match what I have a record of with my website (through sessions). Awesome, this session is correct.

I would personally NEVER STORE a login state - INSIDE a session. I would then take that session ID after it passes IP and Browser matching, and run it through my database to check to see if this user is logged in.

Having said that - I wouldn't really use the session to store information - unless it wasn't "mission critical". For example, a shopping cart - I would store all the information in a session while they make their purchases. If the session is hijacked - the best a person could get is what the person had in their shopping cart before the hack.

After of course, when they go to checkout - then I would force them to login - or register to store their details in a database that I could continue to cross check for the remainder of their shopping with me.

I've lost my train of thought.... How'd I go?

[eluser]FlashUK[/eluser]
I understand... I kinda knew thats what a session did but I was denying my own knowledge. The data is stored on the server and the users is related to it via an ID. Simple right

I will need to use sessions to track users before they eventually login, so I definitely need to consider using native rather than linking it via a database and cookie (not all browsers enable cookies anyway).

The link I posted about the sessions lists some interesting ways to secure a session (using user-agent not ip since ip can change). It would be interesting to see this implemented in your library (if you haven't done so already!)

I shall check out your script and see what I think of it

[eluser]systemsos[/eluser]
FYI - A session still uses a cookie (just a single one) to store the ID in.

If a user's browser doesn't allow cookies, it won't allow sessions.

One particular exception to this rule is PHP's automated Session ID translation - which will automatically pass the Session ID in the URL if cookies are not enabled. However, this being less than a secure solution - many (and most from my last check) PHP setups won't allow it. You could however implement this solution in your own applications.

With RA_Session you may enable IP checking and/or UserBrowser checking.

Depending on what it is you are using sessions for would best determine how you should tackle that approach however, a public forum for example would be an "okay" to have a different IP each time.

An accounts program (where it lists my credit card (or the last 4 digits at that)) I would hope checks my IP.

I would much rather be forced to relog than to have someone with the same browser as me nab my session.

[eluser]EugeneS[/eluser]
[quote author="coolfactor" date="1203867841"][quote author="EugeneS" date="1202838506"]
native sessions was so expected in this release
why not to include native sessions support as option ?
[/quote]

Eugene, nothing is stopping you from using native PHP sessions within your CodeIgniter applications. Are you hoping for a session API that uses native sessions internally?

You can always just work with $_SESSION directly as you would with raw PHP. That still works. Can you clarify your concerns?

Example:

Code:

session_start();
$_SESSION['name'] = "Eugene";

There, I just stored your name into the native session, with 2 lines of code. CodeIgniter doesn't stop you from doing this.[/quote]
))

if i'd like to use

session_start();
$_SESSION['name'] = "Eugene";

i wouldnt use CI or other frameworks ... just pure php

about 3d party libraries:

guys if i like to use different addons as many as i DONT need i'd use PEAR+smarty instead of CI,
what the sense to load extra library when already exists native library already optimized for CI ?

the main goal of framework is to keep one style + kind of code optimization for one engine + speed up of work flow ... nothing more...

i'm not microsoft new age programmer who likes to drag and drop components on the form (and their applications finally require latest 3d card to show directory listing) just to get it working without any idea of speed and server load and server resources ...

just do not understand CI developers' position to not include support of native sessions ... just 5-10 rows of code into existing library ... tired to do it manually from version to version ... native php sessions so common thing every where ...

[eluser]systemsos[/eluser]
But if you used a 3rd party library (or used your own library) you could negate the need to add those 5-10 rows of code each version update. Just copy (or keep) your library right?

I do agree though, it is kind of weird that it's not native. That's another ball game though (I believe there was a big discussion on another thread about it).

[eluser]FlashUK[/eluser]
I was looking at your code and saw this, is this bit of code correct?

Code:

function _ra_decode ($value)
    {
        //_ra_decode first checks if encryption is enabled, and then decodes as required
        //_ra_decode supports decoding entire Arrays
        
        if (is_array($value)) {
            $temp_array = array();
            foreach ($value as $key => $val) {
                if ($this->sess_encryption) {
                    $temp_array[$key] = $this->_ra_decode($val);
                } else {
                    $temp_array[$key] = $val;
                }
            }
            return $temp_array;
        }
        if ($this->sess_encryption) {
            $value = $this->CI->encrypt->decode($value);
            return $value;
        }
        return $value;
    }

Shouldn't it read (you forgot the else tag)

Code:

function _ra_decode ($value)
    {
        //_ra_decode first checks if encryption is enabled, and then decodes as required
        //_ra_decode supports decoding entire Arrays
        
        if (is_array($value)) {
            $temp_array = array();
            foreach ($value as $key => $val) {
                if ($this->sess_encryption) {
                    $temp_array[$key] = $this->_ra_decode($val);
                } else {
                    $temp_array[$key] = $val;
                }
            }
            return $temp_array;
        } else {
            if ($this->sess_encryption) {
                $value = $this->CI->encrypt->decode($value);
                return $value;
            }
            return $value;
        }
    }

I corrected a spelling mistake (legnth) and added the ?> close tag on the wiki page.

P.S: I have only been looking over it for the past 15 mins. It looks well written. I especially like how you've used the _ra_encode and _ra_decode functions.

[eluser]systemsos[/eluser]
It used to be } else { before I reread the code...

When you read it - the else function isn't actually needed. As the line above terminates the function when you use "return $something".

So really, it is still an else statement - just without the else. Technically you could also put an else statement on the last return $value - might make it easier to read but I'm so so about it.

When I copy/paste the latest code to the wiki page I may have missed the ?> bracket. Thanks for that.

Where was the length typo?

Thanks again =D