-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Welcome page interrupts Oauth authorization flow for newly created OSM accounts #4246
Comments
I would change the requirements here, so that the user "is always given the opportunity to read the welcome page". I agree that the current situation doesn't work well for signups via Oauth authorisation flow, as you describe. But it's still important that new users see this page, and it's not obvious how a user would stumble across it otherwise. I'm open to suggestions as to how this is done - for example, a post-signup welcome email, or a temporary banner on their dashboard, or something entirely different, or somehow integrated into the authorisation flow so that it's shown on their screen (e.g. making the return-to-application occur in a new tab, or similar). |
The welcome page does take care of telling the user what our norms are, such as "don't copy other maps" - so I see it as mostly a feature, or as a necessary pain. |
Yes, I almost agree with requirement (as you @gravitystorm put it). I would just append to it "when on openstreetmap.org website". It is about making sure that message(s) contained in welcome screen are delivered to the user. I think it is up to third-party app's responsibility to deliver these messages in a manner that is as similar and as prominent as If it is, let me immediately give one possible proposal. We would work on implementation (with your hand-holding when necessary):
We don't mind other solutions as well (for example with welcome being mail), but it is really important that OAuth signup flow is uninterrupted and that conversion is maximized. Feel free to comment on proposal (does it make sense at all, any problems...), and let's come up with solution that works for all! |
I think it needs to be osm.org. Are third-party apps going to keep up to date with all the changes and translations? |
We could serve the "inner" html to be rendered in the user's environment, whether that's the website or a third app. At the same time, we can reinvent the registration flow to show the message at another time - the important part is the communication of community norms, not registration taking lots of steps. |
Are third-party apps keeping up to date with tags?:) My take is that third-party apps should have fundamental sovereignty to decide what they present to user when they interact with them. Same as how they have full autonomy to decide what tags they will use or how notes will be uploaded or how big bbox of changeset should be. And it is up to community and OSMF to keep those apps in check and that they don't go rogue. Furthermore, welcome screen is not legal requirement, it is just something that makes sense for general-purpose editor, but it is not very well fit for all editors (for example, I would argue that StreetComplete could have completely different welcome screen if they can choose). Looking at current
This could complicate both OSM codebase while 1) we still couldn't enforce third-party apps to show it and/or 2) it will still hinder on signup flow. For context, Map builder would like to present this dialog when session start, not when user is signed up (which happens after user clicks "save")
I tried to argument it above why I still think third-party apps should be given more agency, but if you still think osm.org need to show it (please reconsider), let's explore other, "mail approach". So, in this case, signup over osm.org will be same as today. But, for signup over third-party apps, we would skip welcome screen, and at that point, we would send "welcome" mail to users' mail address. This mail have html+plain text content that is similar to |
Heya, friendly ping!:) |
What exactly are you pinging? This is an issue not a PR so until somebody steps up to address it there is nothing to do here? |
Sorry, I was under impression that it would be good if we agreed on something before we go dive into implementation. There are two potential solutions - one with adding |
I'm fine with either solution - the email method sounds simpler and I might slightly lean towards that anyway but other people may think differently. As far as comments go the only thing I see @pnorman saying is that the message needs to come from osm.org but both solutions achieve that so I'm a bit confused about where the problem is - it seems he was replying to a comment in your message that didn't really relate to the actual solution you proposed. It was only later that other people suggested maybe outsourcing the display of the text to the third party which I agree is not a good idea. I don't see any comments from @mmd-osm at all so I'm not sure what you mean by that? |
Well, there wasn't really any comment, only a "confused" reaction (visible as emoji). This "confusion" was more about the general idea of "[...] third-party apps should have fundamental sovereignty to decide what they present to user when they interact with them" being applied to the sign up process as well. This is a fairly unique requirement, and no other editing app has ever requested anything similar, iirc. I didn't question the email approach. An emoji simply cannot reliably convey what the confusion is about. |
Thanks @mmd-osm , I understand now why that reaction. We just wanted to err on safe side when designing this:) I agree it is kind of "philosophical" question that we can leave for now (since we will try to implement mail approach) @tomhughes Thanks for feedback, we will try to go with welcome mail approach, I also lean to it. We will also try to "evolve" welcome page for (async) world of mail, as I explained, stay tuned for PR:) |
I disagree with both (as OSM mapper and someone spending a lot of time on editor development). Apps do NOT have full autonomy to decide what tags they will use. https://wiki.openstreetmap.org/wiki/Any_tags_you_like exists but has limit. Editor that for example replaces Similarly editors do not have full autonomy in what is presented to users. For example, showing message "you can improve map by copying shops from Bing Maps and delete ones not listed there" would be unacceptable. Authorisation flow via 3rd party apps can be improved but it should be ensured that user will be aware that they are contributing to OpenStreetMap and 3rd party app is one of editors that enables to use OSM account. And that they are obligated to follow some community rules. |
@stalker314314 just to be sure, this is the implementation you are proposing: (From your comment in #4246 (comment))
I wonder what to do with existing apps. Should they be migrated to the new flow automatically or should they stay with the existing flow until they opt in. And how would the opt in work? Are there downsides to migrating them automatically? |
If we're making the change to email I would assume it would happen for everyone. I'm not keen on the idea of having two versions of the information (which will doubtless get out of sync) depending on how you sign up. |
I agree on the issue of keeping information in sync. At the same time, it is a more radical change than what I understood was proposed before. If I where asked to create a good onboarding for the website now, I would still go for a flow as it is now because it gives a bit more certainty that users actually saw the info before starting to work. It would also make the email a bit more complex when we want to create a wording-bridge to the previous step. That could be something like a text snipped that is based on the registration source:
vs.
@stalker314314 I just noticed that the email confirmation email likely also needs a change depending on which flow is used afterwards. There is this sentence "Nach der Bestätigung deines Benutzerkontos geben wir dir zusätzliche Informationen, um anzufangen." which is true for the welcome page flow but not really for the email flow. ![]() |
We can have parametarization to solve both of these - to reuse complete, existing
Yes, we will account for that, but having mail confirmation is already breaking signup flow. Ideally, clicking on the link in email would continue authorization process, but I am not sure if this is reasonable.
Currently 3rd party apps initiate "Oauth2 authorize with OSM" in order to obtain access token. This triggers the sign-in to OSM if the user is not signed in to OSM already. If the user does not even have OSM account, they would have to create one. Suggested modification of behaviour in OSM is at the moment when the email address is confirmed for these users, signing up as a result of Oauth2 authorization. Instead of driving them to "welcome screen", we would send them a "welcome email" and proceed to "OSM OAuth2 authorization" screen, which is in fact what they wanted to do. I do not see any downsides from the point of view of 3rd party apps. Other than maybe having to remove descriptions that the authorization would have to be initiated twice, due to OSM welcome screen. For example, it would be appropriate to remove "semi-automatic" from the relevant screen in JOSM. All third party apps would be treated same, since the decision is based on "is this signup due to authorization or not". The behaviour for OSM signup which is not a result of Oauth2 authorization would remain same as of today. |
This won't work for some apps. An app may open |
Here's what josm means by "semi-automatic": "semi-automatic" = users have to interact with the authorization dialog on the osm website. This is still going to happen, no matter what changes are made to email confirmations and welcome pages. |
Here's what I'd try to do first: what's already happening:
changes:
|
I'm still very confused here as I don't understand why the welcome page is supposed to be the problem. If I read the description text of this issue, then the actual problem is the interruption of flow because of the confirmation email, which is one step before the welcome screen is even shown. Even with pre-confirmed emails this looks to be the root cause, it is just not externally visible because it is skipped for the user. In that context, @AntonKhorev's suggestion makes a lot more sense to me than #4288. Just fix the flow of information wrt oauth authorization instead of hacking around it for the rather narrow use-case of sign-up with pre-confirmed emails. |
Well I made it very clear that if we were going to change how the welcome page is displayed then it should be for all signups not just those happening via OAuth but the PR seems to have ignored that :-( |
I guess confusion comes because there are multiple interruption flows (what we identified). They are discussed broadly in #4128 . And because it can be confusing, we decided to focus here only on "welcome page" issue. One interruption is for confirmation mails, yes, but this interruption is because "welcome" page is stopper - user cannot go back from welcome screen to originated application that issues singup request and this PR fixes it. I guess original text of this issue clarified this better than me here:)
If you noticed in PR, @milan-cvetkovic commented on it and requested help how best to extract/pull welcome page text to be referenced by both mail and html parts. It is not that we ignored it or that we don't want to do it, but more that we need guidance on this:/ |
This is true if users arrive at that page from confirmation emails (opened in whatever email client which then opens the link in whatever browser, all of this happening after whatever delay with email delivery). Otherwise you can put a link on the welcome page to continue the oauth flow. |
As you can see, it was our second proposal (in original post). Since nobody was for it (except you, but we already started with PR, sorry for this!) and @tomhughes was leaning more towards first (#4246 (comment)), we did first proposal for PR. Proposal with "continue" in welcome page has its downsides (as we discussed here in #4246 (comment), not to repeat myself, most notably different context from someone coming from Street Complete/Map builder and someone clicking on "Edit"), but it is not clear cut (at least to me) which is objectively better. I would like to hear opinions from other people wrt should we go with first vs second proposal (I guess both @lonvia and you @AntonKhorev are for second proposal). If we go with second proposal, I think welcome message needs to be changed a bit, as it is both welcome greeting for OSM and for iD (for example, section that explain what is node, what is way is something that is completely orthogonal to welcoming users to OSM and is more appropriate to users first time seeing iD, as well as "Start mapping" section as it can be confusing to people coming from other editors). And if we remove "what is node, what is way", do we need to add it to "first time usage"/new welcome dialog in iD, or we can say that current tutorial in Id covers it? |
Oh, forgot to add - consider that every additional dialog substantially drops amount of people that started signup process. Of course, OSM is not driven by quantity but quality, but still, if it is something that can be read in async fashion, I am also slightly more inclined to welcome mail (first) proposal (but I have no stake here, if majority is for second proposal - great, that's why I am inviting people to join discussion) |
@tomhughes I tried to keep the flow unaffected for users signing up with OSM directly - they end up on Welcome page after confirming the email (by clicking the link in the email). I had hoped to reuse the same set of messages when generating email for signups due to Oauth authorization request. However, |
That was what I suggested, yes, to send it as an email for all users. It started as an attempt to avoid duplicating the content but I wonder if it isn't better in some ways anyway? It means people don't just see it once but can refer back to it if they wish? It's easy to argue both ways though. |
I created earlier Send welcome email instead of redirecting to welcome page when creating user from authorization #4288. I have created an alternative PR addressing this issue - Welcome screen shows "Continue with authorization" when OSM account created from authorization flow #4329. It addresses this issue by always displaying the welcome page when a new OSM account is created. However, it replaces the "Start Mapping" button with "Continue with authorization" button, which leads the user to "Authorize" screen. |
This will work for all apps even when confirmation email is required, subject so some limitations. The link in the email would (indirectly, through the entry in In case of too much time passed, the link from email would complete the creation of OSM account, but the authorization link would fail, and user would have to repeat the authorization request from the client app. However, this time the user need not create an OSM account (since they already have one) and the authorization request would result in OSM displaying authorize screen immediately. The limitations are:
|
I'll copy this again and note that this is on top of some limitations:
It won't if the app expects the redirect in another window, even if the browser is the same (and in general it's not the same). |
I am not sure what you mean when you say: "app expects the redirect in another window". Web applications expect redirect in the browser. Native applications would normally have to open a listening port and expect redirect to that port on localhost. I believe JOSM works this way. JOSM authorization works across email confirmation with both PRs. Is there something I am missing? Can you give an example where the app would expect redirect to another window? |
Web app opens a popup window: and sets up a callback for it: When the redirect landing page is reached in the popup window, the callback is invoked on the opener window: If another window gets to the redirect landing page, there's no opener with the callback. |
@AntonKhorev thanks for the links, will look into them after SOTM. |
I'm the author of MapComplete.org, and I do know that a lot of people drop out or get utterly confused when they follow the signup. A typical journey is:
A pull request like #4329 would help a lot and, even though it'll won't work in some cases, it'll help in many other cases. |
@pietervdvn Have you checked that #4329 works with MapComplete.org? You're using osm-auth which is not going to work in general and you have some logic choosing whether to enable its single-page mode.
If you do 5th bullet point of changes from #4246 (comment) nobody is getting dropped into iD. |
@AntonKhorev I have tested #4329 with osm-auth demo app. I found out that you are correct that clicking a link in email does not close the window from which the email was originally triggered (2nd browser window appearing as a popup). Instead, it opens up the new tab in the default browser and continues the authorization process - if this is the same browser, and if it was clicked within a reasonable time. The final state is:
Similarly, in single page mode "We have sent you confirmation email" page stays untouched after user clicks the link in confirmation email, and the authorization is completed in the newly opened tab or window. In summary, I believe that #4329 does not degrade UX in any scenario, but significantly improves it when confirmation email is not required, and in many cases when it is. |
Since #4329 has been merged, this issue can be closed. |
Problem
When a first-time user of a 3rd party app attempts to make a contribution to OSM, they have to create an OSM account and authorize the 3rd party app to act on their behalf - modify maps, read profile. Here is the typical scenario when user creates OSM account with username/password:
To complete the authorization user needs to restart the process by initiating authorization of the app with OSM again, when
OSM displays authorization screen, after accepting it, the authorization is completed. Typical web application would regain control of the flow at this time.
Similar flow happens when user uses "Login-with" instead of creating username/password OSM account. When email verification is not necessary, this becomes the only step where the flow is terminated:
To complete the authorization user needs to restart the process by initiating authorization of the app with OSM.
I have observed this behaviour with several applications, JOSM, osmcha, Map builder, to name a few. I believe it is named "semi-automatic" in JOSM for this reason.
Description
Prevent "welcome" screen to interrupt Oauth flow in the above scenarios.
Proposal, one of the following:
I would prefer the former, simply due to having one click less to "the end of the tunnel."
Creating this issue for more detailed discussion of single topic mentioned in #4128.
Screenshots
No response
The text was updated successfully, but these errors were encountered: