Re: [openstreetmap/openstreetmap-website] Display a link for mapillary keys (#986)
- 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:___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)
>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 in and sees a block; instead it was about invalidating tokens exactly once (i.e. at the moment when DWG or whoever creates the actual block in their backend admin interface). If that suggestion is technically viable, invalidating all sessions at block time would force a user to re-login, and if login form is also modified to display the blocking message, it should make sure that user will see a block message no matter what app they use (as they need to login again, and that would show the message). 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 (other proposed solutions I've seen so far seem to require that each and every app be updated, and until all have done so, there always remain a chance the user will never see the block) -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2585751117 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)
> 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: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)
> 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 _"enter your username/password **somewhere** in order to gain elevated privileges compared to when non-logged-in"_ (like e.g. in any Oauth2 flow). > Proper solution: Ask the website to show the block message. Available if > https://github.com/openstreetmap/openstreetmap-website/pull/5524 is merged. While #5524 seems improvement over the suggested workaround, they both IMHO suffer from the same issue: they require app to call some URLs that they would've never called otherwise; and are not an enforceable requirement (i.e. app will work just fine in 99.99% of the cases without it being [correctly] implemented), but something that is optional and hard to test[^1]. My point is that both are far from ideal solution: If something is ***optional***, it will only be implemented ***sometimes*** (because extra work), not always. Which would mean someone would have to go through **all** apps and other API users, and open at least issues (if not PRs) if they don't implement it, and then followup later to check if it is correctly implemented. And keep doing that ad infinitum (as new API users will emerge). That is a high-maintenance approach. On the other hand, implementing it inside OAuth2 flow enforces the block message showing (when needed) for all API users, so it need only be done once, so is low-maintenance. (And yes, we can have _both_, but it it is the latter which is actually more important, IMHO). > The user has no reason to go to OAuth flow when blocked Why do you think there is "no reason"? _"403 Forbidden"_ means that user doesn't have authorization to access some resource, right? The common thing to do in the industry[^2] to solve or troubleshoot such issue is to try to re-authenticate with same user (with hopes that will re-fecth all authorizations too which may have been using stale cache or expired; i.e. IP changed, time expired etc.) or, if that fails, try to authenticate with different user (to determine whether the problem is related to specific account, or elsewhere - e.g. server problem). [^1]: AFAIK, users cannot put different blocks on their accounts. It might help with testing if OSM publicly provided several accounts with known password with various blocks so app devels (and other users) can test how apps behave, but still it would not have solved the core problem -- which is that **optional** things will statistically _never_ be implemented by **all** API users. [^2]: to the point that it got enshrined in the common IT jokes, even for cases when there is no clear indication of authentication/authorization problems: e.g. [mechanic, electrician, and a programmer are driving in a car when it stops suddenly](https://www.reddit.com/r/Jokes/comments/27sdtj/three_engineers_are_riding_in_a_car/) (puchline is programmer's solution _"Why don't we all just get out of the car and get in again, and then see if it starts?"_) -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2602568281 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)
> - 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 either of those "workarounds" automatically display block message to the user of the app (to simplify, assume that user has just installed the app on a new device, and clicked login, which opened webview for them to complete the OAuth login flow, but they are blocked)? Is the block message displayed to the user? If not, how is it "workaround" at all? The whole point of this issue (as I understand it) is the problem that _"blocks with needs_view flag are not shown when user does OAuth authorization"_. > Something that already happens is that some apps lie to their users that the > token is invalid, although they could have checked it. I don't know exact internals of either of the mentioned apps, but I guess if they have made extra checks and extra workarounds on receiving 403, that it was not because they were bored, but because doing that have solved (or worked around, if you prefer) some particular issue(s) that they've had in the past. Do we know what those issues were?[^1] > It isn't because the problem here is for the apps that want to display the > message inside the app. Your suggestion is for the apps that don't want it. Yes, my suggestion was for the general case. I have no problems with the idea that **in addition** to such _always-works_ case, there is an _additional_ new API endpoint for apps which prefer more fine-grained handling of the situation. But if they don't implement those optionals; I think OSM itself (during OAuth flow) should still display block message while it has control over flow and formatting (i.e. HTML renderer by app using webview while attempting to log in). Because if we depend on claim that _"100% of the apps will always do this extra steps which are not unavoidable required functionality"_ we setup ourselves to surely fail (i.e. some apps _won't_ do optional steps, and their users will never see block messages). [^1]: If we're not sure we know, perhaps we should not tear down that [Chesterton's fence](https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence) just yet? -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2588405727 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)
> 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: https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2583791922 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] blocks with needs_view flag not shown when user does oauth authorisation (for example login into an OSM editor) (Issue #5490)
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. When I'm redirected to some page (like `https://www.openstreetmap.org/login?referer=%2Foauth2%2Fauthorize...`) I consider that page ***too*** part of the Oauth2 flow (as evidented by string _"oauth2"_ inside that referer, indicating it was Oauth2 which sent me there). But if you prefer different terminology for URLs which are called by `www.openstreetmap.org/oauth2/*` but are not inside that same "directory" (i.e. URL prefix), I'll be happy to oblige. > There's ony one somewhere where you enter username/password - the login page, > if we ignore apps with very questionable login practices like Organic maps. well, I am not the one to call it questionable or not. 🤷 If those are unwanted, we could perhaps employ countermeasures to disallow them? (or at least open issues at their issue trackers to explain why we don't want those, and what are the acceptable alternatives?) --- Anyway, if I've (hopefully) managed to clarify the ambiguity in terminology used; what do you think of https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2602015806 ? To me the advantages would be that the users become aware of the blocks more often then they do now; are there disadvantages that would outweigh those? -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/issues/5490#issuecomment-2815414414 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] Adds note versions and variable note tags (PR #5904)
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 which are being done. Judging by few words and linked PR discussion, I guess it might have something to do with enabling users to add tags to notes and thus making notes mutable, but I cannot really tell what is an actual idea being implemented, and what are technical side-effects. > plus update functionality (we would have new event type - update) something > you would like? I don't think that notes would benefit from being changed, in fact it would likely be very bad. I.e. if note could be moved or its description changed, followup comments could be misunderstood or turned out of context. Also, it would make necessery not only API/UI to see what changes were being made and when, but a new (or extended) planet.osm.org dump (like we have e.g. `planet-*.bz2` as well as `history-*.bz2` for nodes/ways/relations). Only part of Note that should be modifiable IMHO is implementing #hashtags, the rest of the notes should better remain immutable. Having versions, locations and descriptions being change are IMHO likely to introduce much more chaos then help. **TL;DR:** can you list example use-cases and how this PR addresses them (i.e. _"users currently do this thing x which is inconvenient, and with those changes implemented they will be able do this other thing which is easier/better because "_) -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/pull/5904#issuecomment-2858692186 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] Adds note versions and variable note tags (PR #5904)
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 problematic! --- Thanks for clarifications @nenad-vujicic ! > - At the moment mappers use hash-tags. In near future we could use buttons > for creating / updating / deleting note tags. Similarly for reading, instead > of passing through note-comments, we will have a table like for elements > (this is implemented). I agree; adding tags to notes is useful feature. Data consumers which do not implement that extension would still be able to use all existing functionality in the same way, so would only miss on those extensions. > - At the moment mappers manually search / filter notes. In near future we > could use UI for defining searching / filtering criterias. Having an API extension being able to also filter by those tags would be nice addition, getting around limitation of maxnotes and local filtering etc. (provided it reduces the server load instead of increasing it). Also, data consumers which do not implement those search extensions would retain same functionality as before, so this sounds good to me too. > - At the moment mappers manually inspect notes or use 3rd party tools. We > already have implemented (in this PR) retrieving particular note's version, > which gives us a chance to build note's history viewers / analyzers for > automatizing parts of note's inspection. **Mutable text/coordinates of Notes however looks highly problematic to me.** Notes are currently journal-like implementation, i.e. only new comments can be added, and old ones cannot be changed. I think making the comments and coordinates mutable would be very bad. It is IMHO **not comparable to elements (nodes/ways/relations) versioning**, as those are self-contained and **do not have dependent subelements**. But notes have: each note comment is dependent "subelement", i.e. meaning of each note "reply" **depends** on the content of **coordinates and original texts of ALL preceding comments**, and **not** on their latest version! Changing the text or coordinates of an original note (or previous comment) at a later time, (potentially) changes the meaning of all comments that were written between time where original text was written and its updated version. Also, some apps cache notes offline, which would further make determining on which version the reply was made problematic. Also, one should consider that there will be both old API apps and new API apps running at the same time for forseeable future, so they would need to work together without stepping on each other toes. I.e. in current Notes system it is extremely easy and efficient to follow the temporal ordering of events, just follow the "comments" by increasing ids/timestamps. Any clarifications or corrections are just another comment down the line. Making the comments text or coordinates mutable would totally break the workflow of all existing note consumers, and require all consumerts to convert to new API _and_ also invest significant effort to make sense of and avoid misinterpreting Notes, for no good reason. Also, how would the [Notes planet dump](https://planet.openstreetmap.org/notes/) change with mutable notes? It seems like a drastic change, perhaps even necessitating splitting to separate planet-notes and history-notes as we have for elements (compared to e.g. mere adding of note tags, which would probably just add "tags=" attribute to appropriate XML element, which would work as-is in most if not all data consumers, and is trivial change) -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/pull/5904#issuecomment-2877798403 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
