Fix SSO redirect: use 302, trailing slash, remove S3#118
Merged
Conversation
…ucket - Switch from 301 to 302 to prevent browsers permanently caching the redirect. Stale cached 301s cannot be cleared remotely. - Add trailing slash to /start/ to avoid an extra 302 hop from AWS. - Set cache-control: no-cache instead of max-age=86400. - Remove the S3 bucket, website config, and public access block — they were dead weight since the CloudFront Function handles everything. Replace with dummy origin (invalid.invalid).
Terraform Plan🚧 Changes detected — Plan: 0 to add, 2 to change, 3 to destroy. Plan outputLLM ReviewRisk: 🟢 LOW Plan removes S3 website redirect infrastructure and updates CloudFront distribution to use a placeholder origin with modified redirect behavior.
|
Alexanderamiri
added a commit
that referenced
this pull request
May 9, 2026
## Summary - **301 → 302**: Prevents browsers permanently caching the redirect URL. Stale cached 301s were likely causing users to end up at aws.amazon.com. - **`/start` → `/start/`**: Saves an extra 302 hop (AWS adds trailing slash automatically). - **`cache-control: no-cache`**: Instead of 86400s cache, ensures fresh redirects. - **Remove S3 bucket**: The bucket, website config, and public access block were dead weight — the CloudFront Function intercepts all requests before reaching the origin. Replaced with `invalid.invalid` dummy origin. Net result: 3 fewer AWS resources, simpler stack, same functionality. ## Root cause of "ends up at aws.amazon.com" The 301 with `max-age=86400` was cached by browsers. The original redirect went to `/start` (no trailing slash) which then got another 302 from AWS. Browser caching of these intermediate redirects likely caused the portal SPA authentication flow to break. Note: The Identity Center portal is an AWS-hosted JavaScript SPA. If Google SAML authentication fails or cookies are blocked, users will still end up at aws.amazon.com — that's on AWS's side, not ours. ## Test plan - [ ] CI plan shows S3 resources destroyed, CloudFront function updated - [ ] `curl -sI https://aws.javabin.no` returns `302` with `location: https://javabin.awsapps.com/start/` - [ ] Clear browser cache and visit aws.javabin.no — should reach SSO login page
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/start→/start/: Saves an extra 302 hop (AWS adds trailing slash automatically).cache-control: no-cache: Instead of 86400s cache, ensures fresh redirects.invalid.invaliddummy origin.Net result: 3 fewer AWS resources, simpler stack, same functionality.
Root cause of "ends up at aws.amazon.com"
The 301 with
max-age=86400was cached by browsers. The original redirect went to/start(no trailing slash) which then got another 302 from AWS. Browser caching of these intermediate redirects likely caused the portal SPA authentication flow to break.Note: The Identity Center portal is an AWS-hosted JavaScript SPA. If Google SAML authentication fails or cookies are blocked, users will still end up at aws.amazon.com — that's on AWS's side, not ours.
Test plan
curl -sI https://aws.javabin.noreturns302withlocation: https://javabin.awsapps.com/start/