Description

What config settings should we use for the LoginNotify extension in production?

The wishlist proposal only mentions notifications for unsuccessful login attempts, but LoginNotify can also provide notifications for successful login attempts from unrecognized computers. Is this useful or likely to just confuse people?

I know I'm not the brightest juicebox in the fridge, but when I searched the repo the only wgLoginNotify variables I see are $wgLoginNotifyEnableOnSuccess and $wgLoginNotifyEnableForPriv. Where are the other variables being used?

LoginNotifyCheckKnownIPs is whether to trigger a notification at all after failed logins from known IPs. We'll want this to be true.

LoginNotifyMaxCookieRecords refers to the number of users that are tracked as having logged in on a particular device. We can't store every user login forever (e.g. shared computers at libraries), so there is both a TTL and a max number of records to keep track of on a particular device. That is my understanding after looking at the code. I'm not sure what a good setting would be, but 6 users seems like a sensible default, with 6 months as the TTL.

I know this has been signed off on, but I'd like to point out that 10 ($wgLoginNotifyAttemptsKnownIP) is an absurdly high number for someone to mess up their password that many times before it being reported. You need to fill a captcha after the 3rd/4th try so the chances of 10 password misses is very slim,

Aside this makes testing a real pain because you have to fill out a captcha every time after the 3rd try and you're blocked from attempting to login after the 6th/7th try and need to wait 5 minutes before trying again.

Also, interestingly, I did just test this out in the current state and made ~15 failed login attempts but it did not give any alerts when I did actually login. I'm wondering if somehow the "count" of failed login attempts is lost when the person is blocked from attempting to login for 5 minutes after too many failed attempts.
There could be a couple more reasons for it though. I'm looking.

I don't really understand what LoginNotifyEnableForPriv does. Whether it's set to false or an array of rights doesn't seem to make any difference. The notifications still work for all users. @Bawolff: Could you shed some light here?

@MusikAnimal: If there's no response from Bawolff, can you dig into the code and see what it's supposed to do?

I don't really understand what LoginNotifyEnableForPriv does. Whether it's set to false or an array of rights doesn't seem to make any difference. The notifications still work for all users.

I looks like it allows you set different defaults for users with certain rights, see onUserLoadOptions. I think this is configured using a combination of getOverridenOptions and these options in extension.json. So all you're doing is setting a default that echo and/or email for "Failed login attempts" or "Login from new computer" are turned on at all, not other options like AttemptsKnownIP, etc. Maybe we'll want to set the email options to true for users with admin-like permissions?

So with two fresh new accounts, one an admin (has userrights permission), and another a non-admin account, the difference I see is that "Login from new computer" is defaulted on for the admin. It seems then that the feature works, whereby any options placed here are automatically treated as being true for the configured "privileged" users. This apparently means the defaults for privileged users are not configurable.

Before we update the documentation, I think we should first answer this question. I do like that admins by default get the "Someone has successfully logged into your account from a computer which you have not edited from recently" notification, but this is not without caveats and "icky" and "hacky" code. Maybe it's not worth it, or we should refactor this to make it not-so-hacky. I will write about these findings at T162750 too.

Yeah, the idea for that setting is that high priv users should in theory default enabled since their account security can affect other users, but we shouldnt auto-annoy normal users who dont matter unless they opt in

"wgLoginNotifyAttemptsNewIP" has now been set to 1 in Labs and it solves all of the issues surrounding number mismatch between icon and attempts and bundling works very nicely with it.

"wgLoginNotifyAttemptsKnownIP" is still at 10, which seems like a safe limit. There will be a mismatch between the number showing up on the icon and the number of bundles and attempts if someone does try 10 times but it's pretty hard to reach that count, given that the captcha kicks in after 3 attempts and you're blocked from attempting to login for 5 minutes after 5 attempts. I'm gonna try to replicate this and come up with a screenshot.