Possibility to login user through API without knowing password

[apeisa]

There are often situations when it would be valuable to login using client's credentials. It is slow to create new user with same roles and test that way. It would be great to have a module which allows to login using any username and without changing the password (of course security of that module needs to be top notch).

Other use case is when adding additional login methods (like fb, google account, github... etc). If I have understood correctly, currently we always need to know (or change) the password to be able to login. So what I am looking for is something like:

$session->forceLogin($username);

[Soma]

How about a module that copies the user and sets a random passwd and logs in.

[apeisa]

I thought about that and it would work nicely on first case (ie. support logins), but would fail on additional 3rd party login options.

[nik]

There's also Session::authenticate(User $user, $pass) available for hooking. Session::login calls that to check the password, so overriding that is probably exactly what you're looking for.

[diogo]

What about a module that would temporarily replicate the admin behaviour for any user without leaving the superuser session?

[ryan]

There are often situations when it would be valuable to login using client's credentials. It is slow to create new user with same roles and test that way. It would be great to have a module which allows to login using any username and without changing the password (of course security of that module needs to be top notch).

$user = $users->get('antti'); 
$users->setCurrentUser($user); 

If you want to make the user persistent for the session (without having to do the above on every request), then do this:

$session->_user_id = $user->id; 

[apeisa]

$session->_user_id = $user->id;

I don't seem to get this persistent. Is it protected somehow?

[ryan]

I don't seem to get this persistent. Is it protected somehow?

It shouldn't be. PW only sets this on login, and it should be retained for the session. There isn't any code preventing modification of it.l Double check that the value you are carrying in $user isn't the same one that's already in _user_id?

[nik]

I had this exact problem last week when fiddling around with login stuff. Didn't have the time to dig any deeper then, but now I do.

Could it be because of sessionChallenge-setting? Looks like a challenge-cookie is being set only during the normal login() method. Challenge is checked by isValidSession() during Session::construct() and if it doesn't match user will be immediately logged out. And as challenge MD5 generation uses logged in user's id, it just won't match when $session->_user_id has been tampered with. So sessionChallenge does offer extra security like it was supposed to.

Thus, only setting $session->_user_id isn't enough when sessionChallenge is set to true in site/config.php. @apeisa, try it out after setting sessionChallenge to false.

And there's also sessionFingerprint with similar effects, it seems. Hmm, no, this wouldn't actually be a problem I think. There is a session for guest user as well, so fingerprint does exists and is valid. Anyways, I didn't try this out yet, but I think this shouldn't be a problem after all.

It wouldn't be wise to duplicate these things to own code, so looks like there's a need for some addition somewhere to make it possible to log another user in via API without knowing the password. More permanently than for the current request only that is. But is there a security concern lurking somewhere I'm not able to see from here?

[nik]

Actually.. If you'd hook Session::authenticate() (as I already suggested) before calling Session::login(), you'd be able to do whatever check necessary for authenticating the user - or no check at all if it's all covered already. This way all the magic in login() would be executed and a real session with everything in order would exists. You'd probably want to call $users->setCurrentUser() on top of that as well to make the login effective on this very request.

And you didn't have to make any more permanent hook to Session::authenticate(), just a one-timer before your own login() call. A before hook with $hookEvent->replace set to true.

Forgive me everyone if I'm just hallucinating here, still on painkillers...

[apeisa]

Nik, Ryan, anyone: getting back to this. I am not yet building the module (admin login), but have another use case (3rd party integration). I would like to hook into Session::authenticate from template code. Is that possible or do I need an autoload module to use hooks?

[nik]

Antti, yes, it's certainly possible. You can hook whenever and wherever you like. It's just a matter of being certain your hook has been registered before the event you're aiming for takes place. So you only need an autoload module to hook something you don't have full control yourself, and don't want to or are not able to require some initialization being called before using the hook.

Here goes. And this one I tested a little so I know it works, for me at least .

function myCustomAuthentication($event) {
 $user = $event->arguments[0];
 $pass = $event->arguments[1];

 // TODO: do whatever check is needed to authenticate $user
 // $pass has whatever you like, a token of some kind probably

 // must set replace-flag to prevent the original Session::authenticate() being called
 $event->replace = true;

 // return value is boolean
 // true: successfully authenticated
 // false: authentication failed
 $event->return = true;
}

// ...aquire a user name, somewhere, somehow...

// hook *before* Session::authenticate() to override it
// second argument is null because we're using a plain function and not a method inside an object
$session->addHookBefore('authenticate', null, 'myCustomAuthentication');

// log in the user, passing whatever needed by myCustomAuthentication() as a password - if anything
$user = $session->login("some-username", "some-token-with-a-meaning-in-this-very-context");

I'll actually be using this piece of code myself as well, this week I hope.

[apeisa]

Damn, my code was so close already

Thanks Nik, that example of yours will get into good use tomorrow!

[adrian]

Just in case someone stumbles across this in the future - forceLogin() is now available (since 2.6.8): https://processwire.com/blog/posts/processwire-2.6.8-brings-new-version-of-reno-admin-theme-and-more/#new-session-gt-forcelogin-user-method-to-login-user-without-a-password