"Invalid Request" for certain operations.

[Soilborn]

Script URL: Withheld
Version of script: 3.5.3
Hosting company: AWS
URL of phpinfo.php: Withheld
URL of session_test.php: Withheld
What terms did you try when SEARCHING for a solution: “invalid request”

Write your message below:

Apologies for the withheld URLs for the script and the URL endpoints. My deployment of Hesk resides behind a firewall that renders it publicly inaccessible anyway.

Previously, I had Hesk deployed within a Docker container and it was perfectly happy in there. In order to comply with new SSO organization requirements however, I had to transition to a different build process that completely remade the way it was built within its container, alongside SimpleSamlSSL integration for admin-side access. Everything works now as it did before, for the most part.

I have noticed however that, after the change, there are certain operations I cannot perform. Doing so results in redirecting to the performing PHP file and being presented with the message “Error: Invalid Request.” Tested and confirmed breakages include:

• Merging or deleting tickets from admin_main.php
• Saving changes to Settings → General.
• Saving changes to Settings → Help Desk
• Saving changes to Settings → Knowledgebase
• Saving changes to Settings → Email
• Saving changes to Settings → Ticket list
• Saving changes to Settings → Misc

When this error pops up, the container log list only this or similar (<domain name> replacing the actual domain):

"POST /admin/admin_settings_save.php HTTP/1.1" 200 8465 "https://<domain name>/admin/admin_settings_misc.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"

From what I understand, this must be an issue with data being passed to the other PHP files. I have performed a test deployment with Hesk v3.5.3 using my old build process and these have all worked, so I know it’s something different with my new configuration. My new configuration utilizes port 443 with Apache and all the SSL/TLS cert shenanigans while the older one relied upon an AWS load balancer for this and considered itself simply HTTP, but from there I’m unsure what next. Forcing SSL connections through Settings → Help Desk didn't help either.

Any further help would be greatly appreciated.

[Klemen]

This means that most likely PHP sessions aren't preserved properly. You can use this script to test PHP sessions:
https://www.hesk.com/knowledgebase/?article=23

[Soilborn]

Thanks for the rapid response, Klemen.

This looked like the same file I tried as part of the "read before posting" message, but I downloaded it and pushed it up anyway. The test result came back "OK: PHP sessions work fine."

[Klemen]

The problem is that the 'token' request parameter is wrong, so the token check (CSRF protection) fails.

Two things come to mind:

1. some server-side caching is causing the issue as outdated session data is present; try disabling all server-side caching for Hesk.

2. session data is invalidated too quickly

If nothing works, you could disable CSRF protection by making sure the hesk_token_check function inside /inc/common.inc.php always returns true.

If you use Hesk locally on a trusted network, it shouldn't be much of a downside.

[Soilborn]

Thanks for your help, Klemen!

While disabling server-side caching didn't seem to work, tinkering with the hesk_token_check function did.