Kohana Forums

phpguru

Hoping to get someone to verify this. It took a while to figure out...

I'm using 3.0.8 from the zip download and manually merged in the Auth ORM from the Github sources. I copied modules/database/config/database.php to application/config/database.php and modified it accordingly. I copied modules/auth/config/auth.php to application/config/auth.php and modified the salt according to this Mixu.net post.

Bug #1:
When I register, my app's database config and auth config's salt pattern are read correctly. I get a users row created with a hashed password, a login role and that works. However, when I go to login, Kohana complains access denied to ''@'localhost' on database 'kohana' which indicates to me that the _login( ) method within Auth is reading the database config values from modules/database/config/database.php and not my app's.

Bug #2:
When I examine the salted password on failed login stacktrace, it has been salted with the default pattern from modules/auth/config/auth.php instead of my app's.

Workaround:
I had to copy my app's DB config file overwriting the database module's config, and same with the auth config's salt pattern. Once those two files matched, everything worked as expected.

zombor

Application files always overload a module's file. If it's not occurring, you are doing something wrong. Maybe you have file path caching on.

phpguru

Is file path caching on by default? I've not changed much else in this project. Where would I find that?

zombor

It's in your bootstrap, and documented there as well.

phpguru

Oh this: boolean caching enable or disable internal caching FALSE. Nope, not setting it to true in my bootstrap. I wouldn't be surprised if I did something wrong, but all I've really done is follow the ORM Auth examples here, on the docs, Kerkness, and on Mixu's blog in the simplest fashion possible on a brand new site with nothing else going on, and yet login complains for a database named 'kohana'.

phpguru

Okay, Zombor, maybe this helps. I had changed my 'default' config group in my database config to 'content'. In other words, I had no default database config group in my app, only one named 'content'. AWEllis suggested I change it back to 'default'. That then worked.

Lesson: Only use a different database config group key (other than 'default') if you need a 2nd database connection. I still think it is a bug in the Auth ORM login somewhere, seeing how as everything else worked as expected with a 'content' database config group only.

zombor

There's no bug. You could leave it as 'content' and change your orm model instead.

xenakis

It's not a bug at all.

The ORM model looks for the 'default' config of the database just like it should. Like Zombor said, if you are planning to change the name of this configuration, you should reflect this in your ORM model.

phpguru

I did, xenakis. I changed database config group to 'content' in my application config as I said above. I also created a base model file with protected $_db = 'content'. All my ORMs inherit from it. When I did that, auth ORM register function correctly read my application/config/auth.php and application/config/database.php and created a new `users` row in my database with a salted password. When I tried to login, it failed with access denied for ''@'localhost' on database 'kohana' and is using the default salt from modules/auth/config/auth.php. If this is not a bug I don't see how a misconfigure error on my part can work fine for register function and fail to find the same config files for _login and auto_login - it's the same module with the same configs.

The workaround for me was that I had to use the same salt in

application/config/auth.php &
modules/auth/config/auth.php

and the same db credentials in

application/config/database.php &
modules/database/config/database.php

I realize this says I must be doing something wrong, but I don't see what, and it is definitely happening and definitely reproducible for me.

andrewc

