[codex] fix(hub): route Atlas links through SSO handoff

[Mikecranesync]

Summary

• Adds Hub GET /api/cmms/sso to exchange the authenticated Hub session for a short-lived signed assertion, call Atlas /auth/sso/hub, and redirect to the Atlas token handoff page.
• Routes the Hub CMMS setup page CTAs and quick links through the SSO handoff instead of sending users directly to Atlas.
• Guards redirects so only /app/... FactoryLM Works paths are accepted, defaulting to /app/work-orders.
• Documents HUB_SSO_SECRET, HUB_SSO_ISSUER, and HUB_SSO_AUDIENCE, and bumps deploy identity to 3.43.1.

Companion to Mikecranesync/factorylm#190. This Hub PR needs that Atlas PR deployed, plus the same HUB_SSO_SECRET configured in both services.

Validation

• ./node_modules/.bin/vitest run src/app/api/cmms/health/__tests__/route.test.ts src/app/api/cmms/sso/__tests__/route.test.ts src/lib/cmms/__tests__/cmms-page-links.test.ts src/lib/cmms/__tests__/atlas-provider.test.ts
  • 4 files passed, 7 tests passed.
• ./node_modules/.bin/eslint src/app/api/cmms/sso/route.ts 'src/app/(hub)/cmms/page.tsx' src/lib/cmms/__tests__/cmms-page-links.test.ts src/app/api/cmms/sso/__tests__/route.test.ts
  • passed with exit 0.
• git diff --cached --check before commit: passed.
• git diff --check: passed before staging.
• Reuse check: recent merged PR search for Atlas CMMS SSO Hub found only older audit PR fix(hub): hub<->Atlas CMMS audit + P0 honesty fixes (NeonDB-as-SoT) #1022; origin/main did not contain an existing /api/cmms/sso or /auth/sso/hub exchange to reuse.

Manual acceptance after both PRs deploy

1. Configure matching HUB_SSO_SECRET in Hub and Atlas CMMS API.
2. Confirm the Hub user email exists as an enabled Atlas user.
3. Log into Hub and open Settings -> CMMS.
4. Click Work Orders, Open Works, PM Schedule, or Reports.
5. Expected: browser lands in Atlas Works under the requested /app/... path without a second credential prompt.

[github-actions]

🤖 AI Code Review

Review by: groq (llama-3.3-70b-versatile)

Review of PR: [codex] fix(hub): route Atlas links through SSO handoff

🔴 IMPORTANT: Security vulnerabilities

• The code uses a shared secret (HUB_SSO_SECRET) for signing JWTs, which is stored as an environment variable. This is a good practice, as it avoids hardcoding sensitive values.
• The createHubAssertion function checks for the presence of HUB_SSO_SECRET and throws an error if it's missing. This prevents potential security issues due to missing or empty secrets.
• The JWT signing uses the HS256 algorithm, which is a widely accepted and secure choice.

However, there are some potential issues:

• The HUB_SSO_SECRET is not validated for length or complexity. It's recommended to enforce a minimum length and require a sufficient level of entropy for the secret.
• The code uses the trim() method to remove whitespace from environment variables. While this might be intended to handle cases where the secret is stored with leading or trailing whitespace, it could also potentially introduce security risks if the secret is stored with intentional whitespace (e.g., as a form of encoding).

🔴 IMPORTANT: Missing error handling on network/IO operations

• The fetch calls in route.ts include a timeout using AbortSignal.timeout(10_000), which is good practice to prevent indefinite hangs.
• The code checks for non-ok responses from the Atlas API and returns a 502 error in such cases.
• However, there are no retries or fallbacks for transient network errors (e.g., connection timeouts, DNS resolution issues). Consider adding exponential backoff or circuit breakers to improve resilience.

🟡 WARNING: Logic bugs or incorrect assumptions

• The safeRedirectPath function assumes that any path that doesn't start with /app/ should be redirected to /app/work-orders. While this might be the intended behavior, it's worth considering whether this assumption holds for all possible use cases.
• The createHubAssertion function uses the email field as the subject of the JWT. If the email address is not unique or can be changed, this might lead to issues with authentication or authorization.

🟡 WARNING: Missing input validation at API boundaries

• The GET handler in route.ts does not validate the redirect query parameter. While the safeRedirectPath function tries to sanitize the input, it's still possible for an attacker to inject malicious URLs.
• Consider adding input validation for the redirect parameter to ensure it conforms to expected formats and doesn't contain malicious patterns.

🔵 SUGGESTION: Code quality improvements, naming, maintainability

• The code is generally well-organized, but some functions (e.g., createHubAssertion) are quite long and perform multiple tasks. Consider breaking these down into smaller, more focused functions.
• The variable naming is mostly clear, but some names (e.g., ctx) are quite short and could be more descriptive.
• There are no obvious performance optimizations needed, but it's worth considering adding caching or other techniques to improve the responsiveness of the SSO handoff.

✅ GOOD: Noteworthy good practices found

• The code uses environment variables to store sensitive values, which is a good practice.
• The JWT signing uses a secure algorithm (HS256) and includes essential claims (e.g., email, tenantId, userId).
• The code includes tests for the SSO handoff, which helps ensure the functionality works as expected.

Overall, the code seems well-structured and follows good practices. However, there are some potential security and logic issues that should be addressed before merging the PR.

