sso fallback fix - #3793
Conversation
|
Warning Review limit reached
Next review available in: 6 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe 3D device model scenes now load a specific HDRI file. Runtime environment detection and API URL selection were rewritten, exported configuration values became dynamic getters, and NextAuth now normalizes fallback settings and request-derived URLs. Changes3D Scene Environment
Runtime Configuration and Authentication
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/beacon/components/device-model-3d-inner.tsx`:
- Line 152: Update the Environment component in the device model 3D component to
construct the HDRI URL using the configured application base path rather than
the root-relative "/hdri/potsdamer_platz_1k.hdr" value, ensuring the asset
resolves correctly under basePath deployments.
In `@src/beacon/lib/auth.ts`:
- Around line 11-18: Remove the hardcoded NEXTAUTH_SECRET fallback from the
module initialization in auth.ts so production reaches the existing
missing-secret validation in options.ts; require NEXTAUTH_SECRET from the
environment, or load a local-only placeholder through .env.local. Also remove
the unconditional NEXTAUTH_URL production-domain fallback, and only provide a
development fallback when explicitly non-production, using the existing
environment detection after it is initialized.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 320d55e5-129f-4b4e-abc6-0f3e441beba6
📒 Files selected for processing (4)
src/beacon/components/device-model-3d-inner.tsxsrc/beacon/components/device-model-3d.tsxsrc/beacon/lib/auth.tssrc/beacon/public/hdri/potsdamer_platz_1k.hdr
|
New azure beacon changes available for preview here |
There was a problem hiding this comment.
Pull request overview
This PR adjusts Beacon’s authentication configuration to handle missing NextAuth environment variables more gracefully, and refreshes the 3D device scene lighting by switching the HDRI environment source.
Changes:
- Adds runtime fallbacks for
NEXTAUTH_URLandNEXTAUTH_SECRETin Beacon’s NextAuth configuration. - Updates
@react-three/drei<Environment />to load a specific HDR file instead of using the"city"preset (in two 3D components).
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/beacon/lib/auth.ts |
Introduces fallback behavior for NextAuth env vars used by Beacon authentication. |
src/beacon/components/device-model-3d.tsx |
Switches the 3D environment lighting/background to a specific HDRI file. |
src/beacon/components/device-model-3d-inner.tsx |
Mirrors the HDRI environment change for the inner 3D model component. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
New azure beacon changes available for preview here |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/beacon/app/api/auth/`[...nextauth]/route.ts:
- Around line 4-24: Remove the request-header-based NEXTAUTH_URL mutation from
the handler and delete the associated getHeader, host, and proto logic. Use the
deployment-specific auth URL configuration from authOptions or the existing auth
setup in auth.ts, keeping the request flow request-scoped and leaving the
NextAuth(req, res, authOptions) invocation intact.
In `@src/beacon/lib/config.js`:
- Around line 20-29: Unify private-network detection used by getEnvironment()
and isLocalhost so environment, beaconApiPrefix, and requiresAuth share one
accurate check. Restrict the 172 range to 172.16–172.31, retain valid 10.x and
192.168.x private ranges, and reuse the shared helper in both paths instead of
maintaining separate hostname conditions.
- Around line 139-149: Update the configured URL handling in the
development/staging and production branches of the platform API resolver to
enforce HTTPS before returning remote URLs. Apply the same HTTPS normalization
or validation used by getBeaconApiUrl() to stagingUrl and prodUrl, while
preserving trailing-slash removal and the existing default staging URL behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 08c212a2-8939-4d30-9912-23e5ddbcc824
📒 Files selected for processing (3)
src/beacon/app/api/auth/[...nextauth]/route.tssrc/beacon/lib/auth.tssrc/beacon/lib/config.js
|
New azure beacon changes available for preview here |
Summary of Changes (What does this PR do?)
Status of maturity (all need to be checked before merging):
How should this be manually tested?
What are the relevant tickets?
Screenshots (optional)
Summary by CodeRabbit
Visual Improvements
Bug Fixes
Configuration