nonce issue when using WordPress mobile app in parallel with web

[oferlaor]

Steps to reproduce:

1. Login as admin to WP on a regular browser
2. Login into the same WP site using the WordPress mobile app (I am using iOS)
3. Upload some piece of media to the site through the mobile app (i.e., authenticate and actually use the mobile app for something)
4. Go back to the WP admin area on the regular browser, for example open list of posts.

Expected result: I get the list of posts
Actual result: I get kicked into my profile page.

In the console, I can see multiple 403 errors. The Error is: rest_cookie_invalid_nonce. Meaning, there’s a mismatch between the nonce we got in the mobile app and the desktop. At this point, WP should be creating a new nonce and continuing normally, but it seems that this functionality is broken in 6.8.

Things I tested:

1. Disabled caching plugins + cloudflare
2. If I downgrade the site from 6.8 to 6.7.2, it resolves the problem (even with caching plugin + cloudflare)

Conclusion: 6.8 nonce refresh might have a new bug in this flow. For now, I’ve reverted to 6.7.2.

[oglekler]

Hi @oferlaor Thank you for reporting the issue.
Most likely this issue is not with the WordPress, but with the application, but this is just a guess, I bring this to the attention of one of the apps developers. If this will be confirmed as an issue with apps, it will need to be reported in the dedicated repository instead.

In the meantime, I am changing the severity because even if that you are experiencing is quite annoying, it is not effecting functionality seriously and only happening in certain conditions.

This is also not exactly about Security and rest api most likely is just a courier.

[oferlaor]

A few clarifications:

1. version 6.7.2 does not have this problem.

2. It seems that the nonce refresh flow, when it's invalid, has some type of problem - which causes this issue. I think the app is fine, it basically generates its own nonce and it looks like the original one expires on the desktop side.

3. Once this happens, the result is pretty catastrophic, user gets kicked out from what they are doing (and posts in the middle, stop being able to save) and everything jumps to the user's profile.

At that point, the user is blocked from doing anything as an admin, nothing works and only after deleting all cookies and logging back in, does it start to work again.

I marked it as security because the rejection is incorrect 403 error.

[oglekler]

@johnbillion and @dpcalhoun can you pleace check this out?

[dpcalhoun]

@oferlaor unfortunately, I am unable to reproduce the reported issue currently when following the provided reproduction steps. The post lists loads as expected during my testing. My environment consisted of:

• WordPress 6.8
• WordPress mobile app 25.8
• iOS 18.3.1
• Safari 18.3
• No plugins installed or activated

I utilized a newly created WordPress site and fresh install of the WordPress mobile app in my testing.

Are you able to share additional details regarding your environment—mobile app version, OS version, browser version, plugins, etc?

[...] everything jumps to the user's profile.

To avoid confusion, I interpret "user's profile" as the /wp-admin/profile.php route, and that navigating anywhere within WP Admin results in a redirect to this route. Is that correct?

[oferlaor]

iOS 18.4.1
Wordpress 6.8
WP app 25.8

Steps:

1. I log in as admin, on both platforms - web (chrome on Mac) and app.
2. I enter list of posts on chrome desktop
3. I upload a photo from my phone to the same site using the mobile app
4. I try something else on the chrome desktop (for example, refresh the list of posts <url>/wp-admin/edit.php, or visit the media library <url>/wp-admin/upload.php)

I downgraded to 6.7.3 (no other changes) and it behaves as expected.

Key points:

1. You have to use the same *admin* user
2. Both have to do something "admin" on both the chrome and the mobile app

Regarding the weird redirect. You are correct, I get an notice "something went wrong! failed to fetch" in the UX and then you get redirected to the user's personal profile (the URL wp-admin/profile.php). The console shows all API calls as returning 403 errors. When reviewing then, it shows:

403: rest_cookie_invalid_nonce

[dpcalhoun]

I attempted again using Chrome 135.0.7049.115 on macOS 15.4.1. After using the same admin user and performing admin-permission-required tasks in both platforms—macOS Chrome and iOS mobile app—the session in Chrome still operated as expected, I did not experience 403 errors.

I'm unsure what environment difference or overlooked step might lead to the diverging experiences. 😕

What plugins are activated on the site experiencing the issue? Are you able to reproduce for a newly created WordPress site without zero plugins installed?

[oferlaor]

it'll be quite complex to create a newly created WP site without plugins - we have too many customizations. Creating a new version would be too hard, it's a heavy complex site.

I can privately provide credentials to our sandbox site, which I use for testing. I didn't test the flow there, I can try.

[dpcalhoun]

Replying to oferlaor:

it'll be quite complex to create a newly created WP site without plugins - we have too many customizations. Creating a new version would be too hard, it's a heavy complex site.

I can privately provide credentials to our sandbox site, which I use for testing. I didn't test the flow there, I can try.

To clarify, I was not inquiring if you can reproduce with a fresh setup of your specific site. I am asking: can you reproduce the issue in a new, default-settings, no-modifications, no-plugins-installed WordPress site?

I cannot when testing with a site created with ​https://jurassic.ninja.

[oferlaor]

