I’m using CI session, I’ve modded the setcookie to set expiration time to 0 to create(expire upon closing of browser) session cookie.
Somehow the session cookie is very flaky. I’ve tested on my computer with IE6/7 Firefox 1.5/2.0 and the latest Opera. And the session works.
But I have several other users reported being redirected to login page after signing into the system.

User login -> check auth, set cookie, and display secured home page -> user request another secured page—> user fowarded to login page as if the cookie was not set.

My config.php

/*
|—————————————————————————————————————
| Session Variables
|—————————————————————————————————————
| | ‘session_cookie_name’ = the name you want for the cookie
| ‘encrypt_sess_cookie’ = TRUE/FALSE (boolean).  Whether to encrypt the cookie
| ‘session_expiration’  = the number of SECONDS you want the session to last.
|  by default sessions last 7200 seconds (two hours).  Set to zero for no expiration.
| */
$config[‘sess_cookie_name’]      = ‘ci_session’;
$config[‘sess_expiration’]      = 7200;
$config[‘sess_encrypt_cookie’]  = TRUE;
$config[‘sess_use_database’]  = FALSE;
$config[‘sess_table_name’]      = ‘’;
$config[‘sess_match_ip’]      = TRUE;
$config[‘sess_match_useragent’]  = FALSE;

/*
|—————————————————————————————————————
| Cookie Related Variables
|—————————————————————————————————————
| | ‘cookie_prefix’ = Set a prefix if you need to avoid collisions
| ‘cookie_domain’ = Set to .your-domain.com for site-wide cookies
| ‘cookie_path’  =  Typically will be a forward slash
| */
$config[‘cookie_prefix’]  = “”;
$config[‘cookie_domain’]  = “.mydomain.com”;
$config[‘cookie_path’]      = “/”;

/*
|—————————————————————————————————————
| Global XSS Filtering
|—————————————————————————————————————
| | Determines whether the XSS filter is always active when GET, POST or
| COOKIE data is encountered
| */
$config[‘global_xss_filtering’] = TRUE;

Can anyone help?

Can you clarify a couple of things first, so we don’t go off at a tangent?

I’ve modded the setcookie to set expiration time to 0 to create(expire upon closing of browser)

I take it you are using something like

to set expiration to browser exit.
That will work for a normal cookie, but the CI session cookie is another animal.
In your config.php the session expiration is set to 2 hours (7200 secs)

$config[’sess_expiration’] = 7200;

If you set this to 0 (Zero) the session will never expire.
So check if you are mixing ci_session cookie with “normal” cookie usage.
ci_session cookie data is usually set/unset using

No, I’ve modded the sess_write() function in Session.php to write 0 as expiration time.

I get some inconsistent results if I apply that change to Session.php.
Basically, If I load a page displaying session details, exit browser and reload, I get the following:

FireFox : Works as anticipated, new session details on re-opened browser.
Opera 9: Works as anticipated, provided browser cache is not in use.
IE 6 : Displays old session details, a new session is not started on re-opening browser.
      Browser cache setting does not seem to affect this.
      If config session expiration set to something like 60 seconds, the old session is destroyed after that period,
      but not on browser exit.

I think there is a potential for confusion with your change to sess_write() to set expiry to 0.

      // Is the session current?
      if (($session[‘last_activity’] + $this->sess_length) < $this->now)
      {
        $this->sess_destroy();
        return FALSE;
      }

The session class will be getting sess_length from the config, in your case 7200 secs. Unless of course you have catered for that.

Sorry I can’t offer more help, but I am curious as to the problem here, is there any other info you might be able to add?
Like CI log debug messages or anything which might narrow the field?
Also, this thread may help you closing sessions on browser exit

Regards
Oscar

But it still should not sign the user out right after he sign in, session should be valid for 7200 secs if he keeps his browser open.
Another user just reported to me that he’s able to keep the session after he upgraded to IE7. So there’s definitely some inconsitency here.

From what I’ve gleaned, it seems IE 6 SP1 has some obscure funnies concerning cookie handling.

Are any of your users who have reported a login redirect NOT using IE?
Of the users who report a problem, do they report a repeatable problem, or is it intermittent?

I agree with you as far as your change to the code goes, there is nothing there that should affect
the session status from one page load to the next.
If the session cookie is set, then it is set.

I can only conclude that it must have something to do with the way the browser is handling the cookie.

Regards Oscar

