Issue: Re-opening Accounts & IsLoginAllowed

[woodwardmatt]

Pre-requisites: Two pre-requisites:

• MR is configured to allow login without verification (as I want users to be able to jump straight into the system after registration and defer verification until they have decided they want to continue using the application).

• The closure and re-opening of accounts uses a manual SetIsLoginAllowed method call to prevent / allow access whilst an account is temporarily closed. Examples:

        //Close Account
        userAccountService.CloseAccount(ID);
        userAccountService.SetIsLoginAllowed(ID, false);
  
        //Reopen Account
        userAccountService.ReopenAccount(account);
        userAccountService.SetIsLoginAllowed(account.ID, true);

Scenario: User A creates a local account, and verifies it. Later User A decides to Close the account (not delete it). A while later (malicious) User B tries to reopen User A's account by supplying User A's email address (assumption here is that is somehow known to User B). User A receives a, "Account Reopened" email from MR and immediately tries to cancel the request.

Issues: The ReopenAccount routine (quite rightly) requests that the user re-verifies their email account. However on cancelling the request (to verify the email address) MR has no ability to denote that the request was not just a simple email verification, but a more broadly part of a Reopen Account routine. Thus whilst manually controlling the IsLoginAllowed property of an account, and under this situation the account is left with Login access enabled even though the user has cancelled the request.

Resolution(s): The only way I can think of a way around this is either:

• Don't allow access prior to verification, and let that approach control login access (not the option I want given the need to get users into the system quickly and not add too many hurdles).
• Differentiate the verification request so that the type can be denoted as part of a ReopenAccount routine E.g. VerificationKeyPurpose.ReopenAccount This request type would ultimately be used to provision for verifying email address (as per account initiation) and either controlling the IsLoginAllowed property of the account, or raising an event (incl. a reference to the key purpose) that as a developer we could use to undertake any post CancelVerification processing i.e. setting the IsLoginAllowed if we so choose.

Keen to get some thoughts on this. It's very much an alternative use case, but still very much part of the overall logic of the MR framework & End User Experience.

References: This issue follows on from a prior closed issue #475 and may help to clarify the context of this issue.

[brockallen]

Really sorry for letting these issues get so old without attention.

Yes, I see. I think you have a really good point but to be honest you're more in the middle of it than I am (meaning I think you've got a better idea on perhaps a solution than I would). Perhaps we do need more verification purpose flags.

Do you have a workaround, or are you looking to get a fix into MR? If so, then I'd suggest first building several unit tests to illustrate the broken workflows and then we can fix them one by one. Would you be interesting in forking and then working on a PR?

[woodwardmatt]

Hey @brockallen No drama, I know what its like :)

I've moved on a little with my work since this issue, but i'll revisit this in a few days and see if I can come up with something for you.

Equally, I may be a little slow, but I will do my best :)