I understand. It's just that the site is too complex to even try to deploy without plugins, it's not a trivial marketing site, but a full blown app.

just saw 6.8.1 was released so tested both 6.8 and 6.8.1, and there's an interesting development.

with 6.8 on my staging environment, it reproduces in the flow I outlined (I can try and disable plugins there, but I should note that I disabled the majority of my plugins, including all caching, security and similar plugins).

However, when I moved to 6.8.1 I got different results:

1. On 6.8, no matter what I do, I get kicked into my profile page and I can't do anything until I clear cache+cookies and log back in.

2. On 6.8.1, I get kicked out to the profile page, but if I go back into the post list or media list, it works again... So, looks like theres' a difference there.

The staging site has no caching, so it's possible that when getting kicked out, the issue is aggrevated and retained whereas the cacheless version persists it less...

[dpcalhoun]

Replying to oferlaor:

[...] It's just that the site is too complex to even try to deploy without plugins, it's not a trivial marketing site, but a full blown app.

Understood. I am attempting to verify it's reproducible on a site other than the site you are referencing; that is why I remain interested if you can reproduce the issue on a different, unmodified WordPress site.

Merely trying to reduce the number of variables or possible causes, hoped it might provide additional insight into the problem. 🙇🏻‍♂️

[jorbin]

I also am unable to replicate this though I wasn't logged in to the mobile app before upgrading WordPress.

@oferlaor If you log out of the mobile app and log back in does this continue to happen?

[oferlaor]

Just upgraded production to 6.8.1, behavior is different between 6.8 and 6.8.1!

WHILE the mobile app is running, wp-admin keeps trying to redirect me to the profile page (it sometimes gets in a loop, trying to redirect the profile page into itself).

I exit the mobile app (kill the process), I can at least work. I still see the 403 error on:

/wp-json/wp/v2/users/me?context=edit&_locale=user
/wp-json/wp/v2/types?context=view&_locale=user

BUT once I exit the mobile app, the same REST API call work correctly and get a 200.

as soon as I go back into the mobile app, the desktop side

/wp-admin/admin-ajax.php will reply with

302, location: /wp-admin/profile.php

with tons of cookies, but at the end, there's

X-Redirect-By: WordPress

again, once I exit the app, opening the /wp-admin/edit.php redirects once to wp-admin/profile.php and after refreshing again, it works correctly...

So, it's not even that I have to logout, it's like I can't have both running simultaneously.

About the clean site. I don't have a server or place to install it on, so I can't test the flow on a clean WP site.

Hope this is useful.

[johnbillion]

There isn't inherently this sort of connection between wp-admin and the WordPress app. The app uses XML-RPC (or a Jetpack connection) and there's no concept of state or being logged into the app in a way that affects the wp-admin area. I suspect the issue(s) that you're seeing are caused by a plugin on your site, in particular that redirect from admin-ajax.php to profile.php isn't something that WordPress core does.

I appreciate that reproducing or isolating the problem isn't easy. A good place to debug this would be to start deactivating plugins one by one on your pre-production site until you can identify one or more culprits that affect this behaviour.

I'll leave this open for the time being, but this doesn't sound like a core issue.

[SirLouen]

Replying to oferlaor:

I understand. It's just that the site is too complex to even try to deploy without plugins, it's not a trivial marketing site, but a full blown app.

The problem here is that if it's not reproducible, it is not sortable.

And even if we could reproduce it under a sandbox condition you provided with credentials the problem could come from who knows where (and this is not something into the scope of the average WP developer, unless you put money on the table and hire an agency).

My recommendation for you is simple:

Try isolation. If you had a full developed by you site from scratch, the classic go-to is to test each part independently (even if parts are correlated, generally dev teams create mocks of the interconected parts to "simulate" they are there, but they are not actually)

In WordPress there is a very interesting "feature", and this is the plugins: Plugins create this sort of isolation, since you can enable and disable them. So first you can start by disabling each single plugin.

Next, you can add one or two, and test. Same for themes. You can add different themes, or comment out parts of your custom theme just in case.

As a rule of thumb, if we cannot reproduce something with a maximum level of simplicity, it can't be fixed. Maybe you have found a bug because there is something in XML-RPC that is wrong or whatever, but we need to isolate it to the maximum level to get a conclusion and following your simple steps we cannot reproduce it for now.

[oferlaor]

so, I disabled all the plugins (that allow themselves to be disable). That left a couple that don't like to be disabled like ACFP and Yoast.

At that point, I deleted ALL the plugin directory. The issue went away. Great!

So, I did the opposite, I restored the previous version, reproduced the problem and removed just ACFP and Yoast. No dice - issue remains...

So, not quite sure how to proceed. Normal elimination doesn't work, unless disabled plugins still execute some code (AFAIK, that's not the case).

[oferlaor]

OK, I think I found the plugin that's at fault here. I think some change in 6.8 triggered a behavioral change there. I see it has some edge cases that redirects to profile.php

Thanks for the help and I'll update if I stil think it's 6.8, but for now I think you guys were right.

[johnbillion]

Great, thanks for confirming. I'll close this off! Hope you get it sorted.