Page MenuHomePhabricator

Add block cookie for browser-based API edits (including VisualEditor & MobileFrontend)
Open, NormalPublic5 Story Points

Description

Block cookies are only added on page load. As many communities use the VisualEditor as the default editor for logged-out users, the block cookie should be added on all users, regardless of editor they use.


Current behavior

When users edit with the desktop source editor, the block cookie drops:

However, they are not dropped with tools that make edits via API, such as the VisualEditor or mobile web editor:

No block cookieStill no block cookie when VE opens and "you are blocked" message appearsNo block cookie when edit is rejected
No cookie when mobile web "you are blocked" message displays

Acceptance criteria

  • Users should receive a block cookie when they attempt to edit with the VisualEditor — when the editor loads and displays the "you are blocked" message
  • Users should receive a block cookie when they attempt to edit with the mobile web editor — when the editor loads
  • The block cookie logic should behave the same it does in T152462 and T5233

Notes

  • We can break these up into as many investigation + implementation tasks as needed.
  • Can we piggy-back off the "you are blocked" notice tracking we implemented in T189724 ?

Event Timeline

TBolliger created this task.Jun 6 2018, 6:19 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.
dbarratt renamed this task from Drop block cookie for API edits (including VisualEditor) to Add block cookie for browser-based API edits (including VisualEditor & MobileFrontend).Jun 6 2018, 6:24 PM
dbarratt updated the task description. (Show Details)
Vvjjkkii renamed this task from Add block cookie for browser-based API edits (including VisualEditor & MobileFrontend) to wibaaaaaaa.Jul 1 2018, 1:05 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Ankry renamed this task from wibaaaaaaa to Add block cookie for browser-based API edits (including VisualEditor & MobileFrontend).Jul 2 2018, 10:15 AM
Ankry raised the priority of this task from High to Needs Triage.
Ankry updated the task description. (Show Details)

I tested this again today. The description is still correct. If an IP is hardblocked and if a user attempts to edit via VisualEditor (e.g. the wiki is configured to allow for IP editors to use VisualEditor or the user's preference is set to VE) the block cookie is not set:

No block cookieStill no block cookie when VE opens and "you are blocked" message appearsNo block cookie when edit is rejected

The block cookie does appear on the source editor:

TBolliger updated the task description. (Show Details)Feb 20 2019, 10:03 PM
TBolliger updated the task description. (Show Details)
TBolliger updated the task description. (Show Details)

@dmaza & @Tchanders we should probably just set the cookie when the API request is made from the browser... do you see any problems with doing it that way?

Also doesn't drop a cookie on mobile web:

TBolliger updated the task description. (Show Details)Feb 20 2019, 10:09 PM
TBolliger set the point value for this task to 5.Feb 21 2019, 7:51 PM
TBolliger updated the task description. (Show Details)

Good to know! We should double-check, but it appears this may be a duplicate task.

Niharika triaged this task as Normal priority.Jul 16 2019, 5:14 PM
dbarratt moved this task from Ready to In Progress on the Anti-Harassment (The Letter Song) board.

Change 528596 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Add block cookie for API edits

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

Core Platform Team Would be nice to get a code review of this from your team. :)

Change 528893 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/extensions/VisualEditor@master] Set block cookie when blocked user makes an API request

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

FYI We discussed a possible different direction for this, I'll submit a patch for discussion.

Change 529824 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Track all requests that load the block with a block cookie

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

Change 529824 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Track all requests that load the block with a block cookie
https://gerrit.wikimedia.org/r/529824

This is an alternative way to go about this, that is more aggressive, but prevents extensions from being responsible for cookie blocking.

mobrovac added subscribers: Anomie, mobrovac.

Change 529824 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Track all requests that load the block with a block cookie
https://gerrit.wikimedia.org/r/529824

This is an alternative way to go about this, that is more aggressive, but prevents extensions from being responsible for cookie blocking.

This is indeed more aggressive, but given @Anomie's fix in Gerrit 491300 for T216245: VisualEditor, MobileFrontend, and other tools using action=edit do not auto-block IP addresses (which covers ApiEdit) all is left to do here really is to make VE aware of it, if I'm not mistaken. To that end, Gerrit 528893 LGTM.

This is indeed more aggressive, but given @Anomie's fix in Gerrit 491300 for T216245: VisualEditor, MobileFrontend, and other tools using action=edit do not auto-block IP addresses (which covers ApiEdit) all is left to do here really is to make VE aware of it, if I'm not mistaken. To that end, Gerrit 528893 LGTM.

I'm confused, how do autoblocks relate to this task? I think maybe they suffer from the same "spreading" problem as cookie blocks (and perhaps should also have a more aggressive solution)

mobrovac added subscribers: tstarling, daniel.

This is indeed more aggressive, but given @Anomie's fix in Gerrit 491300 for T216245: VisualEditor, MobileFrontend, and other tools using action=edit do not auto-block IP addresses (which covers ApiEdit) all is left to do here really is to make VE aware of it, if I'm not mistaken. To that end, Gerrit 528893 LGTM.

I'm confused, how do autoblocks relate to this task? I think maybe they suffer from the same "spreading" problem as cookie blocks (and perhaps should also have a more aggressive solution)

You are correct, I confused the two.

We need more eyes on this. @tstarling @daniel could you take a look at Gerrit 529824 ?