Page MenuHomePhabricator

[Spike 8 hours] Successful login notification gets sent out even when disabled in preferences
Closed, ResolvedPublic5 Story Points

Description

This is not a very reproducible bug. The user gets an Echo notification about a successful login to their account sometimes. So far the only thing I know is that this happens for fairly new accounts and the notification gets issues just once and never again.

Steps I used to reproduce this on my machine (roughly):

  1. Create a new account (on your local install)
  2. Login
  3. If you don't see the notification yet, log out and log in using some other browser
  4. Refresh a few times, do few more logouts/logins until you see the notification

Expected behavior: No web notifications for logins ever. The preference is disabled.

For the spike: Figure out why this happens and how to fix it.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Niharika added a comment.EditedSep 3 2017, 2:37 AM

@IKhitron By definition, if the system does something that it shouldn't be doing, it is a bug. You may consider it unlikely, or even that the reporter was wrong. But if we admit that it happened, well, how else would you categorize it? :)

A miracle, of course.
Could you, please make the same screenshot from special:notifications, but using uselang=en this time? Thank you.

I filed the ticket, @IKhitron. It's a known bug and we're working on fixing it. Here's the screenshot with English version:

Did Echo extension invented a new mediawiki message text especially for you.

I don't think you intended it but sometimes you come across as sounding overly sarcastic and not in a good faith. Can we keep that under check? Thank you. :)

Did Echo extension invented a new mediawiki message text especially for you.
I don't think you intended it but sometimes you come across as sounding overly sarcastic and not in a good faith. Can we keep that under check? Thank you. :)

Hi, @Niharika. It REALLY wasn't sarcastic. I asked exactly was I thought - I do not think that mediawiki engine is AI and can create a behaveour itbdoes not intended. I think you also would be surprised, if you get a mail from mediawiki that some article wasn't updated for a year, and it knows that the article issue was in the news lately. I have very poor English, maybe it was the cause of your misunstanding, but I really wasn't sarcastic.

@MaxSem To jog your memory...

mysql:wikiadmin@10.64.16.18 [enwiki]> select count(*) from echo_event where event_type='login-success';
 +----------+
| count(*) |
+----------+
 |    30851 |
+----------+
1 row in set (0.02 sec)

and...

mysql:wikiadmin@db1080 [enwiki]> select distinct up_value from user_properties where up_property='echo-subscriptions-web-login-success';
+------------+
| up_value   | 
+------------+ 
| fake-false |
+------------+ 
1 row in set (0.01 sec)
Aklapper renamed this task from Succesful login notification gets sent out sometimes to Successful login notification gets sent out sometimes.Sep 9 2017, 12:51 PM

Change 379837 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/LoginNotify@master] WIP: remove all the artificial messing with preferences

https://gerrit.wikimedia.org/r/379837

TheDJ added a subscriber: TheDJ.Oct 2 2017, 2:47 PM

Change 379837 merged by jenkins-bot:
[mediawiki/extensions/LoginNotify@master] Remove support for per-group preference defaults

https://gerrit.wikimedia.org/r/379837

I just received this ghost notification a second time. This time with &uselang=en version:

I just received this ghost notification a second time. This time with &uselang=en version:

Thanks for that, Platonides. I believe @MaxSem is still working on this. The weird formatting with the icon and "Change password" string - is that because of some user script?

No problem. I was just reporting that the assumption that it was issued just once and never again turned out to be false.

I hadn't noticed the formatting difference before you mentioned it. I am not aware on any user script which does that. It is also happening on the native language:

This link only appears on the wiki where it happened, not when showing from a foreign wiki, but I had another alert on Wikimedia Commons, and there too it shows misplaced. Other notifications seem to suffer the same problem.

No problem. I was just reporting that the assumption that it was issued just once and never again turned out to be false.

Thanks for that.

I hadn't noticed the formatting difference before you mentioned it. I am not aware on any user script which does that. It is also happening on the native language:


This link only appears on the wiki where it happened, not when showing from a foreign wiki, but I had another alert on Wikimedia Commons, and there too it shows misplaced. Other notifications seem to suffer the same problem.

