[openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)

[Matija Nalis]

> If there's an api to check whether the user is blocked, you need a valid token to access that api.  If blocking invalidates the token, you're not going to have a valid token to access that api.


Makes sense. That is why my suggestion implied that such a new API call is maybe not needed at all (thus avoiding that whole need-valid-token-to-access-the-api problem)

> It only makes sense to invalidate the token if you insist on making users to reauthorize all of their apps once blocked, maybe as a form of punishment.


Not a big fan of unneeded punishments.  Also reauthorization is needed only first time, not for every app. Here is some pseudocode that perhaps might get my point better across:

- when DWG clicks `block user $user_id`: do the `UPDATE tokens SET valid=false WHERE user_id=$user_id`
- token validation code by API: `SELECT * FROM tokens WHERE token=$token and valid=true`  (as usual, if the result is an empty set, there is no valid token and user needs to login)
- login code: when user tries to login and is blocked, display block message, and when they confirm that window, do `UPDATE tokens SET valid=true WHERE user_id=$user_id` (indicating the user have read the message in one app/website and their tokens no longer need to be invalid)

> It's going to happen if things are done the way StreetComplete devs want.  They want to kill off the token once they get a 403 response.

It seems to me they do that because there is no reasonable better solution available _**currently**_ (adding complex and ugly kludges which will likely also stop working during 2025 due to GDPR issue does not really count)? But I'm not speaking for that project :man_shrugging: 

> If the user has a timed block, they'll keep killing off the tokens and telling the user to reauthorize, and then get 403 again because the block is still active.

Which seems fine to me in that case? If my suggestion is implemented, the user would have to login once and will be displayed the message like e.g. _"[...] You will not be able to login until 1.may.2025 00:00"_. Now, if the user is attempting to login before that time, that probably means either:

- they have not _actually_ read the message  (_"just press next / OK"_)
- they have read the message, but are not understanding it (e.g. _"language issue or lack of technical understanding"_)
- they have read and understood the message, but have in the meantime forgot for how long they have to wait before being granted access again
- they have read and understood the message and the block, but are trying to circumvent it

I'd say that in all those cases  displaying the block message again is just fine (and I'd wager recommended?). The appropriate thing for user to do is to wait for indicated date, cool off, and reflect on things that earned them that timed block. 

> If we add some kind of notifications for blocks, they won't work because the user needs to be logged in to receive notifications.

I'm not sure about this. Is that something which already exists, or are you talking about potential future additions of functionality to OSM? In any case, if token is invalidated, whenever user tried to access some resource that requires a valid token, they would need to login to obtain a valid token (which would display the block message if it is timed and not expired yet), so I'd say they'd get notified?

> The apps need to change their code if their devs want the error messages presented to users to make sense.  "We got some error we don't know why, maybe go relogin?"

I meant _additional change_. Surely something _already_ happens in the apps when they receive _"403 Forbidden"_, which AFAICT should happen mostly with things intentionally preventing that login like blocks (or in rarer cases, server failures). In either case, trying to re-login seems like the safe bet on the list of the things to try? What do the apps currently do here, in your experience?

> And I haven't even suggested to display the block message in the app. That's because currently the blocks api returns it in some format it doesn't tell, but it's almost certainly markdown. Then you'll say that you don't want to parse markdown

I'll note that this particular problem is also completely avoided in my suggestion (as all displaying is done on a login form HTML, which _already_ must be correctly displayed to the user, so no additional changes or rendering implementations need to be done on the app side).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2585839783
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/5490/2585839783 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250112/28e093e6/attachment.htm>