> 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 all (thus avoiding that whole
need-valid-token-to-access-the-api problem)
> 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.
Not a big fan of unneeded punishments. Also reauthorization is needed only
first time, not for every app. Here is some pseudocode that perhaps might get
my point better across:
- when DWG clicks `block user $user_id`: do the `UPDATE tokens SET valid=false
WHERE user_id=$user_id`
- token validation code by API: `SELECT * FROM tokens WHERE token=$token and
valid=true` (as usual, if the result is an empty set, there is no valid token
and user needs to login)
- login code: when user tries to login and is blocked, display block message,
and when they confirm that window, do `UPDATE tokens SET valid=true WHERE
user_id=$user_id` (indicating the user have read the message in one app/website
and their tokens no longer need to be invalid)
> 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.
It seems to me they do that because there is no reasonable better solution
available _**currently**_ (adding complex and ugly kludges which will likely
also stop working during 2025 due to GDPR issue does not really count)? But I'm
not speaking for that project :man_shrugging:
> 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.
Which seems fine to me in that case? If my suggestion is implemented, the user
would have to login once and will be displayed the message like e.g. _"[...]
You will not be able to login until 1.may.2025 00:00"_. Now, if the user is
attempting to login before that time, that probably means either:
- they have not _actually_ read the message (_"just press next / OK"_)
- they have read the message, but are not understanding it (e.g. _"language
issue or lack of technical understanding"_)
- they have read and understood the message, but have in the meantime forgot
for how long they have to wait before being granted access again
- they have read and understood the message and the block, but are trying to
circumvent it
I'd say that in all those cases displaying the block message again is just
fine (and I'd wager recommended?). The appropriate thing for user to do is to
wait for indicated date, cool off, and reflect on things that earned them that
timed block.
> If we add some kind of notifications for blocks, they won't work because the
> user needs to be logged in to receive notifications.
I'm not sure about this. Is that something which already exists, or are you
talking about potential future additions of functionality to OSM? In any case,
if token is invalidated, whenever user tried to access some resource that
requires a valid token, they would need to login to obtain a valid token (which
would display the block message if it is timed and not expired yet), so I'd say
they'd get notified?
> 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?"
I meant _additional change_. Surely something _already_ happens in the apps
when they receive _"403 Forbidden"_, which AFAICT should happen mostly with
things intentionally preventing that login like blocks (or in rarer cases,
server failures). In either case, trying to re-login seems like the safe bet on
the list of the things to try? What do the apps currently do here, in your
experience?
> And I haven't even suggested to display the block message in the app. That's
> because currently the blocks api returns it in some format it doesn't tell,
> but it's almost certainly markdown. Then you'll say that you don't want to
> parse markdown
I'll note that this particular problem is also completely avoided in my
suggestion (as all displaying is done on a login form HTML, which _already_
must be correctly displayed to the user, so no additional changes or rendering
implementations need to be done on the app side).
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2585839783
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/issues/5490/2585839...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