They are not misplaced for me. Maybe you want to try with ?safemode=1 in the URL and see if that fixes it. If so, it's probably a user script (global perhaps). If not, you should file a ticket with the Echo notifications project.

Now that the LoginNotify extension code has been updated, we need to run the migratePreferences.php maintenance script.

Now that the LoginNotify extension code has been updated, we need to run the migratePreferences.php maintenance script.

I believe this has been run now, correct?

@MaxSem — Please update (close?) this ticket as appropriate.

MaxSem closed this task as Invalid.Feb 12 2018, 9:37 PM

Despite claims that it's easily reproduceable, it's not.

I'm not sure if this is the correct place to report this, but this bug is now happening to me. Every time I've logged in to Wikipedia (English) in the last few days (August 2018), I get the notification saying that someone has logged into my account from a new device. I'm logging in from the same device I have been logging in with for nearly 2 years. Also "Preferences-->Notifications-->login from unfamiliar device" boxes are unchecked, and the web box is greyed out and uncheckable. Is there a way to stop these false positives?

Niharika reopened this task as Open.Aug 20 2018, 5:13 PM
Niharika moved this task from Archive to To be estimated/discussed on the Community-Tech board.

I'm not sure if this is the correct place to report this, but this bug is now happening to me. Every time I've logged in to Wikipedia (English) in the last few days (August 2018), I get the notification saying that someone has logged into my account from a new device. I'm logging in from the same device I have been logging in with for nearly 2 years. Also "Preferences-->Notifications-->login from unfamiliar device" boxes are unchecked, and the web box is greyed out and uncheckable. Is there a way to stop these false positives?

Thanks for reporting this, @Wikimedes. We'll look into it.

Niharika renamed this task from Successful login notification gets sent out sometimes to [Spike 8 hours ] Successful login notification gets sent out sometimes.Aug 21 2018, 11:55 PM
Niharika renamed this task from [Spike 8 hours ] Successful login notification gets sent out sometimes to [Spike 8 hours] Successful login notification gets sent out sometimes.
Niharika removed MaxSem as the assignee of this task.
Niharika added a project: Spike.
Niharika removed the point value for this task.
Niharika moved this task from To be estimated/discussed to Estimated on the Community-Tech board.
MaxSem added a comment.Sep 4 2018, 6:48 PM

We can't tell what's going on from production logs: because Logstash now doesn't log debug level and lower, we only get "Sending a login-success notification to Wikimedes" (info level) but not messages with details (debug). @Wikimedes, why do you log in so often? Do you clear cookies every day? Is your IP highly dynamic?

I probably log in less than once per day, is that more often than usual?
Cookies are cleared automatically when I close my browser.
My internet connection is through a Verizon Jetpack, and almost always from home, so I don't think my IP address is dynamic, but I really don't know.

MaxSem closed this task as Resolved.Sep 4 2018, 7:04 PM
MaxSem claimed this task.
MaxSem moved this task from Ready to Q1 2018-19 on the Community-Tech-Sprint board.

Cookies are cleared automatically when I close my browser.

My internet connection is through a Verizon Jetpack, and almost always from home, so I don't think my IP address is dynamic, but I really don't know.

Found it in a different log - the IP is extremely dynamic indeed. Thus, if you never keep the cookies from the previous login around, the system has no way to know it's you and sending you these notices is the expected behavior.

I have "Preferences-->Notifications-->login from unfamiliar device" unchecked, so why are notifications being sent to me?

That sounds like a different (but legit) bug.

Niharika reopened this task as Open.EditedSep 4 2018, 8:11 PM

@Wikimedes described the bug correctly and that's what this ticket is about.

That notification should never be sent out because the very checkbox is disabled by the extension itself. For successful logins, only emails should be sent out.

One possible reason this could be happening is because of GlobalPrefs meddling with it. GlobalPrefs overrides the matrix and when a local override is created the checkbox is no longer disabled.

