Jetpack: SSO: ensure that 'return to your site' link goes to correct page

Created on 22 Jun 2016  ·  6Comments  ·  Source: Automattic/jetpack

Steps to reproduce the issue

  1. Connect with Jetpack, turn on SSO, and add the jetpack_sso_bypass_login_forward_wpcom filter using:
add_filter( 'jetpack_sso_bypass_login_forward_wpcom', '__return_true' );
  1. Make sure you are are logged in to WordPress.com with any account
  2. Go to the login page for your site at yoursite.com/wp-admin
  3. Click on the 'Return to Your Site' link at the bottom of the sign in screen
  4. See that you are redirected back to yoursite.com/wp-admin instead of yoursite.com
    It looks like nothing is happening because it's the same page as before.

    What I expected

I expected to be redirected back to yoursite.com

SSO [Pri] Low [Type] Bug

Most helpful comment

I think you're describing the "Return to your site" link that's at the bottom of the Calypso/WP.com UI. If that's the case, I'd expect that that link sends the user back to $site/wp-admin.

Here's why. The flow roughly looks like this:

  • User goes to $site/wp-admin
  • User clicks "Log in with WP.com" button
  • User lands on WP.com/Calypso to approve the flow (if the user isn't already connected)

Since the user got to WP.com with the intent of logging in to their site, when they click the "Return to site" link, I think it makes sense that we send the user back to their site to log in.

That being said, things get weird with the bypass login form filter. When clicking the "Return to site" link, my guess is that you're essentially just refreshing the WP.com/Calypso UI since you are redirected back to your site and then redirected right back to WP.com/Calypso.

That is less than ideal. This is something that exists in the pre-4.1 SSO functionality as well.

I think the best way to fix it is that when a site has the bypass filter set to true, that we change the "Return to site" link to point to the site.

The issue is that right now, we don't know the value of these filters on the WP.com side. So, we have a few options.

  • We could sync those values in the old sync
  • We could wait for new sync where those values will begin to be synced
  • We could add a query parameter

cc @lezama to see what he thinks.

All 6 comments

I think you're describing the "Return to your site" link that's at the bottom of the Calypso/WP.com UI. If that's the case, I'd expect that that link sends the user back to $site/wp-admin.

Here's why. The flow roughly looks like this:

  • User goes to $site/wp-admin
  • User clicks "Log in with WP.com" button
  • User lands on WP.com/Calypso to approve the flow (if the user isn't already connected)

Since the user got to WP.com with the intent of logging in to their site, when they click the "Return to site" link, I think it makes sense that we send the user back to their site to log in.

That being said, things get weird with the bypass login form filter. When clicking the "Return to site" link, my guess is that you're essentially just refreshing the WP.com/Calypso UI since you are redirected back to your site and then redirected right back to WP.com/Calypso.

That is less than ideal. This is something that exists in the pre-4.1 SSO functionality as well.

I think the best way to fix it is that when a site has the bypass filter set to true, that we change the "Return to site" link to point to the site.

The issue is that right now, we don't know the value of these filters on the WP.com side. So, we have a few options.

  • We could sync those values in the old sync
  • We could wait for new sync where those values will begin to be synced
  • We could add a query parameter

cc @lezama to see what he thinks.

Your explanation makes sense to me @ebinnion and I'd be ok with leaving the link the way it is.

We could wait for new sync where those values will begin to be synced

👍

We are already syncing these values in new sync, but we need to address actually storing those filters on the WP.com side. I'll circle back once this is finished.

but we need to address actually storing those filters on the WP.com side.

we are already doing it \o/

This issue has been marked as stale. This happened because:

  • It has been inactive in the past 6 months.
  • It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

Was this page helpful?
0 / 5 - 0 ratings