Support for optional account verification
Closed this issue · 9 comments
Is there a way to got configurable option for allowing users with not approved account to log in? In my application e-mail confirmation isn't mandatory, but possible and adding more functionality for the users.
You should be able to override the login logic to support your use-case.
Yes, your extension is greatly configurable right now and thats what I've actually done. Just thought it will be good to have this feature in stock. Second project I've got where e-mail is not needed to activate account, but should be checked anyway to connect to it.
Thinking about adding extra boolean for this: email_confirmed.
The whole idea behind this extension was to allow you to use it for any application. I'd like to keep the number of features to a minimum, while leaving room for implementing any use-case you might have.
If you find something hard to implement, we'd love to hear about it. We don't want developers abandoning the extension because they are unable to implement, e.g. their authentication flow.
That said, the main focus of this extension is account security so anything we can do to make it more secure by default we will certainly consider implementing into the extension itself.
What we usually end up doing is using a different identity class (Account model) that may contain additional columns. Often that's the only thing we need to override, everything else can pretty much be done through configuration.
Actually what you could do is to use add a new status STATUS_VERIFIED = 2 for your Account model and disabled the whole account activation process. I think we should keep the account activation and verification separate. I'll give the verification part some thought, maybe we can support it out of the box as a separate feature.
Thanks a lot! Additional status should be enough.
Just an additional idea.
If user has written not his\her email there should be link in recipients e-mail I haven't initiated a sign up to delete account.
This feature could be useful for current behavior with activation e-mails too.
That's also a good idea, we should create a separate issue for that.
Closing and archiving repo.