> 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
> - 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 eith
> 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.
Makes sense. That is why my suggestion implied that such a new API call is
maybe not needed at
>Sending the user to reauthorize again and again when they've already seen a
>block is not going to help with anything.
Perhaps I'm misunderstanding, but why would that _"again and again"_
reauthorisation need to happen?
My suggestion was _not_ about invalidating tokens every time a user logs i
> but for clients that already have a token and are just hitting the API
> there's no way we can magically display a message.
Wouldn't be possible that when a user is blocked, their tokens are invalidated,
so they are forced to re-login?
--
Reply to this email directly or view it on GitHub:
h
- ref: https://github.com/openstreetmap/openstreetmap-website/issues/5200
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/986#issuecomment-2466428044
You are receiving this because you are subscribed to this thread.
Message ID:
