<p></p>
<blockquote>
<p dir="auto">invalidating tokens</p>
</blockquote>
<p dir="auto">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.</p>
<p dir="auto">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. Got blocked while having JOSM, Vespucci, StreetComplete, OSMCha, etc authorized? Now go reauthorize all of them and don't get blocked next time.</p>
<blockquote>
<p dir="auto">Perhaps I'm misunderstanding, but why would that "again and again" reauthorisation need to happen?</p>
</blockquote>
<p dir="auto">It doesn't need to happen. 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. 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.</p>
<p dir="auto">This behavior of killing off tokens on 403 is the reason why this issue was opened. If they stop doing that, they wouldn't need block messages appearing on the authorization page.</p>
<blockquote>
<p dir="auto">If that suggestion is viable, invalidating all sessions</p>
</blockquote>
<p dir="auto">Invalidating website sessions is a different from invalidating tokens, but it goes further down the road of not being able to check the current blocked status. The user won't necessarily notice that they are logged out. If we add some kind of notifications for blocks, they won't work because the user needs to be logged in to receive notifications.</p>
<blockquote>
<p dir="auto">As a main advantage to such flow, only admin blocking backend and login form need to change, and no app need to change their code</p>
</blockquote>
<p dir="auto">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?"</p>

<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-2585774911">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLP4YINVLJ2EB3ZHRGT2KKB3LAVCNFSM6AAAAABU67LUOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBVG43TIOJRGE">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLIM6BV2AKFUSQ5KVT32KKB3LA5CNFSM6AAAAABU67LUOOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTU2D7FT6.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/2585774911</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-2585774911",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2585774911",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>