Ensure that blocked user sees his block-message

[westnordost]

A user that usually only uses StreetComplete to map should be able to see his block message.

This issue needs research: How does it currently behave when the user is blocked?

https://community.openstreetmap.org/t/is-this-the-same-person/123461

[matkoniecz]

I’ve tried blocking the user that I used for StreetComplete. A toast was displayed at the first attempted edit - “Authorisation Error, Please try logging in again”. No message was displayed at the second attempted edit. The things I’d “edited” were not changed in OSM but were in SC’s upload queue.

I then manually logged into OSM in a PC browser and saw the block message.

After making another change in SC (after the block is cleared) results in a different message:

You need to authorize with your OSM user account to publish your answers. Authorize now?
You can do this later on the profile screen.
Later OK

https://community.openstreetmap.org/t/is-this-the-same-person/123461/19

The summary of all of this is that there are a bunch of changes within StreetComplete that would be hugely beneficial:

allow ordinary OSM messages to be shown in a timely manner
allow block messages to be shown in a timely manner
recognise that a “failure to upload” might be a block and not an invalid token
Also, we cannot be sure that the user in this case has ever seen an email, a block message, or an OSM message :slight_smile:

[kmpoppe]

After my second dev user was logged in on the app and was able to "do" stuff, I asked SomeoneElse to block the user for an hour and then tried to upload a change.

SC displayed a popup "Authorization error, please try to login again" (login information was discarded) and the log displays this information:

