I'm posting this today (November 2025) to finally clarify and document solutions for two persistent, complex issues I've been troubleshooting since early this year (February/April 2025). These problems occurred while running osTicket 1.18.2 behind a Cloudflare proxy and might be very useful for others using similar security/CDN setups.
Issue 1: Agent/User Password Reset Functionality Fails
Symptom: The password update page loads on the osTicket subdomain (e.g., example.yourdomain.com), but the submission button or the required confirmation dialogue is unresponsive. Browser console errors show resources are blocked by Content-Security-Policy (CSP).
Root Cause: Cloudflare's security features were injecting a strict Content-Security-Policy header into the HTTP response, overriding the server's configuration. This blocked essential inline JavaScript needed for the frontend functionality.
Solution: Cloudflare Transform Rule Override
We must force Cloudflare to send the correct, permissive CSP header.
- Cloudflare Dashboard - Rules - Transform Rules - Modify Response Header.
- Create a new rule with a precise filter to target only the osTicket subdomain:
- Rule Match: Hostname equals example.yourdomain.com
- Header Action: Select Set static (to overwrite any existing headers).
- Header Name: Content-Security-Policy
- Value (The Permissive Policy):
default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://static.cloudflareinsights.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://static.cloudflareinsights.com; object-src 'none';
Issue 2: Agent/Admin Login Lockout ("Session Timed Out")
Symptom: After an agent or admin logs out or their session expires, they cannot immediately log back in. The system repeatedly rejects the attempt with the message "Session timed out due to inactivity," forcing the user to wait a long period before a successful re-login is possible.
Root Cause: This is caused by an official osTicket patch conflict where a previously used SameSite=None setting caused issues with same-site login attempts, preventing the browser from properly discarding the old session cookie.
Solution: Applying the Official SameSite Patch
We reverted the SameSite attribute setting to the more standard and compatible values.
- File to Edit: include/class.ostsession.php
- Find the line (around line 262) that sets the samesite option.
- Replace the existing line with this configuration:
'samesite' => !empty($ost->getConfig()->getAllowIframes()) ? 'Lax' : 'Strict',
(Note: This fix for the login lockout also resolved the cross-site password reset functionality once the CSP issue was cleared.)
By applying these two fixes, the system is now fully functional and stable.
Acknowledgement and Credit
I want to extend my thanks to Kevin for providing the crucial insight into the SameSite attribute conflict, which was essential for resolving the login lockout problem.
Reference Thread: https://forum.osticket.com/d/106376-login-issue-for-users-on-v1182/18
