Safe OnlineExam
Roll out & operate

Verify the integration

The full acceptance sequence — administrator, instructor, student-in-browser, and student-in-SEB — to run before any real exam.

Run this sequence after any deployment that affects authentication, Canvas interaction, settings, configuration generation, the detector, certificate material, or exit behavior — and always before the first real exam. Use separate administrator, instructor, and student accounts.

Why manual acceptance matters

Automated tests protect the application's contracts, but the critical path crosses Canvas and a native SEB client that a unit test cannot fully reproduce. This end-to-end run is what proves the whole chain — identity, proof, and exit — works together on real devices.

Administrator

Confirm /health, /lti/config, JWKS, and the detector endpoints on the deployed URL.
Confirm Canvas stores the current LTI client ID, deployment ID, login URL, target link URI, and JWKS URL from /lti/config.
Confirm the API OAuth key has the complete application and administrator scope set, including the exact session_token scope.
Open Safe Exam Browser Admin from root-account navigation and complete its separate OAuth authorization.
Confirm only Canvas-authorized root-account courses appear. Create and assign a school tool preset; refresh one test course; reveal a password and verify it disappears automatically; rotate the course exit password; reset one assessment exit password; rotate its code; toggle SEB; and confirm the secret-free activity records.
Repeat the launch as an instructor, a sub-account administrator, and a student, and confirm the root-account dashboard is denied in each case.
Confirm the active Canvas theme loads the detector on a Classic Quiz /take page and a New Quiz assignment route.
Confirm the client certificate profile is installed on an approved test device and the active public-key hash matches the service.

Instructor

Launch the tool from a Canvas course and complete (or re-run) Canvas OAuth.
Refresh the course. Confirm it finds the intended published Classic Quiz and New Quiz data.
Configure a valid effective exit password, an optional start password, selected course tools, one quiz-only tool, and narrow URL rules. Confirm the quiz-only tool does not appear in another assessment or in course defaults.
Enable one Classic Quiz and one New Quiz. Confirm Canvas requires an access code and the management response does not reveal it.
Change one protected setting, confirm the previous configuration becomes unsuitable for proof, and download a fresh configuration.
Disable each assessment and confirm Canvas access-code protection is removed only through the intended action.

Student in a normal browser

Launch the course-navigation placement and complete the one-time Canvas connection.
Run the optional setup check. Test a missing/revoked scope path and confirm the recovery path requests a new Canvas connection.
Open each enabled assessment. Confirm the ordinary browser presents the protected launch/download flow — never an access-code value.
Confirm the detector's launch UI is available on the assessment route and that approved tools are not exposed before a valid SEB proof.

Student in SEB

Start from an SEB client with no usable Canvas browser session, open a fresh configuration, and verify it reaches Canvas through the generated session URL.
Confirm the encrypted configuration opens only on a client with the managed private identity. Run the setup-check configuration first when validating a new client or profile.
For Classic Quiz and New Quiz, verify Config Key proof succeeds, the correct access-code prompt is filled once, and the assessment becomes available.
Confirm disabled tools are unavailable, and each selected tool opens only its intended launch/resources; returning to Canvas preserves the assessment flow.
Cancel a final Canvas confirmation. Verify no submission exit begins.
Submit successfully. Verify Classic Quiz exit waits for Canvas's completed-submission result, and New Quiz exit waits for its authoritative result UI.
Verify the validated quit action works after completion, and that a native early quit still follows the configured password policy.

Release regression checklist

Before a merge or release, confirm:

  • Automated verification (verify, verify:postgres, and the relevant Compose/Playwright checks) passes.
  • Public LTI, JWKS, health, detector, and OAuth callback URLs are unchanged — or Canvas has been updated intentionally.
  • A settings change is shown to reject stale configuration/proof.
  • Instructor and learner roles cannot reach each other's privileged endpoints.
  • Classic Quiz and New Quiz are both exercised for shared assessment/detector code.
  • Certificate, encryption, Config Key proof, session handoff, start/exit password, and URL-tool policy work together on supported devices.
  • The browser console is clean on desktop and mobile.
  • The release uses the intended image digest, runtime identity, database, numbered secret versions, and public URL.

Test-data hygiene

Use isolated Canvas courses and non-sensitive test accounts. Never paste real access codes, OAuth tokens, session URLs, private keys, .p12 files, or passwords into fixtures, snapshots, shell history, or issue reports.

Next: Deploy the certificate to devices.

On this page