2024-12-29T21:16:32.325: E [Upload] Unable to upload de.westnordost.streetcomplete.data.AuthorizationException: Client request(PUT https://master.apis.dev.openstreetmap.org/api/0.6/changeset/create) invalid: 403 Forbidden. Text: "Dein Zugriff auf die API wurde gesperrt. Bitte melde dich auf der Web-Oberfläche an, um mehr zu erfahren."

So it seems that the API will display a message localized to the user's setting. I wonder if displaying that in the popup would make any difference, because the display duration is relatively short.

[westnordost]

What happens if you try to login again in StreetComplete? Is the block message displayed at the login screen?

[kmpoppe]

No, when I click on "Login" it warns about an unpublished edit, ignoring that message, the website shows the "requested methods" list:

After clicking "Authorize", the same authorization error is displayed with these messages in the log:

2024-12-29T21:37:21.304: W [UserUpdater] Unable to download user details de.westnordost.streetcomplete.data.AuthorizationException: Client request(GET https://master.apis.dev.openstreetmap.org/api/0.6/user/details) invalid: 403 Forbidden. Text: "Dein Zugriff auf die API wurde gesperrt. Bitte melde dich auf der Web-Oberfläche an, um mehr zu erfahren."
2024-12-29T21:37:21.370: E [Upload] Unable to upload de.westnordost.streetcomplete.data.AuthorizationException: Client request(PUT https://master.apis.dev.openstreetmap.org/api/0.6/changeset/create) invalid: 403 Forbidden. Text: "Dein Zugriff auf die API wurde gesperrt. Bitte melde dich auf der Web-Oberfläche an, um mehr zu erfahren."

So the /user/details fails first.

I'm baffled by the fact that I can use my login data in the web-window and it displays the methods list and never complains the user is blocked but only gives this information to the app.

[kmpoppe]

Also, when I explicitly log out of the website widget and login again, the behaviour is the same, i.e. not displaying the block message at all.

[westnordost]

Maybe you still had a login cookie in the webview, i.e. you were already logged in?

Or, the oauth flow is hardwired to directly go to the authorization screen, without showing any block message in that flow.

[westnordost]

Say, how does the block message on osm.org look like when you try to log in in the browser? (Does it display properly on small screens like that of a smartphone?)

[kmpoppe]

Maybe you still had a login cookie in the webview, i.e. you were already logged in?

That's what I just tried by explictly expanding the Burger Menu and Logging off:

That should remove the login cookie.

Say, how does the block message on osm.org look like when you try to log in in the browser? (Does it display properly on small screens like that of a smartphone?)

Absolutely not. It goes from the successful login directly to the map view. Doing the same login on the browser on a desktop displays the block message - although I can browse through the map and do everything - excepting editing.

[westnordost]

That's indeed quite weird. The block message is always shown in the browser, but never in a webview? Or is it dependent on the screen size? What about a browser on the smartphone? Or is the block-message-displaying disabled by being in the oauth flow?

[matkoniecz]

Is message disappearing when browser window is resized to be tiny?

[matkoniecz]

I blocked myself and logged into mobile browser and get block message displayed on login

[tomhughes]

Being blocked shouldn't stop you being able to login or authorize an OAuth token as far as I know so you should be able to authorize and then get the active block count from the user details API call.

[tomhughes]

Hmm apparently it does stop you being able to make the details call but that seems like a bug to me - you just shouldn't be able to edit.

[mmd-osm]

Yes, that’s a known issue: openstreetmap/openstreetmap-website#3522

[AntonKhorev]

Hmm apparently it does stop you being able to make the details call but that seems like a bug to me - you just shouldn't be able to edit.

That's why I suggested opening /api/0.6/user/(id) as a workaround https://community.openstreetmap.org/t/is-this-the-same-person/123461/23

[AntonKhorev]

I blocked myself and logged into mobile browser and get block message displayed on login

We have blocks with needs_view flag and without it. Only those with needs_view will be shown on login.

[AntonKhorev]

Currently you as an app developer can do the following to detect the block and tell about it to the user:

• record user id and name
• when you get 403, check /api/0.6/user/#id without sending auth header (if you include the header and the user is blocked, you won't get the results)
• if received active blocks count is above zero, the user is blocked and you can tell the user that they're blocked
• then you can tell them that to find out why they're blocked, they need to login, and you give them this link: /login?referer=%2Fuser%2Fusername%2Fblocks, where %2Fuser%2Fusername%2Fblocks is an urlencoded link to /user/username/blocks, insert real username instead of username
• when the user opens that link and logs in they'll either get shown a needs_view block if there's one, or they'll be redirected to a page that lists all of their blocks

[matkoniecz]

We have blocks with needs_view flag and without it. Only those with needs_view will be shown on login

Yes, I set it.

What I have not tested personally whether I will see it in oauth flow (AFAIK no) and whether it will be cleared while going through oauth flow

[kmpoppe]

• record user id and name
• when you get 403, check /api/0.6/user/#id without sending auth header (if you include the header and the user is blocked, you won't get the results)

First of all, we'd need to ensure the user id doesn't get forgotten, when we get a 403, which is the case today upon upload after the user is blocked.

The behaviour logging in when already blocked is a whole different story because "now" I only get a Warning about the 403 and the app thinks we were logged in but doesn't show the username, so there's something considerably to do here to figure out a working route with the "known issue" mentioned above.

@westnordost playing around with LastUploadErrorEffect I was able to explicitly display a new UserBlockedDialog when we encounter a 403 while uploading, but I don't feel that's enough :-/

[AntonKhorev]

What I have not tested personally whether I will see it in oauth flow (AFAIK no) and whether it will be cleared while going through oauth flow

I tried opening oauth links while having a needs_view block:

• if the user isn't logged in, oauth flow will lead them to login and after logging in they're redirected to the block page
• if the user is logged in, they are not redirected to the block page

[mmd-osm]

when you get 403, check /api/0.6/user/#id without sending auth header (if you include the header and the user is blocked, you won't get the results)

Just as a reminder, if the GDPR project happens to take off in 2025, calling this endpoint without authentication is supposed to no longer work then: https://wiki.openstreetmap.org/wiki/GDPR/Affected_Services#Methods_for_user_data

[kmpoppe]

With this issue being depending on time (GDPR 2025) and changes to openstreetmap-website, should this be put into a "Project" to not loose sight of the todo's because there's nothing on the SC side that can be done right now?

[matkoniecz]

Current state, according to my research and research shared by others:

• currently blocked user will not get a message
• they will become logged out on failed upload giving 403 error (which for SC users would appear almost entirely on being blocked but it is not certain and may easily change in future)
• they can log in again which will not result in getting a block message
• repeat

Also, there is no reasonable stable API that allows to check whether user is blocked. There are ugly workarounds but nothing reasonable.

[matkoniecz]

I would consider it being blocked by and waiting on openstreetmap/openstreetmap-website#5452 (or other reasonable way to query block status without doing complex and fragile workarounds)

Until it happens blocked users may be confused a bit.

Thanks again everyone who helped in research and to people improving OSM API (including writing PR, reviewing them and so on).

[westnordost]

Well, in my opinion, not even by the mentioned pull request. It seems like a bug or otherwise an important missing feature in openstreetmap-website that when logging in as part of the oauth flow, the block is not displayed to the user. It doesn't make sense for all openstreetmap editor developers to query some special API in order to display a block message to the user within the app. Instead, the block should just always be displayed when trying to login on osm.org, regardless of normally or as part of an oauth flow.

See also https://community.openstreetmap.org/t/is-this-the-same-person-streetcomplete-block-and-message-visibility/123461/26

Ideally, the block reason should be shown to the user modally when trying to login (or trying to use a login cookie) before redirecting him to the OAuth authentication. This way, it is guaranteed that the user will see the message when logging in (or trying to) via oauth, regardless of from what app the oauth flow was initiated.

[matkoniecz]

There was

Being blocked shouldn't stop you being able to login or authorize an OAuth token as far as I know so you should be able to authorize and then get the active block count from the user details API call.

but I guess it does not reject missing display of block message being a bug

[AntonKhorev]

when logging in as part of the oauth flow, the block is not displayed to the user.

The block is displayed when logging in (no matter what the flow is) if the block wasn't viewed and it needs to be viewed.

[matkoniecz]

And it is only place where it was checked? So already logged in user will not get any message from osm.org about being blocked (unless they go to block list, manually or via API?)

[matkoniecz]

Even if they login with oauth into some another OSM editor?

---

From https://github.com/openstreetmap/openstreetmap-website/issues?q=is%3Aissue+oauth+block+message I see no report about this

I think about opening following issue:

Title: blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor)

Body:
This was tested on Android, as part of #6062 resulting from https://community.openstreetmap.org/t/is-this-the-same-person/123461
I spend noticeable amount of time on this and I am still a bit confused.

1. Login in a browser, remember login, close browser
2. Become blocked, with 0-hour block that must be seen before
3. Grant oauth token in the same browser (logging into some editor software using that generated token)

Expected: block message is shown on user entering the site, as from user perspective they log into some software

Actual: oauth authorisation appears, control handed to requesting software, user still blocked.

I am aware that there are some ugly workarounds that can be done by app, and done by some editing software.

[AntonKhorev]

Login in a browser, remember login, close browser
Login via oauth in the same browser

The second "Login" is not a login. The user is already logged in.

they will become logged out on failed upload giving 403 error

I guess that this "become logged out" is also not an actual logout.

[westnordost]

they will become logged out on failed upload giving 403 error

I guess that this "become logged out" is also not an actual logout.

In the context of StreetComplete, it means that the OAuth token is deleted. For getting a new OAuth token, osm.org is opened within a WebView. In this WebView, the user may still be logged in via a cookie, so that he only needs to re-authorize StreetComplete, rather than input his username and password.

[AntonKhorev]

It doesn't make sense for all openstreetmap editor developers to query some special API in order to display a block message to the user within the app. Instead, the block should just always be displayed when trying to login on osm.org, regardless of normally or as part of an oauth flow.

If the user receives a block while logged in and using your app, how are you going to know that they're blocked? The "instead" part may never happen because they are already logged in and won't try to log in again. What do you do once you discover that the user is blocked is a different question, that's why I also write about step 2 in openstreetmap/openstreetmap-website#5452.

In the context of StreetComplete, it means that the OAuth token is deleted

That's not "logging out". If you delete the token, you won't be able to check if the current user is blocked. Other editors probably don't delete the token in this situation, at least iD doesn't as I just checked.

[westnordost]

The point is that the app shouldn't need to know that the user is blocked. If upload gives a 403 error, the API token will be considered invalid and deleted, the user is prompted to "log in again". This will lead him to osm.org in a WebView, in which a block reason should be displayed (but currently isn't).

[AntonKhorev]

If upload gives a 403 error, the API token will be considered invalid and deleted

403 doesn't make the token invalid. You are deciding to delete a valid token.

the user is prompted to "log in again"

The prompt is wrong because it's not a login.

in which a block reason should be displayed (but currently isn't).

Not necessarily.

[westnordost]

I know.

It's a login/logout from the user perspective.

[AntonKhorev]

You may argue that there should be a redirect to needs_view blocks from oauth authorization page too. I don't know why we don't do this, probably for the same reason that there are no redirects from every other page. But even if showing needs_view blocks, by redirect or otherwise, is added to the oauth page, that won't solve all of the problems. What if it's not a needs_view block, what if the block was already viewed? Such block will still give 403s, you'll make the user visit the oauth page again and then what?

If openstreetmap/openstreetmap-website#5452 is merged, you'll be able to check if there are viewed / not viewed active blocks. If you delete the token, you lose that ability.

[matkoniecz]

The second "Login" is not a login. The user is already logged in.

Authorizing an application by granting it a new oauth token is effectively login from user perspective.
I would expect block message shown on login to be displayed also then.

[matkoniecz]

I opened openstreetmap/openstreetmap-website#5490 - I admit that I have no great hopes for this but wanted to at least try.

It really should not be required by every single app that supports login via oauth to support hacky workarounds.