Remove system-wide user authentication with a more typical approach

[fluiddot]

Related to #387.

Proposed Changes

Note

This patch won't be necessary when merging WordPress/wordpress-playground#1753 and updating the Playground dependencies. I decided to introduce the patch to resolve the issue as soon as possible.

• Patch php-wasm package to avoid injecting internally stored cookies in requests. This will allow the browser to manage and include the cookies in requests to the site, which is the typical behavior when navigating a site.
• Add a middleware to the Express server to allow auto-log-in via a query parameter. This is a workaround to address the lack of an auto-login feature that we previously benefited from the login step performed when starting.
• Update openSiteURL IPC handler to include the query parameter to ensure it auto-logs when navigating to the site.

Testing Instructions

Auto-login

• Run the command npm install.
• Run the app with the command npm start.
• Create a site.
• Click on WP admin.
• Observe the WP admin dashboard is displayed and you are logged in with the admin user.
• Open the URL http://localhost:<PORT>/wp-admin/ in incognito mode or a different browser.
• Observe it redirects to the login page.

Site buttons

• Run the command npm install.
• Run the app with the command npm start.
• Create/start a site.
• Click on each button of the Customize section.
• Observe that the page loads and you are logged in with the admin user.

WooCommerce API

• Follow the testing instructions from The system-wide user authentication implementation causes friction and breaks the WooCommerce REST API authentication #387.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[fluiddot]

Since the file is minified and it's quite hard to see the difference, here's the change that this patch applies:

• Remove setting the cookie header with value persisted in internal cookie store (original code).

[sejas]

@fluiddot Looks great!
I tested the happy path and also a couple of edge cases. It worked great.

Do you think we should remove the autologin from wp-now?

studio/vendor/wp-now/src/wp-now.ts

Lines 369 to 372 in 9b4a088

	wp_set_current_user( $user->ID, $user->user_login );
	wp_set_auth_cookie( $user->ID );
	do_action( 'wp_login', $user->user_login, $user );`

Screencast

BKs7o8.mp4

[sejas]

nice!

[sejas]

I was considering to add an early return if the autologin fails. For example if the user has changed the password, then I was expecting this code would override the cookies and logout the user, but on the contrary it works like a charm.

I also tried with manual logout, and then using any of the wp-admin buttons and I was redirected to the login screen without any URL parameter, which seems the best flow for the user to enter their credentials.

So no need to add any changes 👍

In any case, If the user restarts the site, the password will be overwritten.

[fluiddot]

I was considering to add an early return if the autologin fails. For example if the user has changed the password, then I was expecting this code would override the cookies and logout the user, but on the contrary it works like a charm.

Good observation. Actually, the cookies are being rewritten with the response from wp-login.php and auth cookies are removed.

I also tried with manual logout, and then using any of the wp-admin buttons and I was redirected to the login screen without any URL parameter, which seems the best flow for the user to enter their credentials.

So no need to add any changes 👍

In any case, If the user restarts the site, the password will be overwritten.

Exactly, the admin credentials will be updated when the user restarts the site. There's an alternative that would cover this case by using a plugin that performs the auto-login. We actually discussed this in a Playground PR that will serve as a long-term fix for this problem.

For now, I think we can go with this approach and when WordPress/wordpress-playground#1753 (comment) is merged and included in the app, this case will be solved.

[wojtekn]

The code change looks good, and the feature works as expected.

I see one thing I would like to validate. It makes sense to have auto-login working automatically for all links pointing to WP Admin, including those from the Customize section.

However, should 'Open site' and thumbnail point to the frontend without auto-login instead?

[fluiddot]

[...] Do you think we should remove the autologin from wp-now?

studio/vendor/wp-now/src/wp-now.ts

Lines 369 to 372 in 9b4a088

	wp_set_current_user( $user->ID, $user->user_login );
	wp_set_auth_cookie( $user->ID );
	do_action( 'wp_login', $user->user_login, $user );`

Screencast

BKs7o8.mp4

@sejas Good question. Yep, I think we can remove it. However, we need to keep the logic that creates the admin user. Since it doesn't disrupt these changes, I'll do it in a separate PR.

[fluiddot]

[...] I see one thing I would like to validate. It makes sense to have auto-login working automatically for all links pointing to WP Admin, including those from the Customize section.

However, should 'Open site' and thumbnail point to the frontend without auto-login instead?

I don't have a strong opinion on this, but we could disable auto-login for this case 👍 .

[wojtekn]

I don't have a strong opinion on this, but we could disable auto-login for this case 👍 .

It feels more natural to me. For example, I could quickly review how my site's frontends look for logged-out users, while still all WP Admin links would automatically sign me in.

[fluiddot]

I don't have a strong opinion on this, but we could disable auto-login for this case 👍 .

It feels more natural to me. For example, I could quickly review how my site's frontends look for logged-out users, while still all WP Admin links would automatically sign me in.

Yeah, good point. However, I'd like to note that if you navigate to WP-Admin (you will be auto-logged) and then to the home page, you will see the page as a logged user.

In any case, I've addressed this in 65f2386.