- 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:
>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
> 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
> 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
> 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
mnalis left a comment (openstreetmap/openstreetmap-website#5490)
> You don't enter username/password during an Oauth2 flow. You enter them
> before that if you're not actually logged in because the authorization page
> redirects you to the login page in this case.
Well, that's what I meant. Wh
mnalis left a comment (openstreetmap/openstreetmap-website#5904)
I think this PR would benefit from outlying in more details exactly ***why***
is it doing changes (i.e. what exactly new user-requested functionality will
become available), instead of just enumerating low-level technical steps whi
mnalis left a comment (openstreetmap/openstreetmap-website#5904)
**TL;DR:** great for adding support for adding/changing (optional) tags on
notes, as well as (optional) extra API params / website changes to filter by
them; but please no mutable note texts/coordinates - it would be quite
problem