Hi, I posted another solution for some days but the thread have been deleted, somebody have answered so I answer in this thread.

My solution is in config.php I set
$config[‘sess_expiration’]      = -1;

In session.php library, in the function sess_write:

Somebody answered me saying that:

If you change the config sess expiration to -1, there is some code in the
session class (lines 103 - 110) which does
the following :

$expiration = $this->CI->config->item('sess_expiration');
        
        if (is_numeric($expiration))
        {
            if ($expiration > 0)
            {
                $this->sess_length =
$this->CI->config->item('sess_expiration');
            }
            else
            {
                $this->sess_length = (60*60*24*365*2);
            }
        }

this->sess->length is used elsewhere and if the database is switched on will
result in expired sessions only being garbage collected
after two years.

I don’t have the problem because $expiration variable = -1 so <0 and $this->sess_length = (2 years) that’s OK.

But $this->sess_length is used only to set expiration cookie in sess_write function and my solution checks if ($this->CI->config->item(‘sess_expiration’) < 0)?null:($this->sess_length + time())  so if $expiration <0 I set expiration value to “null” not “0”, in other case, I use sess_length (php manual setcookie  , expiration parameter if is null is a non-persistent cookie).

The person who answer me continue saying:

Two:
Browsers like Microsoft IE v 6 Service pack 1 (and possibly others) do not
properly expire non-persistent sessions.
If you have access to IE 6 you can test it out yourself, I have and can
confirm it.

This can lead to problems, for example, your session is set to expire at
browser exit, forcing the user to login again on revisit.
MS IE 6 users will retain the session, and not have to login again, unless
you test for time inactive or something.

