update backend manifest with oauth route

[MichaelClifford]

No description provided.

[github-actions]

Claude Code Review

Summary

This PR adds the BACKEND_URL environment variable to the backend deployment manifest, sourced from the google-workflow-app-secret Kubernetes Secret. This variable is used by the OAuth flow (introduced in PR #469 and #473) to construct redirect URIs for Google and GitHub OAuth callbacks.

Overall Assessment: This is a straightforward configuration change that follows established patterns in the codebase. However, there are several critical issues that must be addressed before merging.

Issues by Severity

Blocker Issues

1. Missing Secret Documentation

Location: components/manifests/base/backend-deployment.yaml:97-102

Issue: The PR adds a reference to BACKEND_URL in the google-workflow-app-secret, but there is no documentation indicating what value should be set, how to create/configure this secret, or example values for different environments.

Impact: Deployments will fail silently or use the fallback value (http://localhost:8080) which is incorrect for production environments. This breaks the OAuth flow.

Evidence from code (components/backend/handlers/oauth.go:178-181): The backend falls back to localhost:8080 if BACKEND_URL is not set, which will break OAuth in production.

Required Actions:

• Document BACKEND_URL in deployment guides or README
• Add example secret YAML showing all required keys in google-workflow-app-secret
• Update deployment guides to include this configuration step
• Consider adding validation in the backend to fail fast if BACKEND_URL is not set in production

2. Inconsistent Secret Distribution

Location: components/manifests/base/backend-deployment.yaml vs components/manifests/base/operator-deployment.yaml

Issue: The operator deployment also references google-workflow-app-secret for OAuth credentials (GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET), but does NOT include BACKEND_URL. This creates inconsistency.

Required Actions:

• Review if operator needs BACKEND_URL for OAuth functionality
• If yes, add it to operator deployment
• If no, document why the backend needs it but operator does not
• Ensure consistency across all components that handle OAuth

Critical Issues

3. No Validation of BACKEND_URL Format

Location: components/backend/handlers/oauth.go:178-182

Issue: The code uses BACKEND_URL directly without validation. No check if URL is well-formed, no check if URL scheme is HTTPS (production requirement), no check if URL matches registered OAuth redirect URIs.

Security Risk: Misconfigured BACKEND_URL could lead to OAuth redirect to incorrect URL, token leakage if URL is HTTP in production, or silent failures.

Required Actions:

• Add URL validation in backend startup
• Fail fast if BACKEND_URL is missing or malformed
• Add warning if non-HTTPS in production
• Add unit tests for URL validation

4. OAuth Security Concerns

Location: OAuth flow in components/backend/handlers/oauth.go

Issue: The BACKEND_URL must exactly match the redirect URI registered with OAuth providers (Google, GitHub). Mismatches cause OAuth failures. There is no validation that BACKEND_URL matches registered redirect URIs, no documentation of required OAuth configuration, and the fallback to localhost:8080 will break OAuth in all non-local environments.

Required Actions:

• Document OAuth provider configuration requirements
• Add startup validation checking BACKEND_URL format
• Consider making BACKEND_URL a required (non-optional) secret key
• Add troubleshooting guide for OAuth failures

Major Issues

5. Missing Environment-Specific Configuration Examples

Issue: No examples showing correct BACKEND_URL values for different environments (local development, minikube, production). Developers and operators will struggle to configure this correctly.

6. Optional Flag May Hide Configuration Errors

Location: components/manifests/base/backend-deployment.yaml:102

The secret key is marked as optional: true, which means backend will start even if BACKEND_URL is missing, OAuth flow will use fallback http://localhost:8080, and there will be no error logs or warnings until OAuth is attempted.

Recommendation: Make BACKEND_URL required (optional: false) if OAuth is enabled, OR add startup validation.

Minor Issues

7. Missing PR Description

Issue: The PR has an empty body. No context provided for why this change is needed, how to configure the new environment variable, what happens if it is not set, or links to related PRs.

Positive Highlights

• Follows Established Patterns: Uses the same pattern as existing OAuth environment variables
• Correct Secret Reference: Properly references google-workflow-app-secret
• Non-Breaking for Existing Deployments: Uses optional: true so existing deployments will not break
• Consistent with Backend Code: The manifest change correctly provides the variable that oauth.go expects
• Proper YAML Formatting: Correct indentation and structure

Recommendations

Priority 1 (Must Fix Before Merge):

1. Add documentation for BACKEND_URL configuration in deployment guides
2. Create secret example showing all required keys for google-workflow-app-secret
3. Add backend validation to fail fast if BACKEND_URL is malformed or missing when OAuth providers are configured
4. Review operator requirements - determine if operator also needs BACKEND_URL

Priority 2 (Should Fix Before Merge):
5. Add PR description explaining the change and configuration requirements
6. Consider removing optional: true or adding startup validation
7. Add environment-specific examples
8. Document OAuth provider configuration requirements

Priority 3 (Future Improvements):
9. Add health check endpoint validating OAuth configuration completeness
10. Add troubleshooting guide for OAuth failures
11. Consider configuration validation script for pre-deployment checks
12. Add integration tests for OAuth flow with different BACKEND_URL values

Conclusion

This is a necessary configuration change to support the OAuth functionality introduced in recent PRs. The change itself is correct, but lacks critical documentation and validation that would prevent production misconfigurations.

Recommendation: Request changes - address blocker issues #1-2 and critical issues #3-4 before merging.

Once documentation and validation are added, this will be a solid, maintainable addition to the codebase.

Review conducted using CLAUDE.md project standards, backend-development context, security-standards context, and error-handling patterns

---

🔍 View AI decision process (logs available for 90 days)

📋 View memory system files loaded (click to expand)

What Amber Loaded for Code Review

Amber automatically loaded these repository standards from the memory system:

1. CLAUDE.md - Master project instructions, development standards
2. backend-development.md - Go backend, K8s integration patterns
3. frontend-development.md - NextJS, Shadcn UI, React Query patterns
4. security-standards.md - Auth, RBAC, token handling
5. k8s-client-usage.md - User token vs service account patterns
6. error-handling.md - Consistent error patterns
7. react-query-usage.md - Data fetching patterns

Impact: This review used your repository's specific code quality standards, security patterns, and best practices from the memory system (PRs #359, #360) - not just generic code review guidelines.