Skip to content
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

Closed
milan-cvetkovic opened this issue Sep 13, 2023 · 38 comments

Comments

@milan-cvetkovic
Copy link
Contributor

milan-cvetkovic commented Sep 13, 2023

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:

  1. User initiates authorization of the app with OSM from the 3rd party app
  2. User sees OSM login page, and choses to Sign-up instead, since they do not have OSM account.
  3. User fills up email, password, display name, and submits the form.
  4. User accepts the terms, and confirmation email is sent to them
  5. After clicking the link in the email, they see "welcome" screen. The authorization of the 3rd party app has been interrupted.

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:

  1. User initiates authorization of the app with OSM from the 3rd party app
  2. User sees OSM login page, and choses to use one of "Log-in with..." buttons.
  3. User fills up display name, clicks "Sign-up"
  4. User accepts the terms, and submits the form
  5. If email verification is not performed, user would be redirected directly to "welcome" page. The authorization of the 3rd party app has been interrupted.

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:

  1. Skip "welcome" screen entirely if creating the user is initiated from Oauth flow:
    • If there is no email confirmation, after accepting the terms, user would be redirected to authorization page
    • If confirmation email is sent, the link in the email would redirect user directly to authorization page, after potentially having them sign-in if necessary
  2. Add an additional "Continue with Authorization" button to Welcome screen that would be displayed only during Oauth flow. Again, even when user came to "welcome" screen from confirmation email, the Continue button would actually redirect them to authorization page.

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

@gravitystorm
Copy link
Collaborator

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

@grischard
Copy link
Contributor

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.

@stalker314314
Copy link
Contributor

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!

@pnorman
Copy link
Contributor

pnorman commented Sep 21, 2023

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?

@grischard
Copy link
Contributor

grischard commented Sep 21, 2023

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.

@stalker314314
Copy link
Contributor

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

@stalker314314
Copy link
Contributor

Heya, friendly ping!:)

@tomhughes
Copy link
Member

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?

@stalker314314
Copy link
Contributor

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!

@tomhughes
Copy link
Member

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?

@mmd-osm
Copy link
Contributor

mmd-osm commented Oct 3, 2023

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.

@stalker314314
Copy link
Contributor

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

@matkoniecz
Copy link
Contributor

matkoniecz commented Oct 5, 2023

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.

@tordans
Copy link
Contributor

tordans commented Oct 5, 2023

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

@tomhughes
Copy link
Member

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.

@tordans
Copy link
Contributor

tordans commented Oct 5, 2023

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.

image

@milan-cvetkovic
Copy link
Contributor Author

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.

@AntonKhorev
Copy link
Collaborator

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.

@AntonKhorev
Copy link
Collaborator

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.

@AntonKhorev
Copy link
Collaborator

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

@lonvia
Copy link
Contributor

lonvia commented Oct 19, 2023

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.

@tomhughes
Copy link
Member

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

@stalker314314
Copy link
Contributor

If I read the description text of this issue, then the actual problem is the interruption of flow because of the confirmation email,

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

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

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

@AntonKhorev
Copy link
Collaborator

user cannot go back from welcome screen to originated application that issues singup request

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.

@stalker314314
Copy link
Contributor

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?

@stalker314314
Copy link
Contributor

stalker314314 commented Oct 19, 2023

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)

@milan-cvetkovic
Copy link
Contributor Author

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.
...
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 :-(

@tomhughes
Can you please clarify what you had in mind - did you envision complete substitution of welcome page with welcome emails?

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, en.yml appears to be organized in such a way that it discourages reusing strings. I would be grateful for a proposal for under which root to place those messages to be shared between mail and html.

@tomhughes
Copy link
Member

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.

@milan-cvetkovic
Copy link
Contributor Author

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.

@milan-cvetkovic
Copy link
Contributor Author

milan-cvetkovic commented Nov 8, 2023

@AntonKhorev

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.

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 user_tokens table, and welcome page if it is displayed) drive the user to the same authorization link: /oauth2/authorize?.... If the invoking application is still up and the timeout set by the invoking app has not been reached, the authorization would complete successfully.

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:

  • the user needs to use same browser for initial authorize request and confirm-email request
  • the client application needs to be running without restart
  • the whole authorization process needs to be complete in relatively small time frame. In my tests, the authorize link expires in about an hour. Note that the similar behaviour would be triggered if user simply sits on authorize screen for long time in any scenario.

@AntonKhorev
Copy link
Collaborator

I'll copy this again and note that this is on top of some limitations:

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

The link in the email would (...) drive the user to the same authorization link: /oauth2/authorize?.... If the invoking application is still up and the timeout set by the invoking app has not been reached, the authorization would complete successfully.

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

@milan-cvetkovic
Copy link
Contributor Author

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?

@AntonKhorev
Copy link
Collaborator

Web app opens a popup window:
https://github.com/osmlab/osm-auth/blob/8744617fa7f318e769c39e0e314c4fe537d26ec6/src/osm-auth.mjs#L133

and sets up a callback for it:
https://github.com/osmlab/osm-auth/blob/8744617fa7f318e769c39e0e314c4fe537d26ec6/src/osm-auth.mjs#L195

When the redirect landing page is reached in the popup window, the callback is invoked on the opener window:
https://github.com/osmlab/osm-auth/blob/8744617fa7f318e769c39e0e314c4fe537d26ec6/land.html#L5

If another window gets to the redirect landing page, there's no opener with the callback.

@milan-cvetkovic
Copy link
Contributor Author

@AntonKhorev thanks for the links, will look into them after SOTM.

@pietervdvn
Copy link

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:

  1. They get invited to add some feature, e.g. a charging station for e-bikes. (The touristical agency of Flanders did do a campaign about this and sent out emails to municipalities with a link to MapComplete)
  2. The user clicks 'add feature' and is asked to 'sign in' before adding an actual feature in MapComplete
  3. The user registers a new account and runs through the current flow
  4. The user is dropped into either iD, which looks very confusing - or they might click the 'add a note instead' or go back.

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.

@AntonKhorev
Copy link
Collaborator

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

The user is dropped into either iD, which looks very confusing

If you do 5th bullet point of changes from #4246 (comment) nobody is getting dropped into iD.

@milan-cvetkovic
Copy link
Contributor Author

milan-cvetkovic commented Nov 14, 2023

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

  • new user is registered with OSM
  • application is authorized with OSM
  • popup window displays "We have sent you confirmation email" page. It is not and cannot be closed by link in the confirmation email.
  • the browser tab opened by confirmation email does not work properly. Note that this page is hosted by the client app - in osm-auth's land.html in this example. In many cases, developers of the client app could mitigate this behaviour by specifying return_url which would actually refresh the page in question.

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.

@milan-cvetkovic
Copy link
Contributor Author

Since #4329 has been merged, this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests