Added user refresh function to Auth class

[corbinu]

I ran into an issue when creating a user profile page that the current user is stored in session by Auth won't be reloaded until the user logs back in again. This is my quick and dirty fix so that $auth->refresh_user() can be called after a major change to a user that might be logged in. There might be a much better way to do it.

Also thanks to everybody who works on the project is very useful :)

[taai]

Did I understand it right? When the user changes his information in his profile page, the old information in session (!) is not being changed? But in database the information is changed, right?

[taai]

If I understand it right...

No, that's not alright. The complete_login will call the function inside Model_Leap_User and the login time will be updated, also the session will get regenerated...

All you want is to reload user data in session, after you have changed it, right? Well, you can update session like this:

<?php
// $user = ...   -  your Model_Leap_User model that you have changed and saved in database...

// save/update the user data in the session
Session::instance(Kohana::$config->load('auth.session_type'))->set(Kohana::$config->load('auth.session_key'), $user);

But if you want to make a more usable function, yeah, why not! Just don't re-login the user. Here you go:

<?php

    /**
     * This function refreshes the current user's object.
     *
     * @access public
     * @return boolean                           whether the user has been refreshed or not
     */
    public function refresh_user() {
        $user = $this->get_user();

        if ( ! $user) {
            return FALSE;
        }

        $user = DB_ORM::model($this->models['user'], array($user->id));

        $this->_session->set($this->_config['session_key'], $user);

        return TRUE;
    }

[bluesnowman]

@CubedEye Do you have an opinion regarding this issue?

[CubedEye]

The refresh_user() function is a great idea and we've implemented something similar in a code base we're using, but it has a specific use in this case.

Although I'd refrain adding it to the code base, because things that are going change often (Address, Phone, Other Profile Details, etc.) should really be in it's own table and accessed when required, not stored with the user object in session. In the case of the few items in the user table.

Name: Some sort of refresh is probably required, although how often is someone changing their name.

Email: Should have some sort of email activation to change. This activation should trigger a relogin just to confirm the new email via the password authentication. In the case of username only, I'd still advise a relogin although a manual refresh could be implemented.

Password: Can be changed and updated manually if going to be required again in the session, although all authentication (including change password) should be done directly with the database and not with the User object stored in the session. Given this, having an out of date session password is not going to be problem as it won't be accessed.

Just my thoughts... Let me know?

[corbinu]

I think your right would be better if was separate code... Once my site framework is all finished will probably OS it including my user management system... this might be better for there... Will keep submitting stuff if I think it might help. Is a great project and I hope to see it continue and help any way I can.

[taai]

@corbinu Yesterday I decided to do things differently. I don't store user data in the session at all, except just user id. Instead store the user data in cache and access it when needed. It's better also for cases when user is logged in multiple devices and when his data is being changed, you can see changes in every device.