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 db.active over to another database?
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.
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 db.active 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 db.active, 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.
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:
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...
if ($this->authenticated and \Auth::get('group_id', 0) == 1 and ! in_array(\Uri::string(), ['account/pending', 'account/logout']))
{
\Response::redirect('account/pending');
}
// call our parent
parent::before();
}
}
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?
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...
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.
Donate
