I'm curious whether this has anything to do with #1539 and will grab this to test after the other PR is merged.

@brandonpayton thank you for the support!

When I investigated briefly, the permissions check unexpectedly returned false. If I recall correctly, when I logged $this->capabilities on the user class, it was empty.

@dcalhoun, it looks like the auth is not working for some reason. I'm getting the same message, and if I instrument the permissions check to error_log get_current_user_id() the value is 0.

Hoping to look into this a bit more later.

@dcalhoun After some debugging, it looks like Playground is auto-sending cookies and interfering with application password auth. Here's how:

Playground is auto-sending login cookies here:

When Playground auto-adds cookies to these requests that contain Authorization headers, it causes WordPress to skip evaluation of the application password. Instead, cookie-based auth initially succeeds in an earlier filter here:

add_filter( 'determine_current_user', 'wp_validate_auth_cookie' );
add_filter( 'determine_current_user', 'wp_validate_logged_in_cookie', 20 );
add_filter( 'determine_current_user', 'wp_validate_application_password', 20 );

Then when rest_cookie_check_errors() looks for the nonce required by the REST API for cookie-based auth, it finds there is no nonce and clears the current user here:

if ( null === $nonce ) {
	// No nonce at all, so act as if it's an unauthenticated request.
	wp_set_current_user( 0 );
	return true;
}

This is an interesting one. Maybe it would make sense for the PHPRequestHandler to omit cookies if a request appears to contain another auth-related header. But cookies aren't just for auth. So it seems presumptuous to remove cookies when we don't know the user's intent. We could filter out specific WP cookies, but it still might be solving a problem caused by a bit of magic using a bit more magic.

Read and understand our cookie store code better would probably help generate other ideas.

@adamziel @bgrgicak do you have any thoughts on this?

I wonder if it's time to get rid of the internal cookie store and scope all cookies to the specific scoped WordPress site path

I wonder if it's time to get rid of the internal cookie store and scope all cookies to the specific scoped WordPress site path

@adamziel, this is a great idea.

I think there is a rare possibility of the following:

1. Cookies created for a specific slug-based Playground scope path
2. That site is deleted
3. A new site is created that happens to have the same slug as before 🍀
4. The old site's login cookies are used with the new site

Maybe we should add site ID to the scope to avoid that rare possibility.

I wonder if it's time to get rid of the internal cookie store and scope all cookies to the specific scoped WordPress site path

I think this may turn out to be tricky because of restrictions on using Set-Cookie headers with created Response objects.

It would be nice if set cookies could be treated as HttpOnly, but it seems like we may have to set cookies with JS.

If we want to get rid of the cookie store, it may be necessary to do something like:
Message a server client tab and ask it to set cookies before the service worker resolves a fetch response that would contain those cookies.

This is not great because the cookies would not be set at the exact time as they would be if they were actually included as Set-Cookie headers in an HTTP response.

Alternately, to solve this GH issue, we could keep the cookie store and do the following:

• Have Playground web app boot set a flag cookie like playground-web-app-sending-cookies=1
• When the service worker receives a fetch event, check for the presence of the flag cookie.
  • If the cookie is present:
    • Remove it from the request
    • Infer that the browser is including cookies with the fetch
    • Relay cookies from the cookie store
  • If the cookie is absent:
    • Infer that the fetch is omitting cookies
    • Do not relay cookies from the cookie store

cc @adamziel

Because we cannot directly relay Set-Cookie headers via custom Response objects (they are forbidden response headers), I think we still need the HttpCookieStore for php-wasm/web, but we should be able to drop it elsewhere.

I think a good solution may be to support filter callbacks for requests and responses within PHPRequestHandler so the bulk of the logic can be maintained in php-wasm/universal while allow php-wasm/web to maintain a cookie store.

Then, as mentioned above, we can address this bug by always setting a cookie in the web client and letting its presence or absence tell the worker whether to relay cookies from the cookie store.

I think a good solution may be to support filter callbacks for requests and responses within PHPRequestHandler so the bulk of the logic can be maintained in php-wasm/universal while allow php-wasm/web to maintain a cookie store.

On second thought, we should just be able to handle this in the service worker with a per-scope cookie store. AFAICT, this would require no API changes. I am working on this.

On second thought, we should just be able to handle this in the service worker with a per-scope cookie store. AFAICT, this would require no API changes. I am working on this.

As I work through this, one awkwardness with handling this in the service worker is that there is no access to Set-Cookie headers via the Response object. So we'll need another way to relay that info or solve this at another layer. Other than that restricted access, handling cookie storage in the service worker which is already scope-aware seems to be a natural fit.

It looks like convertFetchEventToPHPRequest() in the @php-wasm/web-service-worker package may be a good place to for this. It is specific to running in web browsers, where we are forbidden from accessing Set-Cookie headers on actual Response objects. And this function is what handles mapping fetch() requests to PHP requests and PHP responses to fetch() responses.

The two things I still want to figure out are:
1. Where to best coordinate setting a playground-fetch-includes-cookies=1 cookie to serve as a hint whether cookies should be relayed with a given fetch request.
2. How to best cleanup stored cookies for a scope that is no longer loaded.

1. Where to best coordinate setting a playground-fetch-includes-cookies=1 cookie to serve as a hint whether cookies should be relayed with a given fetch request.

Scratch that. We should just respect the credentials option on a request. It's how the browser would behave normally. There's no need for another side-channel hint about whether cookies ought to be included.

So I plan to:

• Create a PR to move cookie store management so that it is only used for Playground running in a browser
• Make sure that custom cookie storage respects the original request's credentials property

That should keep Playground running as expected in the browser and allow Playground CLI to behave more like a normal web server (which does not apply the same cookies for all clients).