Niharika updated the task description. (Show Details)Sep 4 2018, 8:18 PM
Framawiki removed MaxSem as the assignee of this task.Sep 4 2018, 8:22 PM
Niharika assigned this task to MaxSem.Sep 4 2018, 8:22 PM
Niharika updated the task description. (Show Details)
Niharika removed MaxSem as the assignee of this task.Sep 4 2018, 9:04 PM
Cirdan added a subscriber: Cirdan.Sep 8 2018, 4:39 PM

This also came up on the German-language Wikipedia's village pump recently (permalink). The community there would appreciate if the issue could be resolved soon, one user reported that they received a total of 14 notifications at once.

kaldari renamed this task from [Spike 8 hours] Successful login notification gets sent out sometimes to [Spike 8 hours] Successful login notification gets sent out even when disabled in preferences.Sep 9 2018, 2:42 AM
aezell added a subscriber: aezell.Sep 10 2018, 4:24 PM

It seems like we have two issues that are being combined here:

  1. Login notifications are sent when preferences indicate that they should not be.
  2. Multiple, duplicate login notifications are sent when the user should only get one or zero.

Am I accurately summarizing this?

These bugs are obviously related in some sense but it might not be the same code to fix each of them.

It seems like we have two issues that are being combined here:

  1. Login notifications are sent when preferences indicate that they should not be.
  2. Multiple, duplicate login notifications are sent when the user should only get one or zero.

Am I accurately summarizing this?
These bugs are obviously related in some sense but it might not be the same code to fix each of them.

It's the same thing. Essentially, the code should not allow for a login notification to be sent out at any point in time. The preference is explicitly disabled so users cannot enable it.
There's a bug which does allow login notifications to go through. We need to find and close that path to trigger the notification in the code.

So, default values for options in production, as returned by User::getOptions():

"echo-subscriptions-web-login-success" => true,
"echo-subscriptions-email-login-success" => false,

Same reproduces for various accounts like @Wikimedes and me. It has nothing to do with GlobalPreferences (behaves the same way on non-global wikis) - however, if you override them the values suddenly start making sense.

For the reference, LoginNotify defines the following default preference values:

	"DefaultUserOptions": {
		. . .
		"echo-subscriptions-web-login-success": false,
		"echo-subscriptions-email-login-success": true
	},

I don't know how to investigate this further, would appreciate if someone familiar with Echo looked at this.

Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 10 2018, 10:16 PM
SBisson moved this task from Inbox to External on the Growth-Team board.Sep 12 2018, 7:00 PM
Niharika raised the priority of this task from Normal to High.Sep 18 2018, 3:18 PM

Another instance reported here.

MaxSem claimed this task.Sep 20 2018, 10:28 PM
MaxSem moved this task from Ready to In Development on the Community-Tech-Sprint board.

Change 461832 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/Echo@master] Don't override checkmatrix defaults set elsewhere

https://gerrit.wikimedia.org/r/461832

@MaxSem As this is no longer a spike apparently, could you put some points on it?

Change 461832 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Don't override checkmatrix defaults set elsewhere

https://gerrit.wikimedia.org/r/461832

@MaxSem I realize this is merged already but it would be good to put a point value on the work that you did.

MaxSem set the point value for this task to 5.Sep 25 2018, 9:03 PM
aezell added a comment.Oct 4 2018, 5:40 PM

Since this is reviewed and merged, should it move to Product Review or maybe Done?

Since this is reviewed and merged, should it move to Product Review or maybe Done?

It's supposed to be deployed today according to the train. I will try to test it then and let the users know that we have fixed this issue.

Niharika closed this task as Resolved.Oct 12 2018, 11:08 PM
Niharika moved this task from QA to Q2 2018-19 on the Community-Tech-Sprint board.

Doesn't seem to be happening anymore.

I found this task and its fix in the context of T220762: [betalabs] Stuck cross-wiki notification , and I have a theory for why this was so hard to reproduce: the default value of the preference was forced to true by the Echo code Max removed, but on the preferences form the checkbox for the preference was rendered as unchecked (and disabled). So if a user then submits the preferences form, the preference becomes disabled. This suggests that the bug would only have happened for users who had never changed/saved their preferences (or on wikis where they had never changed/saved their preferences).