Code Igniter Login, Session and Redirect Problem i

2019-02-09 20:41发布

问题:

I'm still new to code igniter and I'm having problems getting the login system to work.

The login always works when I use Firefox. The login consistently works on some IE7 browsers but consistently fails on other IE7 browsers.

When tracing the code, I see that the models/redux_auth_model.php does successfully authenticate the user, it writes user information into the $this->session->set_userdata() and it redirect them to a member's page of my choosing. Here's the code:

public function login($identity = false, $password = false)
{
            $identity_column = $this->config->item('identity');
            $users_table     = $this->tables['users'];

            if ($identity === false || $password === false || $this->identity_check($identity) == false)
            {
                return false;
            }

            $query = $this->db->select($identity_column.', email, password, group_id')
                           ->where($identity_column, $identity)
                           ->where('active', 'Active')
                           ->limit(1)
                           ->get($users_table);

        $result = $query->row();

        if ($query->num_rows() == 1)
        {
            //$password = $this->hash_password_db($identity, $password);

           if (!empty($result->activation_code)) { return false; }

                if ($result->password === $password)
                {
                    $this->session->set_userdata($identity_column,  $result->{$identity_column});
                    $this->session->set_userdata('email',  $result->email);
                    $this->session->set_userdata('group',  $result->group_id);
                    return true;
                }
        }

        return false;
}

I did a variable dump of $this->session in both IE7 and FF and confirmed that all the userdata is intact before the redirect. The session had my email information, group information and $identity_column information.

However, after the redirect, the session data is empty on some IE7 browsers, which is why CI keeps booting me out of the system. It's fully intact on other IE7 browsers and always intact in Firefox.

Why would session data be browser dependent?

Any ideas on how to troubleshoot this further? I am baffled...

回答1:

It is a frustrating problem with the Codeigniter database session class, in the end I resorted to using native sessions using the drop-in replacement found here: https://github.com/EllisLab/CodeIgniter/wiki/Native-session



回答2:

I was having the same problem while using CI Session in IE. Then I use the below header in controller constructor and it works for me.

Here is the header:

header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');



回答3:

I faced the same problem while using IE8 with browser mode. I've found the problem is in matching the user agent. In session database it saves useragent as IE7 but from cookie it gets IE8. I've set $config[sess_match_useragent] = FALSE and the problem is solved.



回答4:

The session class works fine in several of my projects including IE6/7/8 support (including multiple releases of CI). There are a few things that might be causing this, outside of the code pasted above:

  1. Calling $this->session->sess_create(); from a baseclass (or elsewhere in your class's code) would reset your session.
  2. Try combining your set_userdata calls to one call by passing it an array.
  3. Make sure your data does not have any unexpected characters in it (this can cause issues in certain browsers).
  4. Make sure your session class settings in the config are not rolling over the cookie every request.

Alternatively, consider an alternate session class like Native sessions



回答5:

This is an issue that someone made a 3rd party fix for, it patches the session controller. Let me dig it up. I have used it in my codeigniter setups since it was first noted.

This issue is IE7/IE8 specific with redirects or frames.

EDIT

Here is the reference that I have found before, it helped me with the IE issue. Hopefully this is what is causing you headaches: http://www.philsbury.co.uk/blog/code-igniter-sessions



回答6:

It's a problem with browsers. I put this in MY_Controller in constructor:

header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");

for example:

if($this->uri->segment(1)=='admin') header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");


回答7:

We were developing an app involving a Facebook tab when we ran into this problem. We tried the above to no avail. Here's what we found out:

  1. IE privacy settings seem to have to be medium or less
  2. If your running a page app, make sure BOTH URL's have HTTPS protocol in them

Also, look into the Compact Privacy Policy for cookies.



回答8:

config file application config.php

// 'cookie_secure' =  Cookies will only be set if a secure HTTPS connection exists. 
$config['cookie_secure']    = FALSE;


回答9:

I solved this by using native php session instead of cookies (Storing codeigniter session_id in php native session).

You can grab library here: https://github.com/staskus/codeigniter-2.--native-session.

Just copy MY_Session.php file into applications/libraries



回答10:

The problem is IE denying the cookie CI is trying to set. Native sessions is one way, however if you want to keep using CI sessions I have had success with the following troubleshooting:

  • Check that setting $config['cookie_domain'] in config.php is not empty
  • Remove the underscore from $config['sess_cookie_name'], for example change "ci_session" to "cisession"
  • Check that the server time is correct


回答11:

I hate IE !!!

its working now giving P3P to our controllers fix the problem :

class Chupacabra extends CI_Controller {


    function __construct() {
        parent::__construct();
        header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');


    }


回答12:

This issue plagued me when I was trying get a login page to work in CodeIgnitor. The session would not save.

It turns out that it was due to a domain name that I created from FREEDNS that contained an underscore (_). I renamed the domain name using a period (.) and reverted all the code changes that were suggested in this post, and Voila, it worked.

Thanks for all the comments and contributions on this page because they really led me down the road of investigating that darn underscore.