# OIDC csrf\_detected can mask user cancel / consent rejection - docs could clarify log inspection

**URL:** <https://meta.discourse.org/t/oidc-csrf-detected-can-mask-user-cancel-consent-rejection-docs-could-clarify-log-inspection/395021>\
**Category:** SSO\
**Tags:** openid-connect\
**Created:** [February 3, 2026, 11:56am UTC](https://meta.discourse.org/t/oidc-csrf-detected-can-mask-user-cancel-consent-rejection-docs-could-clarify-log-inspection/395021 "2026-02-03T11:56:09Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\
**Post date:** [February 5, 2026, 9:16pm UTC](https://meta.discourse.org/t/oidc-csrf-detected-can-mask-user-cancel-consent-rejection-docs-could-clarify-log-inspection/395021/2 "2026-02-05T21:16:57Z")

</div>

## Minor log-viewer gotcha (FYI)

One small thing that tripped me up while inspecting the logs:

In Admin → Logs → env → params, values may appear with escaped sequences such as:

```plaintext
\u0026

```

This is just JSON/Ruby escaping for &. For example:

```plaintext
error=access_denied\u0026error_subcode=cancel

```

should be read as:

```plaintext
error=access_denied&error_subcode=cancel

```

Nothing is being mangled or lost - it’s purely a display/serialization detail - but it’s worth knowing so operators don’t miss the underlying IdP signal when diagnosing `csrf_detected` failures.

---

_[View the full topic](https://meta.discourse.org/t/oidc-csrf-detected-can-mask-user-cancel-consent-rejection-docs-could-clarify-log-inspection/395021)._