How the Laboratory Access Cookie Works

After a correct access code is accepted, the gate issues a laboratory-specific cookie so subsequent requests can reach Joomla without asking for the code on every page.

Current cookie properties

• Run-specific rather than a global QCUL cookie.
• HttpOnly so ordinary page JavaScript cannot read the cookie value.
• SameSite=Strict to reduce cross-site sending.
• Scoped to the laboratory path instead of the entire production origin.
• The stored secret is encrypted and hashed for verification by QCUL.

Why the cookie can fail

A stale browser cookie from a removed/refreshed lab, an unexpected URL/cookie-domain configuration, or damaged gate metadata can prevent access. Use current production-displayed access details and a fresh private window when diagnosing the gate.

Do not weaken the browser controls

The cookie is one layer in a larger boundary that also includes the external gate, no-store/indexing controls, lab-specific Joomla secret/cookie settings, and visible lab identity.

Safety check before update testing

Before relying on How the Laboratory Access Cookie Works, confirm the private copy still shows laboratory identity, its access gate works, and ordinary browsing stays inside the lab rather than silently using production. The cloned site contains production-derived data, so a laboratory that is not demonstrably isolated should be repaired or refreshed before any update rehearsal.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.