Welcome page interrupts Oauth authorization flow for newly created OSM accounts about openstreetmap-website HOT 28 OPEN

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).

from openstreetmap-website.

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.

from openstreetmap-website.

Are third-party apps going to keep up to date with all the changes and translations?

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 /welcome screen, one can see it is mixture of community norms, but also sprinkled with introduction to iD editor (not all editors use node/way/tag models visible) (to be clear, for Map builder, we will also need to have "don't copy from g" communication)

We could serve the "inner" html to be rendered in the user's environment

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 think it needs to be osm.org.

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 /welcome page, but I think we can benefit with some changes (for example, I would remove "basic terms for mapping", "start mapping" and "Add a note" parts while replacing them with some text that explains that users can visit openstreeetmap.org and that there are other editors available there). In a distant future (not sure if we can do this), we can detect bounced mails and decide what to do if we can detect them (disable user until mail is changed?, notify user with some banner when they visit osm.org?...)

from openstreetmap-website.

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 /welcome page

I think it needs to be osm.org. Are third-party apps going to keep up to date with all the changes and translations?

from openstreetmap-website.

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?

from openstreetmap-website.

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:)

from openstreetmap-website.

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

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 highway=motorway by droga=autostrada would need to be fixed or eliminated and stopped. This does not change that apps are developed independently and have some autonomy in their tagging schemes and which tags are presented, used. But it is not a full autonomy. Similarly, adding this_edit_was_sponsored_by=Coca Cola or visit_this_link=blatantscam.example.com to buildings would be beyond what editor or mapper is allowed to do.

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.

from openstreetmap-website.

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.

It would also make the email a bit more complex when we want to create a wording-bridge to the previous step.

We can have parametarization to solve both of these - to reuse complete, existing welcome.html.erb and render it in mail with slight "if email" tweaks. We would not add name of application (in your example "StreetComplete") to email, though.

I just noticed that the email confirmation email likely also needs a change depending on which flow is used afterwards.

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.

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?

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.

from openstreetmap-website.

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.

[...]

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.

Here's what josm means by "semi-automatic":
https://josm.openstreetmap.de/wiki/Help/Dialog/OAuthAuthorisationWizard#Semi-automaticauthorisationprocess

"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.

from openstreetmap-website.

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 /welcome page! When/if user visits later osm.org or osm.org/edit, it should be given opportunity to see welcome page. But in OAuth signup flow, yet another dialog to click is just hurting conversion rate (both for third-party app and for OSM). Does this makes sense to you?

If it is, let me immediately give one possible proposal. We would work on implementation (with your hand-holding when necessary):

• We introduce new bool column in users table named welcome_seen (defaults to true, not null) (we think there is no perf hits/locks in postgres to do this, even in huge tables)
• All existing users would have welcome_seen set to true, as /welcome page is seen (honors current reality).
• When new user is created in DB, we set this to false initially.
• As login flow continues to guide users to /welcome page, /welcome page (on GET request) sets this bit to true for currently logged-in users (this can be done unconditionally, as this bit can never go true->false)
• OAuth signup skips /welcome page and keep welcome_seen to false.
• We add checks in / and /edit routes to read welcome_seen field and either show nice HTML closable dialog, or just simply redirect users to /welcome page reusing current page (but keeps redirects and URL parameters to bring user back where they originated from).

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!

from openstreetmap-website.

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.

from openstreetmap-website.

Heya, friendly ping!:)

from openstreetmap-website.

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?

from openstreetmap-website.

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 welcome_seen and one with sending welcome mail. @pnorman had comment on first, @mmd-osm was confused with second. If it was up to us, we can go and implement mail version, but we want to reach some sort of consensus (as much as it is possible). But, if you think there is no blockers here, we will start working on PR for mail!

from openstreetmap-website.

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.

from openstreetmap-website.

@stalker314314 just to be sure, this is the implementation you are proposing:

(From your comment in #4246 (comment))

• For Users that register via the website, nothing will change
• For Users that register via your App (that uses the new flow), the last step of the registration which is the welcome screen will be skipped. Instead those uses will receive a welcome e-mail that provides more or less the same information as the welcome screen does today

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?

from openstreetmap-website.

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.

from openstreetmap-website.

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:

You just signed up via StreetComplete. Here are some thinks you should know about OSM in general.

vs.

You just created an account on openstreetmap.org. Here are some thinks you should know about OSM before you start mapping.

@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.

from openstreetmap-website.

Ideally, clicking on the link in email would continue authorization process, but I am not sure if this is reasonable.

This won't work for some apps. An app may open https://www.openstreetmap.org/oauth2/authorize in a specific browser window and expect redirect back to itself in that window. If you're opening a confirmation link from an email client, you're not in that window anymore.

from openstreetmap-website.

Here's what I'd try to do first:

what's already happening:

• when a user without an osm account tries tries to authorize from some app, they first are directed to /oauth2/authorize
• since the user is not logged in, they are redirected to the login page

changes:

• On the login page we detect if it was a redirect from oauth. If it was, a regular registration link is replaced with a link that opens in a new browser window.
• we add a message near the link telling the user to complete the registration in that other window and return to the original window after that
• instead of a redirect url, we add some parameter to our new link that indicates that the user came from oauth
• if a email confirmation is used, this parameter is stored in the token accessible with the confirmation link
• when the welcome is reached, it has a "start mapping" link that normally uses the stored redirect. Instead, if we have the "came from oauth" parameter, we put there a message to return to the original window to continue the oauth flow
• the original page doesn't know that the registration was complete until it's reloaded, so we also tell the user to reload it once they are registered
• reloading with the usual browser controls may not be possible if the window is fully controlled by the app, so we may place a reload button there

from openstreetmap-website.