U4-6878 - Feature Request V7: Add Login Events

Created by Kevin Giszewski 27 Jul 2015, 11:51:10 Updated by Jeffrey Schoemaker 10 Nov 2017, 14:52:28

Relates to: U4-6603

Relates to: U4-6736

What did you do? I'm attempting to harden the Umbraco backoffice by doing the following:

  • Limit certain users to a window of time (M-F 8-8pm) that they can login
  • Run arbitrary code on attempted, successful and failed logins

What did you expect to happen? Was hoping there were events to hook into.

What actually happened? At the moment, I have to write a custom membership (for users) provider to accomplish what I set out to do.

It would be better (possibly) for three events to fire regardless of how the authentication occurred:

  • OnLogin (attempt)
  • OnLoginSuccess
  • OnLoginFailure

Use cases:

  • If a user logs in at odd times of the day, I want to be notified. (I'll handle the business logic)
  • If a failed/successful login occurs, I'd like to run some arbitrary code.
  • On an attempted login, I want to check to see if the account is within a login window.
  • Determine if bots are probing the login page by running some custom logging.

Why not just handle this in a custom membership provider? Well I am :) But it would be nice if the provider was decoupled from this so that regardless of the provider, hardening can exist.

2 Attachments

Comments

Sebastiaan Janssen 27 Jul 2015, 12:39:50

For now you could se log4net filtering to find these events and use your own appender to do this.


Kevin Giszewski 27 Jul 2015, 12:57:31

Yep, but in some cases I want to prevent them from logging in altogether :)

This will likely need to get votes before anything moves anyway. Just figured I better start campaigning.


Jeffrey Schoemaker 27 Jul 2015, 13:00:33

But how does the log4net filtering trigger? They have to hook into some sort of event too?

+1 for this point, I would also really like events that I could hook into.

Something that I would really like to develop is that an e-mail is sent after a succesfull login ("A new login from a new IP-adress detected", see attachments). Hooking in to these events would be great


Timo 27 Jul 2015, 13:07:25

I guess you'll have to monitor the log for changes or periodically check the log entries, but this can hardly be a good solution for something like this.

An event would be very helpful because, as @kgiszewski said you can block the user from logging in altogether without building a custom membership provider.

So +1 for authentication events. Maybe even some more as OnLogout and OnPasswordUpdate might be interesting as well.


Kevin Giszewski 27 Jul 2015, 13:11:33

Good stuff guys :)


Sebastiaan Janssen 27 Jul 2015, 13:15:37

Google is your friend, don't have an example at hand currently but something like this: http://stackoverflow.com/questions/5504148/log4net-configure-to-ignore-messages-from-a-specific-class

Then you can probably send specific Umbraco.Web.Security.WebSecurity (and one other class which I can't remember now) messages to an SMTPAppender for example. Not sure if you can hook into Umbraco with appenders but I don't see why not.


Sebastiaan Janssen 27 Jul 2015, 13:18:16

(not saying we don't want to do this, just giving alternatives for now! look forward to a PR.. Authenticating, Authenticated, AuthenticationRejecting, AuthenticationRejected, AuthenticationExpiring, AuthenticationExpired, something like that?)


Kevin Giszewski 27 Jul 2015, 13:25:35

@sebastiaan The logging method is too far down the line isn't it? If I want to block someone or do something other than emailing, the login has already occurred. Not arguing with you as I can already perform these with a custom membership provider :)

I'm trying to avoid a dependency on Log4Net as well.

But yes, I think your the event names provided are in the right direction.

I'm not the sharpest when it comes to .NET events but I'll try a PR (if I get the courage). Pretty sure there's some sort of pattern with the Umbraco internals I can try to follow.


Sebastiaan Janssen 27 Jul 2015, 13:32:08

@kgiszewski Ah yes, very likely too late! Try to look at the UserService.SavingUser/SavedUser events, then you're pretty close to where you want to be.


Kevin Giszewski 27 Jul 2015, 14:57:59

Great I'll have a look +1 thx.


Shannon Deminick 26 Jun 2017, 07:13:12

Closing issue due to inactivity - see blog post for details https://umbraco.com/blog/issue-tracker-cleanup/


Jeffrey Schoemaker 26 Jun 2017, 07:34:07

I think this will be solved in 7.6.4 thanks to @sebastiaan, so close if after that release?


Jeffrey Schoemaker 10 Nov 2017, 14:52:24

This is fixed in 7.6.x and 7.7


Priority: Normal

Type: Feature (request)

State: Fixed

Assignee:

Difficulty: Normal

Category: Security

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.6.3

Due in version:

Sprint:

Story Points:

Cycle: