Cookies+nonce authentication #994

crazytonyli · 2025-10-30T08:55:35Z

This PR implements a light-weight cookies+nonce authentication.

The new type WpRestNonceRetrieval gets REST nonce via <site-url>/wp-admin/admin-ajax.php?action=rest-nonce. The nonce can be used along with cookies in the native RequestExecutor to make authenticated wp/v2 API requests.

As you can see in the code comment, the new WpAuthentication::Nonce authentication method is only meant for making temporary API calls. So, the implementation in this PR is more straightforward than the original in #327; it does not attempt to refresh the nonce.

jkmassel

Left some suggestions, I think the only blocking one is that we should extract the headers and send them back?

jkmassel · 2025-10-31T04:33:11Z

wp_api/src/login/nonce.rs

+        // Since the "cookies" part is out of our control, we need to verify that the nonce we got
+        // is actually for the user we expect.


It's possible for a request executor to avoid sending and receiving cookies (and actually, that should be the default to reduce traffic back-and-forth and to avoid invertently leaking data) – we can read the Set-Cookie value out of response headers and send them alongside the nonce request which is much more explicit.

We should still validate the the user is the one we expect though.

I didn't do that for two reasons:

Most, if not all, HTTP clients should have proper cookie-jar support. If we don't use the HTTP client's cookie-jar support, we'd need to implement one ourselves, which means (if we want to do it properly) checking domain, expire time, etc.

I think URLSession would overwrite the Cookies header in Request with the cookies in HTTPCookiesStorage. I could be wrong about this though...

we'd need to implement one ourselves, which means (if we want to do it properly) checking domain, expire time, etc.

Right – I hadn't considered this part of it. On the iOS side, WDYT about adding a preconditionFailure for httpShouldSetCookies != true (link) and/or httpCookieAcceptPolicy == nil (link) to ensure programmers don't use it wrong?

Good call. Added in a5f4fb2.

jkmassel · 2025-10-31T04:34:39Z

wp_api/src/auth.rs

+    // The "cookies" part is implicitly handled by the HTTP client.
+    // Since nonce is refreshed often, when using this authentication method,
+    // the caller should not keep using the same nonce for a long time.
+    Nonce { nonce: String },


WDYT about using username/password here and automatically getting the nonce prior to each request?

We should still document that this is bad for performance, but as long as the username/password don't change the client won't become invalid unexpectedly which seems slightly better?

I don't feel strongly about this either way.

using username/password here and automatically getting the nonce prior to each request?

That's how the original PR #327 implements it. It got pretty complicated because we need to refresh the nonce internally, and automatically retry the original API request after refreshing.

Considering the use case right now is using username and password to make one request, rather than all requests on the site, I thought it's better to keep it simple.

I was thinking we'd avoid the complexity by just assuming that the nonce is never valid and refreshing it prior to each request. That makes it simple but more expensive to use.

Still works great for our "we only plan to ever make one request" purpose, but ensures that if the client somehow persists for a while it doesn't "go bad" – it'll always work.

I have implemented it in a different way in 0154c20. The implementation takes advantage of the existing auth mechanism, using the DynamicAuthenticationProvider trait. See the new test_cookies_nonce function.

The implementation should just work if the nonce has expired. It should refresh the nonce and retry the request.

To summarize: We can now use the account username and password to create a WpApiClient (backed by CookiesNonceAuthenticationProvider), which uses cookies+nonce authentication method. The API client instance is not affected by the nonce expiration time, which means it can be kept around for a long time, like your regular WpApiClient with an application password. It stores the nonce internally and refreshes it when it's detected to have expired.

Looks cool – nothing else required to use it from Swift? Android should be ok

I don't think there is anything extra needed for Swift. The WordPressAPI already has public APIs that can accept CookiesNonceAuthenticationProvider. We can probably add a convenience initialiser to WordPressAPI to make the API more ergonomic.

I don't think there is anything extra needed for Swift. The WordPressAPI already has public APIs that can accept CookiesNonceAuthenticationProvider. We can probably add a convenience initialiser to WordPressAPI to make the API more ergonomic.

I'll approve the PR to unblock, feel free to add this now or later :)

I plan to use the authenticateTemporarily added in this PR. So, I'll merge the PR as it is. When we need to frequently use the account username & password to call the REST API from the apps, I'll see what kind of helpers are needed.

jkmassel · 2025-10-31T04:54:15Z

wp_api/src/login/nonce.rs

+        let mut url = self.details.parsed_site_url.inner.clone();
+        url.path_segments_mut()
+            .expect("The site url is a full URL")
+            .push("wp-login.php");


We could fetch self.details.application_passwords_authentication_url then parse the HTML we get back to find the form's action property to get this value, but I'm not sure it adds a ton of value.

jkmassel · 2025-10-31T04:54:46Z

wp_api/src/login/nonce.rs

+        url.path_segments_mut()
+            .expect("The site url is a full URL")
+            .pop() // Remove the "wp-login.php" part
+            .push("wp-admin")


You can also get this relative to self.details.application_passwords_authentication_url by dropping the last path component, but I'm not sure that's really better?

swiftly does not support debian 13 yet, which is the platform of newer WordPress docker images.

crazytonyli added 3 commits October 30, 2025 21:45

Implement getting REST nonce using account credentials

e367225

Add Swift wrapper for cookies+nonce authentication

bc51ec1

Add comments about WpAuthentication::Nonce

b9ebf4c

crazytonyli requested review from jkmassel and oguzkocer October 30, 2025 08:55

jkmassel requested changes Oct 31, 2025

View reviewed changes

crazytonyli added 7 commits November 3, 2025 11:04

Assert the URLSession instance stores cookies

a5f4fb2

Try username & password authentication on any nonce errors

b8c153f

Merge branch 'trunk' into cookies-nonce-authentication

b834b53

Merge the Swift docker env into the existing wordpress image

b1942b7

Implement using username & password to make API calls

0154c20

Less console output during building docker image

c666747

Update the installing swift script

1ebeeac

crazytonyli force-pushed the cookies-nonce-authentication branch from 9c44a00 to 1ebeeac Compare November 3, 2025 02:21

crazytonyli added 2 commits November 3, 2025 15:31

Move Swift Linux test job to the end-to-end test group

8155b69

Fix swiftlint issues

c98be88

jkmassel self-requested a review November 3, 2025 21:20

jkmassel approved these changes Nov 4, 2025

View reviewed changes

Default to test against WordPress v6.8.1

1ce4997

swiftly does not support debian 13 yet, which is the platform of newer WordPress docker images.

crazytonyli enabled auto-merge (squash) November 4, 2025 22:56

crazytonyli merged commit 2b3ed3f into trunk Nov 4, 2025
22 checks passed

crazytonyli deleted the cookies-nonce-authentication branch November 4, 2025 23:32

		// Since the "cookies" part is out of our control, we need to verify that the nonce we got
		// is actually for the user we expect.

Cookies+nonce authentication #994

Cookies+nonce authentication #994

Conversation

crazytonyli commented Oct 30, 2025

Uh oh!

jkmassel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkmassel Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jkmassel Oct 31, 2025 •

edited

Loading