This is definitely strange, but I don't think an error in the core files (though may be wrong). What's the class in which you define your protected $_db, and what's the inheritance tree for your Model_User? If you're using that mixu post, are you using his custom models, in which case the inheritance looks to be Model_User (from mixu, doesn't support transparent extension) > Model_Auth_User > ORM > Kohana_ORM? Have you checked that you're getting instances of the same class types in the register and login functions?

However, the fact that you're getting different salt values in different requests is very strange, as that setting is loaded by a simple Kohana::config call in Kohana_Auth::instance and there are no reported issues with Kohana::config not returning expected results from the cascading filesystem.

Have you checked that all filenames are lowercase, array keys and structure identical, same modules and configuration information (eg identical bootstrap execution) for all requests?

Is your app and module code available to look at somewhere for a second eye to spot any potential issues in the way you've set things up?

phpguru

Here's what I have in application/classes/controller/admin.php

class Controller_Admin extends Controller_Base
{ 
    // protected $_db = 'content';
    /**
     * @var User Object Instance
     */
    protected $user;

    public function before()
    {
        parent::before();
        $auth = Auth::instance();
        $auth->auto_login();
        if ($auth->logged_in())
        {
            $this->user = Auth::instance()->get_user();
            $this->template->navigation = $this->_get_navigation();
            $this->template->styles = array_merge($this->template->styles, array('css/admin.css','css/forms.css'));
        }
    }
// some more stuff that shouldn't affect anything
}

Note that I currently have the protected $_db = 'content' commented out because I was only able to run with the 'default' database config. Anyway, all my other admin controllers extend Controller_Admin. Controller_Base extends Controller_Template and has a session variable and some other stuff; all the other non-admin controllers extend Controller_Base.

The moment Auth registration worked, I figured I had it set up right, but I couldn't login. The $auth->auto_login( ) stuff is what appeared to be getting the module's default values. It took me quite awhile to figure out what was going on because since forever back to the KO2x days I know that app stuff overrides module stuff... so to learn that the auth login was using the default DB & auth configs really threw me into a headspin. I still haven't figured out if I've done something silly in the inheritance tree. I also haven't had time to download the core files again and test it on a fresh setup.

andrewc

Your $_db variable is in your controller, and needs to be in your model somewhere. You could include it in a transparent extension of ORM if you want it to be the same across all ORM models, or in a customized version of Mixus Model_User since that can't be transparently extended.

Given that the $_db var is in the wrong class, I don't actually know how the register ever worked but am not surprised that login didn't. Are you passing $_db to the model before save in your register controller action?

xenakis

It's very rare that you would find such a evident bug in Kohana as the code is pretty clean. Andrewc is right, that $_db variable must be set in your model.

When something like this happens again, make sure you read the docs. And ask yourself, does this make MVC sense? You'll be quick to agree that a $_db variable should be set in the model since that's model logic. Controllers shouldn't worry about what database is being used by the model, that's for the model to worry about.

phpguru

Oh snap - what a silly mistake! That has to be it. I'm guessing I had protected $_db = 'content'; in one model file and not another which may explain why register worked but login didn't. Sorry for wasting bandwidth guys. For the record...

application/classes/models/ormbase.php:

class Model_Ormbase extends ORM { 
    protected $_db = 'content';
}

Then in ORM models...

 class Model_Otherormmodel extends Model_Ormbase { 
    // stuff 
}

Works as expected.

andrewc

But bear in mind your ormbase won't be inherited by module models eg Auth etc.

I'd do

Application/classes/orm.php


class ORM extends Kohana_ORM {
    protected $_db = content;
}

If you want that db for all ORM models.

phpguru

Yeah, better idea. Thanks @andrewc

Hey for what it's worth I changed my salt pattern in application/config/auth.php and deleted my user account and re-registered (different salt) and now cannot login. If I change it back to the same values as in modules/auth/config/auth.php and re-register, it works again. o_O

andrewc

I think there has to be some issue with your setup of config - Auth doesn't do any magic when it comes to reading the config values, so if this isn't working properly it would have to mean the issue existed in all Kohana::config calls, and I find it hard to believe that wouldn't already have been found.

Just to confirm your troubleshooting process on this:

You deleted your user account completely, so that you were starting from a blank table
You exactly copied modules/auth/config/auth.php to application/config/auth.php
You changed the value of the salt pattern in application/config/auth.php
You registered a user account and saw that it was created with a salted password
You attempted to login and this failed specifically because the password didn't match
You deleted application/config/auth.php
You attempted to login with the same username and password and were successful

Isaiah

Also make sure you set a valid salt pattern. You can't just use any values, they have to be a valid offset in your hash (i.e. you can't use numbers greater than the length of the hash type you are using) and they must be in ascending order.

phpguru

@andrewc - Yes to 1 through 6, no to 7. I copied the default auth config and changed '30' to '20' (lower than 28, the preceding number). Register worked, login failed. Removed the config and login still failed.
@Isaiah - You're my hero...

they must be in ascending order

...must be where I went wrong. I thought the salt pattern was just a "pseudo-random" collection of numbers. What's a salt pattern anyway?

Isaiah

What's a salt pattern anyway?

It's a list of offsets to store the salt value at. So they must be valid offsets in your hash and must be in order or else the salt value will get messed up.

Kohana Forums

Howdy, Stranger!

Categories