<p></p>
<blockquote>
<p dir="auto">My workarounds: Send the user to the login page, so they actually log in.</p>
</blockquote>
<p dir="auto">We should both perhaps use more clear language. IIUC you seem to take <em>"log in"</em> to mean exclusively to <em>"go to <a href="https://www.openstreetmap.org/login" rel="nofollow">https://www.openstreetmap.org/login</a> webpage and enter username/password there"</em>, while I intended it to mean <em>"enter your username/password <strong>somewhere</strong> in order to gain elevated privileges compared to when non-logged-in"</em> (like e.g. in any Oauth2 flow).</p>
<blockquote>
<p dir="auto">Proper solution: Ask the website to show the block message. Available if <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2798170799" data-permission-text="Title is private" data-url="https://github.com/openstreetmap/openstreetmap-website/issues/5524" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/5524/hovercard" href="https://github.com/openstreetmap/openstreetmap-website/pull/5524">#5524</a> is merged.</p>
</blockquote>
<p dir="auto">While <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2798170799" data-permission-text="Title is private" data-url="https://github.com/openstreetmap/openstreetmap-website/issues/5524" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/5524/hovercard" href="https://github.com/openstreetmap/openstreetmap-website/pull/5524">#5524</a> 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^{<a href="#user-content-fn-1-7288c7f7e3d62f6f5ca1ef1e05bf4056" id="user-content-fnref-1-7288c7f7e3d62f6f5ca1ef1e05bf4056" data-footnote-ref="" aria-describedby="footnote-label">1</a>}.</p>
<p dir="auto">My point is that both are far from ideal solution: If something is <em><strong>optional</strong></em>, it will only be implemented <em><strong>sometimes</strong></em> (because extra work), not always. Which would mean someone would have to go through <strong>all</strong> 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.</p>
<p dir="auto">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.</p>
<p dir="auto">(And yes, we can have <em>both</em>, but it it is the latter which is actually more important, IMHO).</p>
<blockquote>
<p dir="auto">The user has no reason to go to OAuth flow when blocked</p>
</blockquote>
<p dir="auto">Why do you think there is "no reason"? <em>"403 Forbidden"</em> means that user doesn't have authorization to access some resource, right?<br>
The common thing to do in the industry^{<a href="#user-content-fn-2-7288c7f7e3d62f6f5ca1ef1e05bf4056" id="user-content-fnref-2-7288c7f7e3d62f6f5ca1ef1e05bf4056" data-footnote-ref="" aria-describedby="footnote-label">2</a>} 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).</p>
<section data-footnotes="" class="footnotes"><h2 id="footnote-label" class="sr-only" dir="auto">Footnotes</h2>
<ol dir="auto">
<li id="user-content-fn-1-7288c7f7e3d62f6f5ca1ef1e05bf4056">
<p dir="auto">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 <strong>optional</strong>  things will statistically <em>never</em> be implemented by <strong>all</strong> API users. <a href="#user-content-fnref-1-7288c7f7e3d62f6f5ca1ef1e05bf4056" data-footnote-backref="" aria-label="Back to reference 1" class="data-footnote-backref">↩</a></p>
</li>
<li id="user-content-fn-2-7288c7f7e3d62f6f5ca1ef1e05bf4056">
<p dir="auto">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. <a href="https://www.reddit.com/r/Jokes/comments/27sdtj/three_engineers_are_riding_in_a_car/">mechanic,  electrician, and a programmer are driving in a car when it stops suddenly</a> (puchline is programmer's solution <em>"Why don't we all just get out of the car and get in again, and then see if it starts?"</em>) <a href="#user-content-fnref-2-7288c7f7e3d62f6f5ca1ef1e05bf4056" data-footnote-backref="" aria-label="Back to reference 2" class="data-footnote-backref">↩</a></p>
</li>
</ol>
</section>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2602568281">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLN52SXM7X74FZ7IF5D2LUBZ3AVCNFSM6AAAAABU67LUOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBSGU3DQMRYGE">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLP7QFTVNICPEZUI7T32LUBZ3A5CNFSM6AAAAABU67LUOOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTU3EAFFS.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/issues/5490/2602568281</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2602568281",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2602568281",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>