Page MenuHomePhabricator

Can't dismiss failed login attempt notification (or other notifications from login.wikimedia.org)
Closed, ResolvedPublic

Description

I got a failed login attempt notification today. I have a strong password and 2FA on my account, so I dismissed the notification. However, it re-appeared 2 seconds after. I have tried to dismiss it again from other projects, but nothing works.

Event Timeline

Ajraddatz created this task.Nov 4 2017, 5:17 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptNov 4 2017, 5:17 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Probably. Do either of you have Privacy Badger, AdBlock or a similar plugin enabled? If so, does (temporarily) disabling such plugins fix it?

I tried Chrome's incognito mode with adblock disabled and didn't work. There are no other plugins. And yesterday I used the Firefox 57. So it's not about the browser.

Catrope renamed this task from Failed login attempt notification won't disappear to Can't dismiss failed login attempt notification (or other notifications from login.wikimedia.org).Nov 21 2017, 7:30 PM
Kaartic added a subscriber: Kaartic.Jan 6 2018, 5:37 AM
Kaartic added a comment.EditedJan 6 2018, 5:58 AM

I experience the same issue. I stated this initially in the talk page of community tech page. The only way I could dismiss them is by going to Special:Notifications and marking them as read. I did try restarting Firefox with Add-ons disabled and the result was the same. I also tried clicking on the notification using Chromium and it had no effect too.

Stryn awarded a token.Mar 15 2018, 4:43 PM

@Stryn / @Kaartic have you only experienced this issue with login related notifications, or does it happen with other notification types as well?

Stryn added a comment.Jun 18 2018, 4:27 PM

@Stryn / @Kaartic have you only experienced this issue with login related notifications, or does it happen with other notification types as well?

My issue was not a login related notification, but "You just made your first edit; thank you, and welcome!" on https://login.wikimedia.org when I created there a common.js page for myself. Then I deleted the page, restored, but could not turn off the notification. After 6 months I restored the page (https://login.wikimedia.org/w/index.php?title=Special%3ALog&type=delete&user=Stryn&page=&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_tag_log=1) and marked the notification as read and finally it was gone. So I don't have this problem anymore.

@Stryn / @Kaartic have you only experienced this issue with login related notifications, or does it happen with other notification types as well?

My issue was with failed login notifications. Clicking on the notification takes me to https://www.mediawiki.org/wiki/Help:Login_notifications but doesn't mark the notification as read despite the presence of the ?markasread= parameter. For the time being I'm able to dismiss them by clicking on the blue dot that appears near the notification, though.

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 20 2018, 5:12 PM
Restricted Application added a project: Community-Tech. · View Herald TranscriptJul 20 2018, 10:07 PM

Thanks for your comments @Stryn and @Kaartic, they helped me understand what's going on here.

The link on a failed login notification sends you to mediawiki.org, but the notification came from login.wikimedia.org. The markasread parameter doesn't work because the notification ID in it refers to a notification on loginwiki, but mediawikiwiki looks it up in its own database and finds nothing (or finds an unrelated notification, but it most likely belongs to a different user so it'll refuse to change it). You don't notice this effect for most notifications, because almost all notifications link to a page on the same wiki.

In order to fix this, we either have to change this link to go to loginwiki (then it'll just work), or put the wiki name in the markasread parameter and have Echo proxy a markasread request back to the originating wiki. A side benefit of doing this would be that we can use the same proxy functionality for the regular mark as read button (the blue circle), which would prevent plugins like Privacy Badger and AdBlock from breaking cross-wiki mark-as-read (see T121930: Cross-wiki mark as read doesn't work). See also T132084#2779920 for the last time we discussed this issue.

Thanks for your comments @Stryn and @Kaartic, they helped me understand what's going on here.
The link on a failed login notification sends you to mediawiki.org, but the notification came from login.wikimedia.org. The markasread parameter doesn't work because the notification ID in it refers to a notification on loginwiki, but mediawikiwiki looks it up in its own database and finds nothing (or finds an unrelated notification, but it most likely belongs to a different user so it'll refuse to change it). You don't notice this effect for most notifications, because almost all notifications link to a page on the same wiki.

So there is an unspoken rule that the notification should originate from and link to the same wikis? We should enforce this in the code, if possible.

In order to fix this, we either have to change this link to go to loginwiki (then it'll just work), or put the wiki name in the markasread parameter and have Echo proxy a markasread request back to the originating wiki. A side benefit of doing this would be that we can use the same proxy functionality for the regular mark as read button (the blue circle), which would prevent plugins like Privacy Badger and AdBlock from breaking cross-wiki mark-as-read (see T121930: Cross-wiki mark as read doesn't work). See also T132084#2779920 for the last time we discussed this issue.

We discussed the idea of sending users to loginwiki but it didn't work out because several people were against directly users to that wiki (obscure, used for technical purposes only etc).

FYI, we got two more reports about this happening today: https://www.mediawiki.org/wiki/Topic:Ujerw9yjfnmcocyo

We are considering this for Growth team maintenance work. @Catrope will discuss with @Niharika.

So there is an unspoken rule that the notification should originate from and link to the same wikis? We should enforce this in the code, if possible.

Or at least document what will happen if you try this. And maybe detect what's happening and not add the markasread parameter.

However, I'd prefer to just make this work, as outlined in my previous comment. We are about to have some time to do maintenance work while we figure out what product work to do next, so I have put this task on the short list of tasks to do during that time.

We discussed the idea of sending users to loginwiki but it didn't work out because several people were against directly users to that wiki (obscure, used for technical purposes only etc).

Yeah, that makes sense, and it also makes sense that the notification originates from loginwiki. Cross-wiki notifications should really support cross-wiki link targets though, so it's not really your fault, it's ours :)

Change 457681 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] Make markasread parameter work cross-wiki

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

Change 457681 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Make markasread parameter work cross-wiki

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

Etonkovidova closed this task as Resolved.Sep 6 2018, 4:17 AM
Etonkovidova added subscribers: Etonkovidova, SBisson.

The fix does not apply retroactively to old notifications.

The fix does not apply retroactively to old notifications.

Wait a minute... I think it should. @Catrope ?

The fix does not apply retroactively to old notifications.

Wait a minute... I think it should. @Catrope ?

Yes, it should. A notification that was generated before this change should now get dismissed when clicked. This particular bug might not be testable in beta labs though, because en.wikipedia.beta.wmflabs.org and mediawiki.org are not in the same wiki family.