Login member via add-on?

Found it in the code! 😊 Seems like this should do the trick:

$session_id = ee()->session->create_new_session($member_id);

There are a number of checks that ExpressionEngine performs to check the validity of the request before creating a trusted session, are you bypassing all of those? Username/password, login attempt lockouts, ban check, IP required, allow/disallow multiple logins, member account activated, remember me, update online user stats, session type, all of the login related extension hooks that other add-ons would expect to fire when a new session is created, etc.

You’ll find most of that in the Auth library; I wouldn’t advise using the Session library directly.

Ideally I’d like all those checks to be performed, but there doesn’t seem to be any API for logging in a user by member_id?

How are you verifying that the agent is the member that you want them to log in as?

A unique hash is stored in the database together with the member_id it is associated with.

Yes, but I mean, when someone visits the site, how do you know that it’s who you intend it to be? In other words, without authenticating with username and password, what are you doing to ensure you are logging in who you think you are?

They know the secret hash, so they are the user. That’s all.

That seems incredibly insecure, so fair warning that a user authenticated with a single data point—that is undoubtedly transmitted over a network—should be locked down and still considered an untrusted agent for any destructive or privileged activities.

That out of the way, if you know the member ID, you could do this:

ee()->load->library('auth');
$member = ee()->db->get_where('members', array('member_id' => $member_id));
$sess = new Auth_result($member->row());
$member->free_result();
$sess->start_session();

That will get some of the checks, handle some cookie maintenance, and fire some expected hooks, at least.

Well, it is somewhat insecure; I have a big red warning about this in the docs. What makes it insecure though is the fact that the secret hash can be emailed to the user; if that is done, any servers on the way can read that email and grab the unique hash and then use it to log in. But then again, this is also the case with the “Forgot Password?” functionality that ships with EE.

(..) so fair warning that a user authenticated with a single data point

Trying to understand this statement … the hash is a single data point. So a username / password auth (two data points) would be more secure? If so, would a hash that is a combination of “username+password” be more secure than a generated hash?

Thanks for the code, I’ll use that instead to get more of the native functionality included in the login.

Absolutely username and password is more secure, not just because it’s two data points, but also because the password is provided by the user, never an admin or even ExpressionEngine. It can’t be reverse engineered, and it can’t be copied from the database. If a site is running SSL (as it should), it is very hard to intercept or spoof, and only weak passwords are really at risk. And even then there is built in protection against brute force.

A single hash, regardless of how many variables were used to generate it, is not going to increase its strength, unless your hashes were previously made and stored from a single piece of public information. The forgot password URLs expire quickly, and cannot be used again after being used successfully. How do your hashes work, how are they generated, and what triggers their creation?

Absolutely username and password is more secure, not just because it’s two data points, (..)

Ok, I thought maybe it was a general advice against using a single data point. All the stuff listed could be the case for a single data point - although, it isn’t, in this case 😊 So in this case, way more insecure (but not because it’s a single data point, but because of all the other stuff (generated etc.)).

How do your hashes work, how are they generated, and what triggers their creation?

Right now, like this:

$hash = md5(ee()->localize->now.$member_id.rand(999, getrandmax()));

They are created on user signup (hooking onto one of the member registration hooks) if the admin has enabled the creation of an “auto login link”. So, one for each signup (if enabled).

Looking at it now I guess the security of the hash could be increased by replacing $member_id with $member_email (since $member_id is incremental and $member_email is provided by the user).

But this functionality is never going to be secure in any case so a big red warning is probably best. In fact I’ll integrate that into the admin panel as well, and link to the warning in the docs. It is meant for websites not needing top notch security.