Page MenuHomeMiraheze

Requesting wikis ignores if user is blocked.
Closed, InvalidPublic

Description

If a user is blocked it will still allow them to interact with requests. Sorry if this isn’t a security ticket, just didn’t want this to be public knowledge

Event Timeline

@Zppix you mean comment on requests or also create new ones?

@Zppix you mean comment on requests or also create new ones?

It seems interact in general.

RhinosF1 added subscribers: Unknown Object (User), John.Mar 25 2022, 15:09

It doesn't seem to have any check for blocks.

@John, @Universal_Omega: is this intended or?

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

Unknown Object (User) added a comment.Mar 25 2022, 16:00
In T8990#181904, @John wrote:

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

I think we should have it check for global blocks only, not local meta blocks I guess, if it doesn't?

In T8990#181904, @John wrote:

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

I think we should have it check for global blocks only, not local meta blocks I guess, if it doesn't?

If you are globally blocked (from your IP), you can't create an account. If you don't have an account, you can't request a wiki.

Unknown Object (User) added a comment.Mar 25 2022, 16:02
In T8990#181904, @John wrote:

@John, @Universal_Omega: is this intended or?

It was removed in early 2018 with a rewrite as we didn’t want meta blocks to influence someone’s ability to request wikis or engage in wiki requests.

I think we should have it check for global blocks only, not local meta blocks I guess, if it doesn't?

If you are globally blocked (from your IP), you can't create an account. If you don't have an account, you can't request a wiki.

Unless you already have an account?

I'm far less worried about that. It's never caused an issue and it's fairly easy to lock an account. We block 1000s of proxies and can easily block more to reduce the risk of people being able to just change IP.

Slightly different issue (I'd raise it elsewhere but I have a meeting I need to get to), but it appears that restricting view access to require "delete" permissions does not work, only restricting access to "createwiki" (I have not checked os).

EDIT: Actually, it seems that sometimes setting the visibility just does not work for some reason.

Reception123 lowered the priority of this task from High to Normal.Mar 26 2022, 08:07

Lowering priority since this has been the case since 2018 apparently with no issue so I don't see why 4 years later it would be high.

Lowering priority since this has been the case since 2018 apparently with no issue so I don't see why 4 years later it would be high.

When you create the task it gets assigned that for some reason.

In T8990#182067, @Zppix wrote:

Lowering priority since this has been the case since 2018 apparently with no issue so I don't see why 4 years later it would be high.

When you create the task it gets assigned that for some reason.

Yeah, because it's a security task

I'm proposing that since no one figured this out until now, a solution that wouldn't require extension changes (which I feel aren't necessary since there's been no occurrences of abuse) is to use wgRevokePermissions. As to not give anything away before being merged, I will merge the PR immediately after CI checks.

If we see a large occurrence of the new 'requestwikiblocked' right being used, we can instead create a task to implement something with Special:Block

Reception123 changed the visibility from "Custom Policy" to "Public (No Login Required)".
Reception123 changed the edit policy from "Custom Policy" to "All Users".
Reception123 removed a project: Security.
Dmehus changed the task status from Resolved to Invalid.EditedApr 2 2022, 23:15
Dmehus subscribed.

@Reception123 Your commit is fine and can stay, as it's potentially useful for Stewards and the Trust and Safety team to have in their toolkit, but I wanted to test this to be sure I could replicate this and, indeed, can confirm that I cannot replicate this. I have tested a sitewide block, without autoblock enabled, and a second sitewide block, with autoblock enabled, and can indeed confirm that sitewide blocked users cannot access the Special:RequestWiki special page to request a wiki. I can attach screenshots.

Test block with autoblock disabled

2022-04-02 15_49_46-Window_test_block_with_autoblock_disabled.png (661×1 px, 88 KB)

Test block with autoblock enabled

2022-04-02 15_58_36-Window_test_block_with_autoblock_enabled.png (655×1 px, 93 KB)