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

[Anton Khorev]

> > * Sending the user to /login?referer=%2Fuser%2Fusername%2Fblocks is a workaround that somewhat works for non-needs_view blocks too and is not affected by GDPR. (*)
> 
> > * Don't care about non-needs_view blocks and want a simpler workaround? Send users to /login. (**)
> 
> Hmmm, does doing either of those "workarounds" automatically display block message to the user of the app (to simplify, assume that user has just installed the app on a new device, and clicked login, which opened webview for them to complete the OAuth login flow, but they are blocked)?

The app tells the user: "open this link, you'll see a login form, then enter your login details to see if you're blocked". If the user does that, they'll get redirected to a needs_view block if one exists *or* in case of more complicated link with a referer they'll get redirected to the *Blocks on Me* page.

> The whole point of this issue (as I understand it) is the problem that _"blocks with needs_view flag are not shown when user does OAuth authorization"_.

The whole point of this issue is that it doesn't describe the problem but rather a solution, and it's not a good solution.

Problem: We want the website to show the block message.

Solution offered here: Make the user log in again because logging in shows the block message. But actually not, let's make the user authorize our app again and call this a *login*. Since it's not actually a login it doesn't do what we want, therefore let's ask to modify what it does so it work similarly to an actual login. And all of this still won't work for non-needs_view blocks.

My workarounds: Send the user to the login page, so they actually log in.

Proper solution: Ask the website to show the block message. Available if #5524 is merged.

> But if they don't implement those optionals; I think OSM itself (during OAuth flow) should still display block message while it has control over flow and formatting (i.e. HTML renderer by app using webview while attempting to log in). Because if we depend on claim that _"100% of the apps will always do this extra steps which are not unavoidable required functionality"_ we setup ourselves to surely fail (i.e. some apps _won't_ do optional steps, and their users will never see block messages).

The user has no reason to go to OAuth flow when blocked. It's only going to happen if the app forces the user to do so. *OSM itself* doesn't have control over the app at this moment. The app first have to return control to OSM.

There is of course a scenario when the user is blocked before authorizing the app and we can discuss what to do in this case, but this is not why this issue was opened.

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

Message ID: <openstreetmap/openstreetmap-website/issues/5490/2601405554 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250119/1696005e/attachment.htm>