openstreetmap-website
openstreetmap-website copied to clipboard
openstreetmap
Blocked user cannot log on to community.osm.org
Following up on https://community.openstreetmap.org/t/my-user-is-blocked/1006/11
Once a user has been blocked, they can no longer log on to community.osm.org, because fetching user details using /api/0.6/user/details is being rejected by HTTP 403 "Your access to the API has been blocked. Please log-in to the web interface to find out more.”
app/controllers/api_controller.rb seems to be the relevant bit in the website code:
# have we identified the user?
if current_user
# check if the user has been banned
user_block = current_user.blocks.active.take
unless user_block.nil?
set_locale
if user_block.zero_hour?
report_error t("application.setup_user_auth.blocked_zero_hour"), :forbidden
else
report_error t("application.setup_user_auth.blocked"), :forbidden
end
end
I reckon we need to align the API with the rest of the site, i.e. a user block only affects certain aspects of the API, not all of it.
As the case that prompted the creation of this issues shows, the current behaviour is quite appropriate as the default. It literally stops forum shopping and burdening the admins / DWG with having to chase around after the individuals in question.
That it might be a worth while extension of the blocking mechanism itself to be able to apply separately to the equivalents of the OAuth authorisations in a fine grained fashion is something that has been discussed in other issues IIRC.
One of many https://github.com/openstreetmap/openstreetmap-website/issues/1946
I disagree - it is clearly inappropriate.
The current situation is that user blocks on the web site are intended to stop the user editing. Nothing else.
You can argue that it should be wider if you want but that would mean the process of applying them would need to be moved from DWG to some sort of wider moderation team with the authority to globally block users from all OSM services.
For completeness for those who may be unaware, the OSMF's "ban" policy is at https://wiki.osmfoundation.org/wiki/Ban_Policy . The "Permanent blocks" mentioned in there are applied extremely rarely (maybe 2 in the last year or so, and that's more than normal).
Where a user has been blocked for problematic editing there is often other problematic behaviour that goes with it (changeset discussion comments, PMs. wiki edits, emails) and in some cases it may make sense to moderate those too (where possible), but usually having the user still being able to communicate outweighs cutting them completely adrift, if only to be able to reply "actually, it's not OK to do/say that, because...". Sometimes the admins of the relevant forums (forum.osm.org, wiki.osm.org, the OSM admins in the case of PMs etc.) would apply bans there if relevant.
I was surprised that a block (of any sort - even just a "please read this message before you continue editing" one) would cause a lockout at community.osm.org - clearly that is not desirable.
-- Andy (from the DWG, but other DWG members many have different views!)
As a DWG member, I can only agree with Andy. It is inconvenient that a user who has been blocked does not have or will not have the opportunity to publicly comment on their block or other issues unrelated to that block.
As a DWG member too: +1 for Andy's reply. Banning a user is meant only about editing, to avoid damaging data in any way whatsoever, but not meant to curtail his/her right to freedom of expression in the different OSM means of communication. Banning a user in any of those channels should be treated under other moderation rules.
As a DWG member, I can only agree with Andy. It is inconvenient that a user who has been blocked does not have or will not have the opportunity to publicly comment on their block or other issues unrelated to that block.
That however is, at least currently, not the case. Both the mailing lists and the diaries are currently available to blocked users, and it would seem unlikely that that will ever change for the former.
In the end, what we probably need here is to move the user block check from setup_user_auth to a dedicated function, and add that function as a new before_action where needed (e.g. creating changesets, uploading changes, and similar).
I was considering whether we can move these authorization checks out of the authentication method (since authorization != authentication) and into the abilities (since we're already using CanCanCan as our authorization framework).
The topic I haven't explored yet is how easy it will be to get the error messages correct, since if a user cannot edit it would be nice to know why (e.g. database offline, user block, user not yet active etc) and return an appropriate error message.
Indeed, CanCanCan seems to have some issues to tell a user why a particular API call failed. I will create two follow up issues I've noticed during testing... (#3529, #3530)
As a DWG member, I can only agree with Andy. It is inconvenient that a user who has been blocked does not have or will not have the opportunity to publicly comment on their block or other issues unrelated to that block.
That however is, at least currently, not the case. Both the mailing lists and the diaries are currently available to blocked users, and it would seem unlikely that that will ever change for the former.
Yes, and they could also write a letter to the daily mail or the NY times, but about 80% of the OSM users don't know how to participate in the mailing list or don't care to do so. They can also use discord, slack, telegram or whatever, but most of the communication between users (that are reported to the DWG) is happening on the changeset comments, and that is also the place where the DWG is interacting with them. As of this moment, if I block a user, I cannot tell them: "You are blocked until you have replied to the many questions on your changesets", because they simply cannot reply. And never, ever shall I tell a blocked user: "please start a discussion on you OSM user diary".
They can't reply on discourse currently (that's a bug as discussed here) but as far as I know all other communication channels are open to them.
If you have evidence to the contrary then please open a ticket for that so that we can keep this one vaguely on topic.
as far as I know all other communication channels are open to them.
I suspect the changeset comments (and notes) might be a problem, since they are still implemented by making ajax requests via the API. That might explain @marczoutendijk 's point, but I haven't tested them.
@marczoutendijk has a point here: commenting on changesets fails with HTTP 403 "Your access to the API has been blocked. Please log-in to the web interface to find out more.", which unfortunately isn't visible to the blocked user, except in the browser console.
--> should be moved to a new issue.
Another unhappy user who was affected by this bug: https://www.openstreetmap.org/changeset/121943595