# DiscourseConnect HMAC validation fails with WordPress despite matching callback parameters

**URL:** <https://meta.discourse.org/t/discourseconnect-hmac-validation-fails-with-wordpress-despite-matching-callback-parameters/413092>\
**Category:** Support\
**Tags:** sso, hosting\
**Created:** [23 september 2026 om 06:08 UTC](https://meta.discourse.org/t/discourseconnect-hmac-validation-fails-with-wordpress-despite-matching-callback-parameters/413092 "2026-09-23T06:08:18Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![Gallussi](https://avatars.discourse-cdn.com/v4/letter/g/ac91a4/32.png) [@Gallussi](https://meta.discourse.org/u/Gallussi)\
**Post date:** [23 september 2026 om 06:08 UTC](https://meta.discourse.org/t/discourseconnect-hmac-validation-fails-with-wordpress-despite-matching-callback-parameters/413092/1 "2026-09-23T06:08:18Z")

</div>

Hi,

I’m setting up [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) between a WordPress site and a hosted Discourse instance and have reached a persistent HMAC signature validation failure.

**Setup**

- WordPress is the authentication/provider side.
- Discourse is using [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true).
- WordPress receives the [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) request and returns the callback containing `sso` and `sig`.
- The callback reaches Discourse, but Discourse rejects it because the HMAC signature does not validate.

We have done fairly extensive debugging and have narrowed the problem down considerably.

**What we have confirmed**

- `wp_unslash()` does not alter the callback values.
- The EA/WordPress validation inputs match the parameters reconstructed from WordPress’s observed query string.
- The expected callback code is definitely executing.
- The deployed source files match our build manifest.
- We have checked for wrong-file and duplicate-definition issues.
- PHP-FPM has been restarted after the latest corrections, so this is not an old PHP process/opcache state.
- A completely fresh [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) request after those changes still fails HMAC validation.

In other words, the current failure is reproducible on a fresh request.

**What we have not yet been able to prove**

1. That the effective secret being used by Discourse at runtime is byte-for-byte identical to the secret being used by WordPress.
2. That the `sso` payload is not being changed somewhere before the point at which WordPress observes the request.

At this stage we don’t want to keep changing settings or code blindly.

**Question**

For current Discourse/[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true), what is the best way to determine exactly which payload and secret Discourse is using when it calculates the expected HMAC?

Is there a recommended debugging/logging method that would allow us to compare the Discourse-side HMAC input with the WordPress-side input without exposing the actual secret publicly?

If there are any known issues involving WordPress/PHP handling, URL encoding, Base64 payloads, reverse proxies, or hosted Discourse that could produce this situation, I’d also appreciate pointers.

I can provide sanitized request/callback values, relevant WordPress code, and logs if needed.

Thanks.

---

_[View the full topic](https://meta.discourse.org/t/discourseconnect-hmac-validation-fails-with-wordpress-despite-matching-callback-parameters/413092)._