Cannot change data

  • Resolved gaetgodi

    (@gaetgodi)


    2 weeks, 4 days ago

    I get a not authorized message when I try to save this table. In checking the app, both admin and editor are authorized, both got the same message.

    Gaetan

    = 5.5.81 =

    • Released 2026-08-18
      …
    • Fixed: Allow admins only to configure lookups
    • Fixed: Check authorization for wildcard exports
      …

    This is released the same day the 401s appeared and explicitly touches admin/authorization logic for the API layer. Given check_table_access() is exactly the function gating your save action, and its whole design hinges on current_user_is_admin() + the (empty) wpda_rest_api_table_access option, a behavior change to “admin-only” gating in this release is the single most likely explanation for both admin and editor now getting rejected identically — if this release tightened or altered how current_user_is_admin()/nonce validation is evaluated specifically inside a live REST dispatch (vs. how it resolves under normal WP execution, which I confirmed still returns YES for both test accounts).

    No WordPress core update or PHP version change was found in this window — this narrows cleanly to the WPDA plugin auto-update.

    1. Correlation with today’s other changes — none, timing coincidence only
    • The WPSC cache_rejected_uri edit and e20bd48 are unrelated (already ruled out in the previous round, and confirmed unrelated to this page again here).
    • No wp-config.php edits today, no cookie-domain/site-URL changes.
    • The only real “changed today (or yesterday evening)” event on this site is the WPDA auto-update to 5.5.81.

    Bottom line: This looks like a regression introduced by WPDA’s own 5.5.81 auto-update (yesterday evening), specifically in its admin/authorization handling for the REST write endpoints — not a caching, nonce, or cookie issue, and not related to this morning’s e20bd48 commit. I’d want to either (a) test with a fresh app-password-authenticated curl call to see the exact response, or (b) temporarily roll back to 5.5.80 to confirm saves work again, before proposing a fix — let me know which you’d like me to pursue, and whether I have your OK to create a throwaway application password on your account for a one-off diagnostic REST call (it’s reversible/revocable, but it is a write action so I held off).

    The page I need help with: [log in to see the link]

Viewing 12 replies - 1 through 12 (of 12 total)
  • gerrybw

    (@gerrybw)

    2 weeks, 3 days ago

    I had a similar issue with intermittent 401 errors when trying to change lookups and other configuration setting of my apps. I spent a lot of time with WPDA team investigating the underlying cause and just in case this is the same for you, in the event it was not caused by recent plugin upgrades.

    My hosting provider had implemented StackProtect and this was rejecting some loopback calls to the WP REST API. So the request was being responded to with a reCAPTCHA challenge which the plugin could not handle. If you are on a hosted platform might be worth checking this.

    Plugin Author Passionate Programmer Peter

    (@peterschulznl)

    2 weeks, 2 days ago

    Please check out this link:
    https://docs.rad.wpdataaccess.com/known-limitations.html#_401-unauthorized-error-0n-update

    It explains the problem that @gerrybw brought up. Please check the inspector’s response to the unsuccessful request and inform us of the result.

    If this does not provide any additional information, does installing the previous version resolve the issue?

    Thread Starter gaetgodi

    (@gaetgodi)

    2 weeks, 1 day ago

    Response body for the failed request: {"code":"error","message":"Unauthorized","data":{"status":401}}

    This isn’t the StackProtect/reCAPTCHA scenario from the known-limitations page — no security/firewall plugin is active on this site, and we traced a live reCAPTCHA network call on the same page to Contact Form 7’s own front-end integration (unrelated to the REST call, just coincidentally timed). We’re on 5.5.81, and this started the same day that version auto-updated. Both an administrator and an editor account get this identical error on save from [wpda_app app_id="7"], a grid on our own custom Results table — both accounts resolve manage_options/current_user_can correctly under normal WP evaluation. Given the generic "code":"error" body, this looks like it’s coming from check_table_access()‘s fallback branch when wpda_rest_api_table_access is unset, rather than the nonce or cookie layer.

    Thread Starter gaetgodi

    (@gaetgodi)

    2 weeks, 1 day ago

    …also, where can I get a previous version?

    Plugin Author Passionate Programmer Peter

    (@peterschulznl)

    2 weeks, 1 day ago

    Thank you for the detailed info @gaetgodi. Could you please share the app authorization settings for this application? It’s accessible via the App Manager:
    https://docs.rad.wpdataaccess.com/app-manager/menu/access.html#authorize-roles-users

    Thread Starter gaetgodi

    (@gaetgodi)

    2 weeks, 1 day ago

    Not sure how to enter this but mine reads Administrator and Editor.
    This messaging does not support cut and paste of images, event though I see it.

    Plugin Author Passionate Programmer Peter

    (@peterschulznl)

    2 weeks, 1 day ago

    Thanks! You’ve authorized the Administrator and Editor roles, correct? So sorry, Gaetan, but I can’t reproduce this issue. Can you please try if installing the previous version resolves the issue? Then we at least know if the issue is related to the update. You can find the documentation for installation an older version here:
    https://docs.wpdataaccess.com/previous-versions.html

    Plugin Author Passionate Programmer Peter

    (@peterschulznl)

    1 week, 4 days ago

    Any progress on this issue, @gaetgodi?

    Thread Starter gaetgodi

    (@gaetgodi)

    1 week, 3 days ago

    I went down to the 5.5.76, the problem does not occur there. I will update the versions until the problem occurs and let you know which version introduced it.

    Thread Starter gaetgodi

    (@gaetgodi)

    1 week, 3 days ago

    It was introduced with version 5.5.79

    Thread Starter gaetgodi

    (@gaetgodi)

    1 week, 3 days ago

    I re-installed 5.5.78, works just fine.

    Plugin Author Passionate Programmer Peter

    (@peterschulznl)

    1 week, 3 days ago

    Got it. The inline editing feature does not work with global save. The issue is fixed in version 5.5.82, which is now available. Thank you for reporting.

Viewing 12 replies - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.