Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Auth check() returns false
  • I'm using two databases, and an user types in a user name and a password and selects a database (oracle or mysql) in the login page.
    The default active db is oracle which is set in app\config\development\db.php
    So, when a user selects a mysql, then the following codes changes the config, and the Auth::check() returns 'true'.

    However, the Auth::check() in the template controller returns 'false', and thereby the login page opens over and over again.

    I added app/config/ormauth.php, and set the db_connection value to the file, but Auth::check() still returns false.

    I'd appreciate it if you could share any solution or workaround.
    Many thanks.
  • To be clear: your default database also contains all your ORM Auth tables, and Auth should continue to use that default DB for all Auth queries, even when you switch over to another database?
  • No, each database has a different users table. 

    In the login controller, auth check is successfully done using the selected database (e.g. mysql). However, auth check fails in the template controller since it still uses the default database which is oracle. 

    The template controller is auto-loaded by bootstrap.php since it displays the headers of the webpage.
    And, the template controller checks auth for permission to the header information.

    I think auth instance is reset at some point even after user login. I can't find where it is reset, or I don't know why template controller still uses the default database.

    I've set the db_connection in the template.php, but Auth::check() still returns false.

    < template.php >
    function before() {
    \Config::set('ormauth.db_connection', \Config::get(''));

    Should I combine login controller with template controller?
  • Again to double check:

    You present the user with a login form in which the user enters a username, password, and selects a database? When the user submits the form, you change to the selected database, and call Auth::login(). The user logs in, this works, and then redirects to another page. So the user authenticates not against the default database, but against the selected database. Correct?

    This other page loads, calls your template controller, it does an Auth::check(), which fails. From your code snippet, you set it's db connection to, but we have just established that the user didn't authenticate against the default database, but against the users selected database.

    So you need to store that selected database in the session, and in your template controller restore that (or at least use it to set ormauth.db_connection) before you attempt to call any Auth method.

    Enable the profiler in the config, and enable database profiling for all databases in your db.php, so you can exactly see in the profiler which query is sent to which database connection.
  • Yes, that's correct. The problem is caused by Auth::check() in the template controller.
    As you suggested, I used Session to save the selected database, but the template controller still uses the default database. I checked db queries after setting profiling to true in db.php. The login controller used the selected database, but the template controller used the default database.

    >> Session::set('selectedDB', $selectedDBname);

    >>\Config::set('ormauth.db_connection', Session::get('selectedDB'));
    >> Auth::check(); -> returns False!

    Do I still miss something?
  • Yes,

    As I told you earlier, the Auth code loads the config file like so:

    \Config::load('ormauth', true);

    which means that if that config file wasn't loaded yet, it will load it, and overwrite whatever is currently in memory. So your db_connection value will get lost because of this.

    So if you want to set config values at runtime, make sure the config file is loaded first:

    \Config::load('ormauth', true);
    \Config::set('ormauth.db_connection', Session::get('selectedDB'));
  • It still doesn't work...I think it might be better to provide the code to get better help.

    class Controller_Login extends Controller_Template 
    public function action_index() 
    if (\Input::method() === 'POST')
    $currentActiveDBname = \Config::get('');
    $selectedDBname = Input::post('database');

    if ($currentActiveDBname != $selectedDBname)
    \Config::set('', $selectedDBname);
      Session::set('selectedDB', $selectedDBname);
    if (\Auth::login(Input::post('username'), Input::post('password')) === false)
    die('Bad Username or Password');


    if (Auth::check())

    $this->template->content = View::forge('login/index');

    class Controller_Template extends \Fuel\Core\Controller_Template
    function before() 
    \Config::load('ormauth', true);
    \Config::set('ormauth.db_connection', Session::get('selectedDB'));
    if ( ! Auth::check() and Request::active()->controller !== 'Controller_Login')

    Auth::check() in login.php returns True, but Auth::check() in template.php returns False.
    Can you see anything wrong in the code?

  • I've tested it in one of our applications, which uses Auth::check() in it's before() method:

     * Check for access to this controller
    public function before()
        // only access for logged-in users
    \Config::load('simpleauth', true);
    \Config::set('simpleauth.db_connection', 'doesnotexist');
        if ( ! \Auth::check())


        // load the dashboard language file
        \Lang::load('dashboard', true);

    and when I switch to a non-existent database, fuel throws "Database type not defined in "doesnotexist" configuration or "doesnotexist" configuration does not exist".

    I'll see if I can find an app that uses Ormauth, and test the same...
  •     Found an app that uses Ormauth, this is it's base controller:

    class Base extends \Controller
         * @var  boolean  whether or not we have an authenticated user
        protected $authenticated = null;

         * Controller initialisation
        public function before()
            // authenticate the user
    \Config::load('ormauth', true);
    \Config::set('ormauth.db_connection', "doesnotexist");
            $this->authenticated = \Auth::check();

            // check for banned users
            if ($this->authenticated and \Auth::get('group_id', 0) == 1 and ! in_array(\Uri::string(), ['account/pending', 'account/logout']))

            // call our parent

    and with this code, it fails with the same exception. So it seems to be either the way you implement things, or the fact that you have a old(er) version of the framework. All our applications run on 1.9/develop, so you can try switching to that and see if that helps?
  • First, I tried with Simpleauth, and it worked!!
    Currently, I'm using 1.7.2 version.

    If the ormauth problem can be solved by the version upgrade, can I just use the newest auth package to my current project? For now, I kinda mind upgrading the entire project to the new version since it will takes long, and I'm a little concerned about any other possible side-effects by the upgrade. 
  • That's quite old, and the question is if the issue you have is part of the Auth package, the Orm package, or part of the framework classes.  Or part of your code. ;-)

    Not sure what PHP version you are using, but 1.7.2 isn't PHP 7 compatible either, so you might run into other issues sooner or later...

    You can check:

    1.9/develop mainly contains bugfixes against the latest 1.8. Upgrading means replacing the packages, replacing fuel/core, make sure you run composer to install the autoloader and any configured packages.

    Also check your public/index.php against the one from 1.9/develop, since that has changed. If you haven't made changes to it, you can simply replace it.

    You can do this on a copy of your app, so you'll won't impact your original codebase, and you can go back if you have an issue for some reason.

    I fear this is the only solution to your problem, other than debugging old framework code yourself and fix it locally.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion