rinvex / laravel-auth

A powerful authentication, authorization and verification package built on top of Laravel. It provides developers with Role Based Access Control, Two-Factor Authentication, Social Authentication, and much more, compatible Laravel’s standard API and fully featured out of the box.
https://rinvex.com
MIT License
132 stars 12 forks source link

[Feature] Allow users to self deactivate their accounts #141

Closed Omranic closed 4 years ago

Omranic commented 6 years ago

With config option for admins to enable/disable this feature.

noxify commented 6 years ago
Omranic commented 6 years ago

We can require password confirmation, but no need for email pre-confirmation. An email after deactivation is just fine. Yes for the event 👍

noxify commented 6 years ago

A pre-confirmation via mail makes no sense.

The first point meant the confirmation email after deactivating the account.

Password confirmation can be implemented via #84

Omranic commented 6 years ago

This feature is fine, but I'm not sure of how the correct implementation should be? Let's say the user de-activated their accounts, which is fine. How could he re-activates his account again (like what Facebook do now)? Currently disabled accounts can't login or gain any access; Only admins can control them.. I'm open to any suggestions.. 🤔

noxify commented 6 years ago

I think the easiest way is to implement something like the account verification. On the login page, we need only a new link „re-activate account“ or something like this.

The logic behind the scenes is the same as for the verification but will activate the account.

Maybe we can use the existing verification logic... Instead of using 0 and 1 in the field we can use several status

0 - new account, requires activation 1 - active account 2 - de-activated account

Alternative Solution: After deactivating the account, the user is able to login, but can see only the actions:

Maybe we can use soft-deletes to identity the current state.

Omranic commented 6 years ago

Soft deletes should server another purpose, we already have the is_active field for this use. I think I like your alternative solution, maybe that's more logical & streamlined from end-user perspective. What do you think?

Omranic commented 4 years ago

Not a priority!