Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.41k stars 1.99k forks source link

Cookies / Admin bar: Atomic sites not seeing WordPress.com admin bar even though user is logged in #52046

Open wpshellbelle opened 3 years ago

wpshellbelle commented 3 years ago

Steps to reproduce the behavior

  1. Go to WordPress.com and confirm you are logged in as a user on an AT site
  2. Visit your AT site (for example, visit https://example.com/ without accessing anywhere else in the same web browser) and check out the admin bar showing:

  1. Visit WP Admin for that site: https://example.com/wp-admin
  2. Visit https://example.com/ again. Check out the admin bar again after visiting WP Admin and then visiting the site via htts://example.com:

What I expected to happen

I expected to see the WordPress.com admin bar as long as I was logged into WordPress.com.

What actually happened

I saw the WordPress.org bar instead of the WordPress.com admin bar if I didn't visit WP Admin

Does this happen on simple or atomic sites or both?

AT sites

User reported: 29090049-hc

obenland commented 3 years ago

@wpshellbelle Is there any more information you can share as to how to reproduce this?

Does this happen on all your Atomic sites? Only with certain plugins enabled? Only with certain themes?

edwinho89 commented 3 years ago

Hi @obenland I followed the same steps by logging in to a user on a private browser first, and was able to reproduce the same. If the user account had previously accessed wp-admin of the site in the current web browser, the WordPress.org bar will not appear.

The issue is reproducible on AT sites without custom plugins enabled, and on any themes.

obenland commented 3 years ago

@edwinho89 Thanks so much for your update! It turns out I still need a little more handholding, I'm afraid :)

I looked at the store admin of the reported user to switch to the user to reproduce the bug. Once I’m logged in to Calypso, I switched the site specified in chat. Clicking on Plugins to get to their wp-admin drops me in a SSO error page.

Am I doing something wrong?

zdenys commented 3 years ago

I looked at the store admin of the reported user to switch to the user to reproduce the bug. Once I’m logged in to Calypso, I switched the site specified in chat. Clicking on Plugins to get to their wp-admin drops me in a SSO error page.

@obenland you'd need to:

  1. SU the user and you should land to https://wordpress.com/stats/day Link: https://d.pr/i/2C6yFB
  2. At this point, you don't need to click anything in Calypso but rather visit the user's site URL directly in a new tab
  3. See that the toolbar is the WordPress.org one Link: https://d.pr/i/aVdlkX
  4. Visit WP Admin of the site at this point and see that the toolbar changed to the WordPress.com one Link: https://d.pr/i/5VWh2j
  5. Go back to the user's site URL directly and see that the WordPress.com toolbar stays Link: https://d.pr/i/Kbveo9

In other words, the WordPress.org toolbar will be the one you see on the front end of the site until you visit WP Admin at least once.

tjcafferkey commented 3 years ago

Investigate a work around, potentially mock the first load if we can't find another solution.

mmtr commented 3 years ago

Seems this is happening because the remote login process that is performed when a user logs in from wordpress.com/log-in does not work currently on Atomic sites.

The 3rd party cookies pod is currently working on improving these flows, so I asked them if they can take over this issue (see p1621586041027700-slack-C01V2160U15).

cc @niranjan-uma-shankar

potentially mock the first load

I wouldn't recommend this, since it can degrade the performance as the result of making a wp-admin request for each logged out visitor visiting the frontend. The ideal fix would be to perform a remote login when the user logs in from wordpress.com/log-in.

niranjan-uma-shankar commented 3 years ago

The 3rd party cookies pod is currently working on improving these flows, so I asked them if they can take over this issue (see p1621586041027700-slack-C01V2160U15).

Just to clarify, the 3rd party cookies pod is currently focused on simple sites. We haven't yet reached the point of discussing or triaging atomic site issues. I've added this issue to our project board for tracking, but I don't have a time frame defined at the moment on when we can get to this.

mmtr commented 3 years ago

Thanks @niranjan-uma-shankar. I'll also keep it in our board, in case we have room for working on it first. We are currently prioritizing small issues (and there are plenty of them), so it's likely that we won't be able to fix this before the end of the "Back to Basics" plan.

Sandkorner commented 3 years ago

Would that be something that might be worked on in the near future? The same user is asking for an update and maybe I can give them some information regarding this.

JoshuaGoode commented 3 years ago

This also impacts "Edit" links as they won't appear until the cookie is set.

This also forces site owners that have Private or Coming Soon sites to use the provided "log in" buttons or access their WP-Admin in order to view the site.

Recent internal discussion:

Copons commented 3 years ago

Just FYI, we have removed the Nav Unification label as this issue is about the masterbar rather than the unified sidebar. If it was an error on our part, please feel free to readd the label! 🙇‍♂️

jorpdesigns commented 2 years ago

I think this bug is also affecting the "Edit" link seen at the bottom of pages and posts on the front end.

By default, the link does not show:

editlink1

After visiting WP Admin and reloading the same page, I can see the link:

editlink2

Reported in 5206358-zen

cometgrrl commented 2 years ago

I can reproduce this, but I only see the WordPress.org masterbar when I'm proxied.

@Automattic/build Can y'all look into this? It's been open for quite some time and seems like a pretty big annoyance/missing feature for our Atomic users (who might not use wp-admin).

github-actions[bot] commented 2 years ago

Support References

This comment is automatically generated. Please do not edit it.

vykes-mac commented 2 years ago

This is what I discovered so far, I realise that the masterbar.css file along with other wp-com css files not loading when I visit an AT site that hasn't yet access wp-admin. I suspect some of the jetpack modules might not be loaded so I append _cli to the url, run the command jetpack module list I see the masterbar is active. After I return to my site url now the correct admin bar is present. I suspect this might have something to do with when the masterbar module is activated, I'll continue to check.

JoshuaGoode commented 2 years ago

I'd like to highlight https://github.com/Automattic/wp-calypso/issues/52046#issuecomment-945901653

I suspect this might have something to do with when the masterbar module is activated, I'll continue to check.

Overall, this is due to users not being in a logged-in state until they visit a /wp-admin/ resource -- which sets the necessary cookie.

Once they have the cookie, they'll get the bar and other admin/editor features, like page/post edit links. We force the masterbar module active and utilize it for nav unification, so it should be cookie rather than module @vykes-mac.

This is because the 3rd party cookies pod work didn't include Atomic and we aren't setting cookies for Atomic sites by just logging into WPCOM, like we do for Simple.

The cookie is wordpress_logged_in_xxxxxxxxxxxxxxxxx

vykes-mac commented 2 years ago

Thank you @JoshuaGoode for that information, It would seem that accessing cli executed whatever codepath is executed from wp-admin to set the necessary cookie and caused it to work.

tanjoymor commented 1 year ago

Just checking if this is still being looked into? I had a very confused user who couldn’t figure out how to access their dashboard after upgrading to the Business plan and the site went Atomic. Previously they always accessed it by going directly to their site’s URL and then clicking on My Sites. This is no longer possible if they have not yet been to a WP Admin page.

danielbachhuber commented 1 year ago

@tanjoymor This is on hold. There aren't any active plans to address it, largely because of the technical limitations discussed earlier in the thread.

cometgrrl commented 1 year ago

@danielbachhuber I just moved one of my sites over to dotcom, and ran into this issue. It's very confusing as a user to not understand why things aren't showing up as expected.

Any chance we could revisit fixing this issue?

danielbachhuber commented 1 year ago

@cometgrrl No plans to spend time on this in the near future. When a solution comes, it will likely come with work around authentication + third-party cookies.

cuemarie commented 1 year ago

📌 ACTIONS

autumnfjeld commented 5 months ago

Going to remove this from the Quake board.

mrfoxtalbot commented 5 months ago

This issue came up in 8255814-zd-a8c More context in p1717667575189049-slack-C03TY6J1A