Invite users - onetime codes

[lumburovskalina]

Main

Related PRs:

• Invite users - onetime codes #41
• Invite users - onetime codes refinery-gateway#391
• https://github.com/code-kern-ai/cognition-gateway/pull/315
• https://github.com/code-kern-ai/dev-setup/pull/72
• https://github.com/code-kern-ai/deployment-cognition/pull/40

Info:

• solves onboarding problem with one time codes for inviting users with links, that were clicked by spam filters
• admin fix

[JWittmeyer]

I failed to remember to checkout the branch in dev-setup 😓

Maybe we should add a small check in the branch (-b) command if there is one for dev-setup and if yes it automatically goes there and checks out the latest version 🤔
I think with cursor this should be simple to implement

• discussed
• ignored
• implemented

[JWittmeyer]

Automated review (review-bot)

[JWittmeyer]

🤖 Review Bot Summary

Risk Level: CRITICAL

Findings: 25 total

• 🔴 Critical: 1
• 🟡 Suggestions: 12
• 🔵 Notes: 8
• ❓ Questions: 4

✅ code-kern-ai/dev-setup (3 findings)

• 🟡 templates/verification/body-verification.html.gotmpl: Verification templates still show VerificationURL (link) while kratos.yml uses use: code for verification. Recovery was switched to code-only and no longer shows a link. If verification is code-only, the link may be redundant or misleading; consider making verification templates code-only like recovery, or confirm that Kratos still provides VerificationURL in code flow.
• 🔵 template/refinery-compose.yml: INVITE_PAGE_URL uses {HOST}. Ensure HOST is substituted in all deployment environments (e.g. dev, staging, prod) so the invite page URL is correct.
• ❓: Recovery emails are code-only; verification emails show both link and code. Is showing both for verification intentional (e.g. fallback), or should verification match recovery and be code-only?

✅ code-kern-ai/cognition-gateway (2 findings)

• ❓ src/api/log_storage.py:114: When key is 'log_request' and the user is not admin, value is left unset (same as before). If downstream code expects a defined value (e.g. False or a default) in that case, consider setting it explicitly in an else branch.
• 🔵 submodules/model: Submodule pointer updated; the actual code changes are in the submodule repository and are not visible in this diff. Ensure the model submodule changes are reviewed separately.

✅ code-kern-ai/deployment-cognition (4 findings)

• 🟡 templates/verification/body-verification.html.gotmpl: Verification templates still show both VerificationURL (link) and VerificationCode. Recovery templates were switched to code-only. With kratos verification set to use: code, the link may be unused or invalid in code-based flow. Consider making verification code-only like recovery (remove link, show only code) for consistency and to avoid a potentially broken or misleading link.
• 🟡 templates/verification/body-verification.txt.gotmpl: Same as HTML template: link and code are both shown. For consistency with recovery and with use: code, consider showing only the verification code.
• 🔵 docker-compose.yml:171: INVITE_PAGE_URL is set to https://${APPLICATION_URL}/auth/invite. If APPLICATION_URL already includes the scheme (e.g. https://host), the result could be a double protocol. Confirm APPLICATION_URL is defined without scheme (e.g. host:port or domain) in this deployment.
• 🔵 kratos/kratos.yml.tmpl:122: Courier template keys were renamed to verification_code and recovery_code. Confirm these match the keys Kratos expects when selfservice.verification/recovery use use: code, so the correct templates are used.

⚠️ code-kern-ai/refinery-gateway (5 findings)

• 🔴 controller/auth/manager.py:27: INVITE_PAGE_URL is set from os.getenv('INVITE_PAGE_URL') with no validation. If the env var is missing, it is None, so _prepare_invite_link can return None or build invalid URLs like 'None?flow=...', breaking invite flows.
• 🟡 controller/auth/kratos.py:248: When the Kratos /recovery/code request fails (response not ok), the code returns None with no logging. That makes production debugging hard. Log status code and response body (or at least status) before returning.
• 🟡 controller/auth/manager.py:185: Building the invite URL with f"{INVITE_PAGE_URL}?flow={flow_id}" can produce an invalid URL if INVITE_PAGE_URL already has a query string (e.g. 'https://app.com/invite?foo=bar' becomes '...?foo=bar?flow=...'). Prefer adding the flow parameter via urllib.parse (e.g. parse_qs on INVITE_PAGE_URL, add/overwrite flow, then reconstruct).
• 🔵 controller/auth/manager.py:239: invite_link is built from _prepare_invite_link(recovery.get('recovery_link') or ''). If Kratos /recovery/code no longer returns recovery_link, invite_link will always be INVITE_PAGE_URL (with optional ?flow=). Confirm with Kratos API contract that recovery_link is still present and desired for the invite page URL.
• ❓ controller/auth/kratos.py: LANGUAGE_INVITE_WITH_CODE uses .format(invite_link=..., recovery_code=...). If the Kratos recovery_code can ever contain curly braces (e.g. for a future format), .format() could raise or misbehave. Is the code format strictly alphanumeric or otherwise safe for .format?

✅ code-kern-ai/refinery-entry (11 findings)

• 🟡 pages/invite.tsx:52: Avoid any for caught errors. Type the error (e.g. from axios or your API client) so handlers can safely use response/status.
• 🟡 pages/recovery.tsx:56: Replace err: any with a specific error type (e.g. AxiosError or a custom API error type) to satisfy the TypeScript policy.
• 🟡 pages/verify.tsx:68: Multiple catch blocks use err: any. Use a typed error (e.g. unknown or AxiosError) and narrow with type guards.
• 🟡 pages/invite.tsx:22: Mutating the API response (e.g. data.ui.nodes and node.meta.label) can cause subtle bugs and breaks immutability. Clone the flow (or nodes) before mutating.
• 🟡 pages/recovery.tsx:31: Same pattern: mutating data.ui.nodes and attrs in place. Prefer copying nodes/attrs before modifying to avoid shared reference issues.
• 🟡 pages/verify.tsx:28: Mutating data.ui.nodes and attrs on the response object. Clone the flow or nodes before applying label/value changes.
• 🟡 pages/invite.tsx: No loading or disabled state during submit; user can trigger multiple recovery flows. Consider disabling the submit button or showing loading while the request is in flight.
• 🔵 pages/invite.tsx:40: flow?.id in onSubmit can be undefined if submit runs before/without flow. Consider asserting flow (e.g. early return) or disabling submit when !flow.
• 🔵 pages/recovery.tsx:26: return_to was removed from the URL and recovery flow creation now always uses returnTo: "/settings". If deep links relied on return_to, this changes behavior.
• 🔵 pages/verify.tsx:22: Verify page only fetches a flow when flowId is in the URL; the previous createBrowserVerificationFlow() path for /verify without ?flow= was removed. Visiting /verify without a flow id now shows nothing.
• ❓ pages/recovery.tsx:103: data-testid="forgot-password" was removed from the "Go back to login" link. Do any tests or E2E flows depend on this selector?

[JWittmeyer]

Automated review (review-bot)