This thread, [url=http://codeigniter.com/forums/viewthread/46521/]Losing
session after login[/url] discussed another
problem, where someone also modded session.php to allow non-persistent
cookie, and had users report unexpected behaviour.

Is a IE6 SP1 reported bug??? I check my solution with IE 5.51.4807.2300, IE 6.0.2800.1106 (XPSP1), IE 7, opera 9, firefox 1.5, netscape 7 and works. I search something in the net, but only I found that bug http://www.microsoft.com/downloads/details.aspx?familyid=88C677AF-DB73-4A6A-B2FD-FF52923B81D1&displaylang=en and this http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerProgrammingBugs  but nothing about real problem with session cookies if I write directly the url in the browser. Possibly others???? PEAR Auth library works with the same cookie configuration and works since 2002-02-07 (the first stable version) and many websited uses non-persistent cookies, really there are problems with this sites? Microsoft, Spaces, Hotmail, .... Non-persistent cookies is standard in fact and if really other browsers have bugs then they don’t respect the standard (since now I have not found any).

So, anyway I write some alternatives, my solution is a simple patch. A real solution would be one more config variable $config[‘is_persistent_cookie’]  = TRUE / FALSE . And of course, I had the old $config[‘sess_expiration’] with the normal behaviour of CI (0 = infinite, >0 expiration time).

In the session.php check in setcookie if $config[‘is_persistent_cookie’]    = TRUE then $expiration = $config[‘sess_expiration’] in other case is null.  This alternative solution permits non-persistent cookie and is more clear.

Hi, I was the one who replied to your original post.
That seems strange, that the thread got deleted??

Anyway, briefly:

Is a IE6 SP1 reported bug??? I check my solution with IE 5.51.4807.2300, IE 6.0.2800.1106 (XPSP1), IE 7, opera 9, firefox 1.5, netscape 7 and works.

That is interesting. I have the exact same version of IE 6.0 but running on WInME. And for example, if I use your session mod, It works on every browser I have except IE. (The session cookie still exists after re-loading the browser).

I don’t know if it is an “official” bug, I found a reference to it in the php manual Non persistent cookie bug

Some versions of IE6, when you drop a non-persistent cookie, handle this incorrectly and instead drop a persistent cookie.
... Specifically, IE6 build 6.0.2800.1106CO (SP1) does this.

Now, about your changes…

I don’t have the problem because $expiration variable = -1 so <0 and $this->sess_length = (2 years) that’s OK.

Yes, it does not matter if $this->sess->length is 2 years when you set the cookie, because you check $expiration and set
a value of null.

But you agree that $this->sess_length is now 2 years?

That means db table will only clear expired sessions older than 2 years.

I like your suggestion and I agree that CI session should allow to set a non-persistent session cookie.
Also, I agree that to set session_expiration to zero when in fact that means 2 years is not logical.

Try post this to the feature request forum again. If Rick is not interested then you can always implement your change
in your own application library.

Regards
Oscar

Oscar Bajner - 23 November 2006 02:06 PM

Hi, I was the one who replied to your original post.
That seems strange, that the thread got deleted??

wops! mmmm, yesterday, the link in the subscription mail shows me a “no found thread”, today works…. ¬¬

Oscar Bajner - 23 November 2006 02:06 PM

That is interesting. I have the exact same version of IE 6.0 but running on WInME. And for example, if I use your session mod, It works on every browser I have except IE. (The session cookie still exists after re-loading the browser).

I don’t know if it is an “official” bug, I found a reference to it in the php manual Non persistent cookie bug

Some versions of IE6, when you drop a non-persistent cookie, handle this incorrectly and instead drop a persistent cookie.
... Specifically, IE6 build 6.0.2800.1106CO (SP1) does this.

Ok, seems it is a problem with IE 6SP1 and WinME (with 2000, XP no problem), I think that WinME is not supported by Microsoft, or they didn’t make the patch.

Anyway about the horrible bug of IE SP1 reported in php manual with the link to Microsoft (about I read in the comments of the users). The bug concerns only third-party cookies not in first-party, so if I have www.mydomain.com/ci_installation…. the cookie is deleted correctly, the problem reside with frameset pages with https in ones and http url’s in others… (the domain is not the same), another problem with older programmers is that earlier versions of IE (5.5, 5.0, 4, etc…) don’t distinguish between third-party and first-party cookies, but anyway the programmers would to have the knowledge of this fact because Firefox, Safari and others distinguish the cookies domain security since many many years.

[Microsoft]
First-party cookies that have a compact policy which specifies that personally identifiable information is used without implicit consent are downgraded (deleted when you close Internet Explorer). First-party cookies that do not have a compact policy are leashed (restricted so that they can only be read in the first-party context).
First-party cookies that do not have a compact policy are leashed (restricted so that they can only be read in the first-party context).
[/Microsoft]

I wouldn’t like that CodeIgniter doesn’t allow “non-persistent” cookie because a (I think) trivial bug in one version of a browser.

Yes, it does not matter if $this->sess->length is 2 years when you set the cookie, because you check $expiration and set
a value of null.

But you agree that $this->sess_length is now 2 years?

(line 378 + )
    function sess_gc()
    {
        srand(time());
        if ((rand() % 100) < $this->gc_probability)
        {
            $expire = $this->now - $this->sess_length; // <--Here is 2 years now
            
            $this->CI->db->where("last_activity < {$expire}");
            $this->CI->db->delete($this->session_table);

            log_message('debug', 'Session garbage collection performed.');
        }
    }

That means db table will only clear expired sessions older than 2 years.

I like your suggestion and I agree that CI session should allow to set a non-persistent session cookie.
Also, I agree that to set session_expiration to zero when in fact that means 2 years is not logical.

You are right . I didn’t see the changes in database sessions, simply I not use it.
So I wrote in the final of the post the possibility of another config variable ,“isperstistent”,
to permits this cases (delete cookie in browser exit and expiration time in the database, because we
can not know when browser exits).

wops! mmmm, yesterday, the link in the subscription mail shows me a “no found thread”, today works.

No Problem

Ok, seems it is a problem with IE 6SP1 and WinME (with 2000, XP no problem), I think that WinME is not supported by Microsoft, or they didn’t make the patch.

Yes, WinMe is no longer supported. I am relieved to learn that this bug probably will only affect a small number of users.
Thanks for the explanation about the problem.

I wouldn’t like that CodeIgniter doesn’t allow “non-persistent” cookie because a (I think) trivial bug in one version of a browser.

Yes, to be clear, in my original post I was not suggesting that non-persistent cookies don’t work, or that your changes would not
work, I just wanted to draw your attention to the fact that there are browsers out there that are buggy in this respect,
to save you some time if some of your users reported strange problems

I would like to see this enhancement to CI sessions, so please do post this to the features requests.
Regards Oscar

I found good solution from Microsoft support about loosing session data if using frameset html. Please check this link : http://support.microsoft.com/kb/323752/EN-US/

And in all views page, I just add this script into HEAD :
<?php header(“p3p: CP=\“CAO PSA OUR\”“);?>

After that, I am not loosing my session again even using FRAMESET html.

cheers,
Cahyono