Experiment Routes

Last Updated: 2026-10-09 | For: Experimenters, researchers, and developers

Audience: Researchers can use this page to diagnose launch context without source-code access. Developers can use it with the route implementation when code changes are needed.

This page summarizes route behavior that affects experiment launch, sign-in, and assignment context.

Route Behavior Model

1. User signs in.
2. Account context resolves in authenticated state.
3. Student class context is selected post-login from dashboard/main menu (not via public sign-in route).
4. Launch target resolves to allowed experiment content.
5. Runtime initializes experiment state.

If any context check fails, launch can redirect or stop before experiment entry.

Ordinary Sign-In and Experiment Continuation

An explicit ordinary destination such as /home or /auth/login opens ordinary sign-in when authentication is required. Remembered experiment cookies cannot override that destination. Ordinary sign-in clears the experiment target, condition, experiment-only login presentation, embedded-key mode, and public-demo routing metadata; learner histories and saved progress remain intact.

The experiment-routing cookies are shared across tabs. Clearing them on ordinary sign-in also clears remembered routing for other tabs. Opening an explicit /experiment/:target/:xcond? URL establishes the requested experiment context again. Existing authenticated experiment flows retain their in-tab context.

Shared /content/:tdfId and /instructions/:tdfId routes continue an active or remembered experiment. A known ordinary password or provider login takes precedence over old cookies on those lesson routes. Authentication remains per tab, so a new tab can need login even when another tab is signed in. Public demos remain experiments, with their existing launch, exit, and expiry behavior.

Prolific entry and return visits

A Prolific launch uses /experiment/<study-id> and includes PROLIFIC_PID, STUDY_ID, and SESSION_ID exactly once. The study ID must match the experiment target, the experiment must support passwordless entry, and the root must have a valid completion URL. Invalid launches stop with an error. Reusing the same identity triple resumes the saved participation account, condition, and progress. Private return links retain the ordinary lockout restrictions. See Prolific participation for the exact study URL.

Common Route Context Dependencies

• authenticated user identity
• post-login class selection context (student dashboard/main menu)
• target experiment/assignment context
• authorization checks for selected target

Operator Checks for Route-Related Failures

1. Confirm sign-in succeeded and session is current.
2. Confirm post-login class-select context is present and correct.
3. Confirm assignment exists for that user/class.
4. Confirm target experiment is accessible to that user role.
5. Re-test from a clean session if stale route state is suspected.

Route-Related Symptoms

• Student signs in but does not reach expected lesson.
• Student lands on home page instead of assigned experiment.
• Launch starts but immediately redirects out of experiment.

Use Troubleshooting for symptom-level triage and Class Setup and Assignment Workflow for assignment verification.

See Also

• Researcher Guide
• Developer Reference Guide
• Class Setup and Assignment Workflow
• Settings.json Reference
• Troubleshooting

Removed Legacy Routes

Legacy public class-coupled sign-in routes were removed from the auth flow:

• /classes/:teacher
• /classes/:teacher/:class

Class selection is now an authenticated workflow step and does not occur on public sign-in routes.