> 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/2602568...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
