Page MenuHomePhabricator

RawAction not setting block cookies
Open, LowPublic2 Estimated Story PointsBUG REPORT

Description

What is the problem?

For logged in users with autoblocks against their users, we are no longer setting block cookies on RawAction (action=raw).

...For ActionRaw it looks like it sets its own headers rather than using OutputPage...

The change was introduced in T233594.

Steps to reproduce problem

On wikis with $wgCookieSetOnAutoblock set to true (should be on most production and beta wikis).

  1. Create an autoblock against $user (i.e. in Special:Block check the option "Automatically block the last IP address used by this user...")
  2. Login as $user
  3. For an existing article $foo, navigate to $foo?action=raw

Expected behavior: A cookie called something like enwikiBlockID is set
Observed behavior: The block cookie is not set

Environment

https://en.wikipedia.beta.wmflabs.org MediaWiki 1.35.0-alpha (25a0c83) 09:08, 9 October 2019

Event Timeline

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptOct 9 2019, 10:39 AM
Niharika triaged this task as Low priority.Oct 17 2019, 6:11 PM
Niharika set the point value for this task to 2.
dbarratt claimed this task.Oct 28 2019, 5:50 PM
dbarratt moved this task from Ready to In Progress on the Anti-Harassment (The Letter Song) board.

Note that RawAction is not a blockable action (requiresUnblock returns false).

@Niharika Solving the child task for this appears to depend on a conversation with @Krinkle about the role of OutputPage. I wonder how important it is to resolve these things now, if the main motivation is to solve this task?

Note that RawAction is not a blockable action (requiresUnblock returns false).

Many of the actions that set the cookie are not blockable, the question should be if the request is cachable or not. If it is always cached, then this task is pointless, but I don't think that is the case....

@Niharika Solving the child task for this appears to depend on a conversation with @Krinkle about the role of OutputPage. I wonder how important it is to resolve these things now, if the main motivation is to solve this task?

What conversation?

@dbarratt I wouldn't say that this task is pointless - just agreeing with @Niharika's comment about only fixing it if it's a trivial amount of work for that reason (T233594#5558160).

What conversation?

Referring to this comment about the role of OutputPage.

@Tchanders @dbarratt Let's drop this task then. Any objections?

dbarratt removed dbarratt as the assignee of this task.Nov 7 2019, 7:58 PM

Indeed. action=raw is an internal endpoint, effectively similar to load.php and thumb.php. Not something one would navigate to directly in a browser. Any (regular) use of it would already be within a few seconds of an HTML page view which we handle already. And on its own action=raw also isn't abusable or interesting to monitor I imagine, from your product's perspective.

+1 for keeping it separate from the cookie path.