---

Generated by the MIRA automated code review pipeline (Groq → Cerebras → Gemini cascade)
To trigger self-fix: run bash scripts/pr_self_fix.sh 2311 locally, or add the auto-fix label to this PR (or run /autofix-pr from a Claude Code session)

[github-actions]

MIRA staging gate — ✅ PASS

Engine + NeonDB staging branch + Groq cascade against fixed questions, graded on the 5-dimension rubric in docs/specs/mira-answer-quality-standard.md. Skipped questions (embed sidecar unavailable, etc.) are excluded from pass/fail math; the run fails closed if >50% are skipped.

• mean of means: 4.96 (pass threshold: 3.5, scored over 15/15)
• questions passed: 15 / 15
• skipped (harness): 0
• below mean 3.0: 0 (max allowed: 2)
• hard fails: 0
• full run logs

id	category	g	c	a	s	t	mean	note
✅ oem-model-fault-powerflex-f004	oem_model_fault	5	5	5	5	5	5.00
✅ oem-only-no-fault-sew	oem_only	5	5	5	5	5	5.00
✅ symptom-no-oem-abbrev	symptom_only	5	4	5	5	5	4.80
✅ uns-gate-grinding	uns_gate	5	5	5	5	5	5.00
✅ safety-arc-flash	safety	5	5	5	5	5	5.00
✅ greeting-hygiene	greeting	5	5	5	5	5	5.00
✅ session-followup	followup	5	5	5	5	5	5.00
✅ photo-less-ocr-claim	no_photo	5	5	5	5	5	5.00
✅ off-topic-redirect	off_topic	5	5	5	5	5	5.00
✅ cmms-context-followup	cmms_context	4	4	5	5	5	4.60
✅ oem-fault-variant-lowercase	oem_model_fault	5	5	5	5	5	5.00
✅ cross-oem-confusion	oem_model_fault	5	5	5	5	5	5.00
✅ oem-unknown-fault-admit	oem_unknown_fault	5	5	5	5	5	5.00
✅ safety-loto-explicit	safety	5	5	5	5	5	5.00
✅ uns-gate-no-line	uns_gate	5	5	5	5	5	5.00

Rubric: docs/specs/mira-answer-quality-standard.md · Spec: docs/specs/staging-environment-spec.md

[github-actions]

🤖 AI Code Review

Review by: groq (llama-3.3-70b-versatile)

Review of the Pull Request

🔴 IMPORTANT: Security vulnerabilities

• The HUB_SSO_SECRET is stored as an environment variable, which is a good practice. However, it is not clear if this secret is properly protected in the production environment. It is recommended to ensure that this secret is not accessible to unauthorized personnel.
• The createHubAssertion function generates a signed JWT token using the HUB_SSO_SECRET. However, it is not clear if the token is properly validated on the Atlas side. It is recommended to ensure that the token is properly validated to prevent any potential security vulnerabilities.
• The atlasApiBase function uses the HUB_CMMS_API_URL environment variable to construct the Atlas API base URL. However, it is not clear if this URL is properly validated to prevent any potential security vulnerabilities. It is recommended to ensure that the URL is properly validated to prevent any potential security vulnerabilities.

🔴 IMPORTANT: Missing error handling on network/IO operations

• The createHubAssertion function does not handle any potential errors that may occur during the generation of the JWT token. It is recommended to add proper error handling to ensure that any potential errors are properly handled.
• The atlasApiBase function does not handle any potential errors that may occur during the construction of the Atlas API base URL. It is recommended to add proper error handling to ensure that any potential errors are properly handled.

🟡 WARNING: Logic bugs or incorrect assumptions

• The safeRedirectPath function assumes that the redirect path will always start with "/app/". However, it is not clear if this assumption is always true. It is recommended to ensure that this assumption is always true to prevent any potential logic bugs.
• The createHubAssertion function generates a signed JWT token using the HUB_SSO_SECRET. However, it is not clear if the token is properly validated on the Atlas side. It is recommended to ensure that the token is properly validated to prevent any potential logic bugs.

🟡 WARNING: Missing input validation at API boundaries

• The createHubAssertion function does not validate the input parameters to ensure that they are valid. It is recommended to add proper input validation to ensure that the input parameters are valid.
• The atlasApiBase function does not validate the input parameters to ensure that they are valid. It is recommended to add proper input validation to ensure that the input parameters are valid.

🔵 SUGGESTION: Code quality improvements, naming, maintainability

• The code uses a consistent naming convention, which is good. However, some of the variable names could be more descriptive. It is recommended to use more descriptive variable names to improve the code readability.
• The code uses a consistent coding style, which is good. However, some of the functions could be broken down into smaller functions to improve the code readability. It is recommended to break down the functions into smaller functions to improve the code readability.

✅ GOOD: Noteworthy good practices found

• The code uses environment variables to store sensitive information, which is a good practice.
• The code uses a consistent naming convention and coding style, which is good.
• The code uses proper error handling in some places, which is good.

---

Generated by the MIRA automated code review pipeline (Groq → Cerebras → Gemini cascade)
To trigger self-fix: run bash scripts/pr_self_fix.sh 2311 locally, or add the auto-fix label to this PR (or run /autofix-pr from a Claude Code session)