How Cloned Sessions and Remember-me Access Are Neutralized

A laboratory must not inherit production browser/login identity blindly, so QCUL changes the Joomla secret/cookie scope and clears copied session/remember-me state.

Neutralized authentication state

• The lab receives a new Joomla secret.
• Cookie path/domain settings are rewritten for the laboratory.
• Cloned session records are cleared.
• Remember-me authentication tokens copied from production are cleared.

Expected result

Passing the external QCUL gate does not mean every production Joomla login session should remain active in the clone. You may need to log into the laboratory Joomla administrator as part of the review, which is safer than silently carrying production sessions across.

Troubleshooting

If authentication behaves unexpectedly, verify you are on the correct laboratory URL and that the current lab’s configuration/cookie path was applied. Do not “fix” the lab by copying production session tables/cookies back into it.

Safety check before update testing

Before relying on How Cloned Sessions and Remember-me Access Are Neutralized, 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.