How QCST Protects Against CSRF and Tampered Form Requests
This article explains Joomla session tokens and server-side revalidation so hidden fields/buttons are not treated as authority.
Where this fits in QC Support Ticket
QCST combines Joomla session/CSRF protection with server-side record authorization. A valid form token proves the request came through a valid Joomla session flow; it does not, by itself, authorize the submitted ticket, Department, Agent, workflow or file identifier.
Primary location: QC Support Ticket frontend and administrator interfaces, depending on the permission or failure being tested.
Why hidden fields are not authority
QCST state-changing forms/actions use Joomla session/CSRF tokens and then re-fetch/revalidate the referenced ticket/target values. A forged Department, Agent, Status or ticket ID in a submitted form is not trusted simply because it came from an HTML control.
Practical implication
If a long-open form suddenly fails after session expiry or another Agent changes the ticket, reload the current page and retry from the current authorized state rather than disabling token checks.
What to remember
- Use least-privileged normal accounts when validating authorization; Super User behavior cannot prove that customer, guest or Agent boundaries are correct.
Two checks happen together
| Protection | Role |
|---|---|
| Session/CSRF token | Confirms the state-changing request came from a valid Joomla session/form flow rather than an arbitrary cross-site submission. |
| Server-side record authorization | QCST reloads/revalidates ticket, Department, Agent, workflow or file context instead of trusting a hidden form field simply because the browser submitted it. |
When a legitimate form fails
A long-open administrator or Agent form can fail after the Joomla session/token expires, and a ticket can change while an Agent has it open. Reload the current page, review the current ticket state and retry from the fresh form. Do not disable token checks or trust stale hidden values to “fix” the workflow.
CSRF protection and authorization solve different problems
A valid CSRF token prevents one class of forged cross-site state change, but QCST must still validate the record and role. This is why custom code should not copy only the token check and skip ticket ownership/Department checks. Conversely, adding extra record checks does not make it safe to remove Joomla’s session token from state-changing forms.
Community Discussion
For practical QC Support Ticket workflows and discussion with other Joomla site owners, visit the QC Support Ticket Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.