check for more user account events

[brockallen]

prolly more types of user account events that can be raised

[talves]

Would be great to be able to flip a switch to let the admin email know that a user event happened. Maybe the fact that there is an email for admin notify or something like that. Have not thought it all the way through, but I may have some ideas soon.

[brockallen]

I'd love to get feedback in the next few days if possible -- i want to get out an update ASAP. Thx.

[brockallen]

I added several new user account events such as

• claims added/removed
• mobile phone added/removed
• linked accounts added/removed
• certificates added/removed
• two factor auth enabled/disabled

i'll close this now, but if you have any others please re-open and provide suggestions.

[talves]

Ok, here is a short list of the items mentioned above. Just thoughts, so nothing concrete:

• I was thinking I could hook into a tool like elmah, so there would first and foremost need to be an event for logging to be able to log (not spent enough time to see if it's already supplied)
• User events turned on for Admin level only, so allow for Admin to track what to receive on the event bus. ie (notifications of logged in failed attempts, failed validation attempts, general errors, etc)

I can extend this great assembly, but these were the gist (no pun intended) of my ideas.

[brockallen]

ok, good ideas.

for hooking into external tools for logging/auditing then it's simple -- it just involves building an IEventHandler<T> for the various events from the UserAccount you care about. so to build that hook into something like elmah would be fine, but i see it as external to the core project. it would be very simple as it's own library -- an addon to MR (deployed via nuget).

as for admin filtering of the events, i guess your event handler would log everything and then only display it to the admin. unless i'm missing something... the way the event bus works is that as a user account is in-memory and being "worked" it collects these events. so the opportunity to persist them is only for the event handler in a short time. nothing built-into MR persists them. again, i was designing this as an extensibility point so different apps could make their own determination what (and how) to store the event info. I feel like i'm missing what you're looking for, though.

[talves]

No, you got it. Wanted to make sure I was not going down the wrong path. Exactly how I would proceed on my own. Happy to see we are on the same page. Nothing needed then on these items.

[brockallen]

ok, cool. i'll be excited to see what extensions you come up with :)