October: Add ability to configure whether or not backend users must be activated before they can login

[tim0991]

https://github.com/octobercms/october/blob/33d492fda730814089087c68778b5238cf510de4/modules/backend/classes/AuthManager.php#L24

In my test, i found no matter what backend_users.is_activated value is, the backend users can signin

https://github.com/octobercms/library/blob/master/src/Auth/Manager.php#L372-L374

class Manager

...

protected $requireActivation = true;

...

if (!($user = $this->getUser()) || ($this->requireActivation && !$user->is_activated)) {
    return false;
}

So, Backend\Classes\AuthManager override October\Rain\Auth\Manager's requireActivation property, and set it to false

What is the reason for doing this, and how can i enable backend user activation

October build

431

[ghost]

I do confirm that this is indeed a bug. Please add the necessary label to this @LukeTowers.

I will work on getting this fixed and will submit a PR.

[developerabdd]

+1

I don't believe it is correct to call this a bug; setting $requireActivation = false was probably not accidental.

So what remains to be known is: why was it done and how can we get an option to enable it if want/need it, without having to manually implement the login/is_activated system manually?

[LukeTowers]

Few options to handle this:

Add the ability for this to be turned on and off with a file config option

or

Add the ability for this to be turned on and off with a DB setting

or

Both of the above.

[Samuell1]

@LukeTowers i think this will be cool to have in cms.php config and default as null depending on debug mode.

[LukeTowers]

@Samuell1 I could agree with having it in cms.php but not with a null depending on debug mode since user's aren't automatically activated when they're created (AFAIK) which would create a breaking change for users.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.

[LeoCantThinkOfAName]

Just happened to have the need to implement a function to manually activate a admin user, or maybe by notification mail.

And found this is a very useful attribute to have, and probably the best way to do this kind of thing.

Yes, this is a low priority issue, but I can not believe this has been here for like two years.

I just spent some time figure this out. It's actually a easy fix, and probably going to make a pull request after this.

According to the thread above, @Samuell1 and @LukeTowers mentioned it may be a good idea to store the configuration inside cms.php. I don't really know how octobercms was looks like back than, but I think it may be a better idea to store it in auth.php, since all the authentication related configuration is there ( login throttle etc... ).

If you guys all agreed on this, I'll make the pull request right away.

Any input on this?

[LukeTowers]

@LeoCantThinkOfAName when this issue was originally submitted auth.php did not exist. auth.php is a perfectly fine place to put such an option.

[bennothommo]

@LeoCantThinkOfAName

Yes, this is a low priority issue, but I can not believe this has been here for like two years.

These sorts of comments don't help anyone. We work tirelessly in our own unpaid time on development of this plugin and October CMS, and thus we have to prioritise our work. If you want stuff done faster, submit a PR or put a bounty on it.

As to the actual issue, can anyone give a good reason as to why you need activation for Backend users? The process of requiring activation is a once-off action that is best for when you have open registrations where people register and have to confirm their email or be manually approved before they have an account.

There's no such capability for the Backend as there's no registrations - an administrator has to be manually created by someone privileged to manage administrators. In addition, it wouldn't make much sense to create an administrator account unless you know that the person needs access, and you know that person's email address is valid.

If someone can provide me a suitable reason why this would be needed, then we'll be happy to consider it. But right now - I don't believe anything needs to change here.

[LeoCantThinkOfAName]

@bennothommo

I understand, and apologize for the harsh commenting. I'm not tryin' to pointing my finger on anyone here.

My specific case may be a lil bit edgy for most cms' are intended for, I'm not going to explain more about my needs.
But for this topic, I found some interesting things inside the codebase, also in the database.
For me, it seems like a conscious derision to leave the is_activated and activation_code etc... on the backend_users table.

Register as backend user is probably not the best idea for open web, but is also a legitimate function to have. (ie. wordpress has this kind of function, but if I was right, they don't have a really good spam protection by default).

Personally I'm not going to implement the register function, just make a small change on this, and I think registration is probably better to be done by plugin, instead in core. Since I agree with your point, I's not necessary for cms.

Anyway, I've made a pull request on this issue, but not really sure if the comment in config file is good enough for it.

If there's any idea or thought on this topic, please advice!

[LukeTowers]

@LeoCantThinkOfAName I would be interested in hearing more about your specific use case, October gets used for a lot more than just a simple website CMS. With regards to your comment about blocking users without deleting them, the backend users table implements soft deletes for blocking functionality so that relationships are always preserved while preventing logins from users.

[bennothommo]

@LeoCantThinkOfAName

I understand, and apologize for the harsh commenting. I'm not tryin' to pointing my finger on anyone here.

Thank you, and I apologise if I was overly harsh.

Personally I'm not going to implement the register function, just make a small change on this, and I think registration is probably better to be done by plugin, instead in core. Since I agree with your point, I's not necessary for cms.

I agree - this is probably a function best done as a plugin if someone really requires it.