View Identity (For Me) → scoped to Everyone with allowSelf="true.
View Identity (For Others) → scoped to Self Service, Help Desk, Manager, Everyone with allowOther="true.
Both quicklinks are visible to admins and end users. End users are allowed to view other identities but only with limited attributes (configured in Identity Display settings).
Issue:
When admins use the quicklink, it works fine.
When end users use the quicklink, I see this syslog error:
CSRF validation failed for /identity/rest/workItemNotifications/count
@Fathima2104 This is not caused by your QuickLink configuration — the setup looks correct. The CSRF error on /identity/rest/workItemNotifications/count is a background REST call IIQ makes to populate the work item notification badge when an identity view loads. It’s separate from the QuickLink itself.
The reason it works for admins and fails for end users is a session/CSRF token timing issue — when a non-admin navigates via the QuickLink, the background REST call fires before the CSRF token is fully in sync with their session. Admins bypass this more gracefully due to elevated session handling.
Two things to check:
Is it actually breaking anything? The CSRF error on workItemNotifications/count is often just syslog noise — the identity view itself may still load fine. Check if end users see a broken page or just a missing notification count badge. Many orgs just suppress the log if it’s cosmetic.
If the page is actually breaking, check your SystemConfiguration object in the IIQ debug page for CSRF-related entries. Also verify your web.xml CSRF filter rules aren’t applying more strictly to non-admin roles than admins.
Also worth checking — if you’re running behind a load balancer or reverse proxy, make sure sticky sessions are configured correctly. CSRF token mismatches between requests are much more common for non-admins in that setup since admins tend to hit the same node consistently.
Can you confirm whether the identity view page actually fails to load, or is IIQ just logging the error while still working? That’ll narrow it down quickly.
@Fathima2104 Could you please confirm if the functionality is working fine or not? Means, are end users able to view other identities? CSRF error could come because of multiple reasons, not necessarily from your quicklink page.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
Hi @neel193 I’m actually experiencing something similar with the Object Browser (Read Only) plugin. Works without issues when logged in a Admin. But getting the error on end user profile. In terms of plugin functionality, I am able to see the UI. However, the object type field is not populating any data.
@nmakgato Instead of using the Object Browser Read Only Plugin, have you tried assigning the DebugPagesReadOnlyAccess capability to the user? This should allow them to access debug in read only mode. (also, which version of IIQ are you using?).
@neel193 We’re currently on version8.3p2. And the current version doesn’t have the DebugPagesReadOnlyAccess capability. Only available on version8.4 onwards
Hello Fathima CSRF errors are in regards to your form security validation. It is a token that’s being sent to authenticate your response. Could you share the complete log ?
