[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]

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

We should both perhaps use more clear language. IIUC you seem to take _"log in"_ to mean exclusively to _"go to https://www.openstreetmap.org/login webpage and enter username/password there"_, while I intended it to mean _"enter your username/password **somewhere** in order to gain elevated privileges compared to when non-logged-in"_ (like e.g. in any Oauth2 flow).

> Proper solution: Ask the website to show the block message. Available if https://github.com/openstreetmap/openstreetmap-website/pull/5524 is merged.

While #5524 seems improvement over the suggested workaround, they both IMHO suffer from the same issue: they require app to call some URLs that they would've never called otherwise; and are not an enforceable requirement (i.e. app will work just fine in 99.99% of the cases without it being [correctly] implemented), but something that is optional and hard to test[^1].

My point is that both are far from ideal solution: If something is ***optional***, it will only be implemented ***sometimes*** (because extra work), not always. Which would mean someone would have to go through **all** apps and other API users, and open at least issues (if not PRs) if they don't implement it, and then followup later to check if it is correctly implemented. And keep doing that ad infinitum (as new API users will emerge). That is a high-maintenance approach.

On the other hand, implementing it inside OAuth2 flow enforces the block message showing (when needed) for all API users, so it need only be done once, so is low-maintenance.

(And yes, we can have _both_, but it it is the latter which is actually more important, IMHO).

> The user has no reason to go to OAuth flow when blocked

Why do you think there is "no reason"? _"403 Forbidden"_ means that user doesn't have authorization to access some resource, right? 
The common thing to do in the industry[^2] to solve or troubleshoot such issue is to try to re-authenticate with same user (with hopes that will re-fecth all authorizations too which may have been using stale cache or expired; i.e. IP changed, time expired etc.) or, if that fails, try to authenticate with different user (to determine whether the problem is related to specific account, or elsewhere - e.g. server problem).

[^1]: AFAIK, users cannot put different blocks on their accounts. It might help with testing if OSM publicly provided several accounts with known password with various blocks so app devels (and other users) can test how apps behave, but still it would not have solved the core problem -- which is that **optional**  things will statistically _never_ be implemented by **all** API users.

[^2]: to the point that it got enshrined in the common IT jokes, even for cases when there is no clear indication of authentication/authorization problems: e.g. [mechanic,  electrician, and a programmer are driving in a car when it stops suddenly](https://www.reddit.com/r/Jokes/comments/27sdtj/three_engineers_are_riding_in_a_car/) (puchline is programmer's solution _"Why don't we all just get out of the car and get in again, and then see if it starts?"_)

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

Message ID: <openstreetmap/openstreetmap-website/issues/5490/2602568281 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250120/433206ff/attachment.htm>