Error management when editing profile

[aiscrim]

When something wrong happens in the ManageController/Index action (e.g. the user changes the email address but it's already in use by another user) an exception is thrown, resulting in a 500 response. Moreover, the details of the error are not clear enough, even locally: in the 'email address already in use' example above, all I get is:

ApplicationException: Unexpected error occurred setting email for user with ID ...

And nothing goes to the logs, so there's no way of understanding what's the problem apart from debugging it in VS.

For me it's quite urgent to solve this issue, so if you are busy I can fix it myself and open a PR, just let me know.

[skoruba]

Please, open a PR if you can, because I am currently busy. Do you try to setup email which is used for another user? I'll be happy for any fix/details on this. 😊 Thanks!

[skoruba]

I think this line is your issue: https://github.com/skoruba/IdentityServer4.Admin/blob/master/src/Skoruba.IdentityServer4.STS.Identity/Controllers/ManageController.cs#L80 Please, check the result in this line. Thanks.

[aiscrim]

Yes, exactly, and as you see when that call fails an exception is thrown. Instead I think it will be better to return a user-friendly message. I'll do it!

[skoruba]

You are right, in this case will be better to have some nice message. :) Thanks @aiscrim

[aiscrim]

Working on the fix I discovered a few other related flaws in the ManageController:

• Here, the way StatusMessage is classified as success or danger is wrong: not all the errors start with the word "Error" (actually, most of the errors start with "Unexpected error..." and they would be classified as success), and anyway in languages other than English that would never work. I suggest replacing the string StatusMessage with an object (bool IsSuccess + string Message).
• TwoFactorAuthenticationViewModel is missing the StatusMessage field, so even if the message is set in the calling action, it never gets displayed.
• Some messages contain the user id, so they seem to be intended more for the log than for the UI, but they are displayed as StatusMessage. The pattern used for the PasswordChanged/PasswordChangedLog messages should be used everywhere imho.

If you agree I can fix the first two issues in the same PR. The last one is a bit trickier for me to solve because it involves creating new localized strings in all the supported languages, so I'd just ignore it atm.