Skip to main content
Safe Online Exam problems should be diagnosed by locating the specific boundary that failed. A Canvas iframe error, an OAuth error, a SEB launch error, a detector error, and a database readiness error each have distinct evidence and should not be treated as a single generic launch problem. This page walks through safe evidence collection, first-check endpoints, and symptom-to-cause tables for every major failure category.

Safe Evidence Collection

Before investigating, record the following context:
  • the release version or Cloud Run revision;
  • the approximate timestamp and time zone;
  • the user role (administrator, instructor, or student);
  • the Canvas course and assessment type (Classic Quiz or New Quiz);
  • the browser, OS, and SEB version; and
  • the exact visible error message.
Never collect or paste the following into any issue, log, support ticket, or diagnostic record:
  • Canvas access or refresh tokens
  • Browser cookies or session IDs
  • Canvas access codes
  • One-time Canvas session URLs
  • .seb files from live assessments
  • LTI_PRIVATE_KEY, database passwords, or state/session secrets
  • The SEB .p12, private key, or identity password
  • Student responses or personally identifiable information

First-Check Endpoints

Check the public, secret-free endpoints before anything else:
  • /health confirms the HTTP process is running.
  • /ready also checks PostgreSQL connectivity and the complete migration set.
  • The JWKS, LTI configuration, and detector requests confirm the public origin and key Canvas-facing assets.
An HTTP 200 health response alone does not validate Canvas configuration, OAuth, PostgreSQL migrations, certificate decryption, Config Key proof, or a real SEB client.

Problem Categories

For Cloud Run, inspect the active service revision and migration/cleanup job executions. For Compose, inspect docker compose ps, the one-shot migration result, application logs, PostgreSQL health, disk space, and the named postgres_data volume.If an upgrade stages a ready candidate but reports no tagged URL, confirm the old revision still has traffic and inspect the run.googleapis.com/default-url-disabled annotation. Use a current upgrade helper that temporarily enables the generated URL for candidate checks and restores the disabled policy after cutover.
For repeated launch failures, compare:
  • LTI_ISSUER with the actual signed iss claim;
  • Canvas’s LTI client ID with LTI_CLIENT_ID;
  • the installed deployment ID with the configured allowlist;
  • login, target-link, redirect, and public JWKS URLs with /lti/config; and
  • the public origin with TOOL_URL.
Do not disable deployment-ID checking as a quick fix. That setting is only for a reviewed self-service installation model where anyone allowed to install the configured client ID is intentionally trusted.
The LTI Developer Key and API OAuth Developer Key are separate Canvas registrations. Do not exchange their client IDs or secrets.
The service deliberately fails closed when cached Canvas discovery is missing or stale. Restore availability through a successful Canvas refresh, not by editing database documents.
Use the browser developer console on a non-sensitive test assessment. Work through these checks in order:
  1. Confirm the active Canvas account/sub-account theme includes the loader script.
  2. Confirm the loader requests ${TOOL_URL}/js/canvas-seb-detector.js only on supported assessment routes.
  3. Confirm the request succeeds without CSP, mixed-content, DNS, or TLS errors.
  4. Confirm the detector does not load twice.
The supported Canvas routes are:
  • Classic Quiz: /courses/:courseId/quizzes/:quizId/take
  • New Quiz: /courses/:courseId/assignments/:assignmentId and its Canvas-generated descendants
If a self-hosted Canvas returns HTTP 422 with ActionController::InvalidCrossOriginRequest for its locally stored theme JavaScript attachment, use the externally hosted ${TOOL_URL}/js/canvas-seb-theme-loader.js workaround documented in Canvas setup, or move Canvas theme assets to supported object storage. Do not disable Canvas CSRF protection.
APP_DETECTOR_DIAGNOSTICS_ENABLED=true adds sanitized server-side detector tracing for development only. Production profile validation rejects this setting. Use a separate test deployment if additional detail is required.
The setup check is a readiness aid, not device attestation. Device-management status, operating-system policy, assistive-technology compatibility, and the approved SEB version must be verified separately by the institution.
If encryption is enabled, hardened startup requires a currently valid end-entity X.509 certificate with an RSA key suitable for encryption. The server must receive only the public certificate — never the private key or .p12.Compare the active public certificate:
The response includes an x-seb-public-key-hash header; compare it with the identity distributed to clients. Delete the temporary public certificate after use if your local policy requires it.If the private identity may be compromised:
  1. Pause affected assessments immediately.
  2. Rotate the identity and distribute the new private identity to clients.
  3. Deploy the matching public certificate to the service.
  4. Require fresh .seb configuration downloads.
Do not switch production to plaintext configuration as an incident shortcut.

Escalation Checklist

Before opening a non-sensitive support issue, confirm:
  • the problem reproduces on the current supported 1.x release;
  • /health, /ready, JWKS, LTI configuration, and detector endpoint results are recorded;
  • the exact role, placement, assessment type, and failure stage are known;
  • whether a fresh Canvas authorization and a fresh .seb configuration change the result;
  • whether it reproduces in an isolated test course and test account; and
  • logs have been redacted of credentials, tokens, session URLs, user data, and school-private hostnames where those are not essential.
Use GitHub private vulnerability reporting for any suspected security issue. Do not test against school or production systems without authorization.