feat: redirect anonymous GET / to the panel

[pcfreak30]

Summary

Redirect an anonymous GET / (server root) to the panel, so browsers that land on the root URL reach onboarding/login/dashboard instead of a 403 XML error. Genuine S3 traffic is unaffected.

Previously a root GET fell through to the S3 handler, where an unauthenticated ListBuckets returns 403 AccessDenied XML (s3/buckets.go:151) — a dead end for anyone typing the server URL.

Approach

GET / is the S3 ListBuckets operation, which requires SigV4 auth. Browsers never sign requests, so the redirect fires only when none of these S3 markers are present:

• SigV4 Authorization header (authenticated calls)
• X-Amz-* query params (presigned URLs)
• a {bucket}.{hostBase} virtual-host subdomain (host-style bucket listing at /)

Any of those pass through to the S3 handler untouched. No path other than exact / is affected.

Changes

• internal/handlers/handlers_root_redirect.go — new RootToPanelRedirect middleware with the S3-request discriminator.
• cmd/s3-server/main.go — wrap s3Root with handlers.RootToPanelRedirect(s3Root, cfg.S3.HostBases) before mounting at /.
• internal/handlers/handlers_root_redirect_test.go — unit tests for redirect + S3 pass-through cases.

Verification

• go build ./... ✅
• go vet ✅
• gofmt -l (clean) ✅
• go test ./internal/handlers/ -race ✅

---

This pull request adds a redirect mechanism that sends anonymous GET requests to the server root ("/") to the panel interface, while ensuring all genuine S3 API requests continue to work unaffected.

Key Changes

New Redirect Middleware

• Added a new RootToPanelRedirect middleware in internal/handlers/handlers_root_redirect.go that wraps the S3 handler
• When an anonymous GET request hits the server root, it redirects users to /_panel/ with a 302 Found status

Smart Request Detection

The middleware intelligently distinguishes between browser navigation and actual S3 API calls by checking for:

• Authenticated requests: Requests with SigV4 Authorization headers pass through
• Presigned requests: URLs containing X-Amz-* query parameters pass through
• Virtual-host style requests: Requests to bucket subdomains (e.g., {bucket}.s3.example.com) pass through

Implementation Details

• The middleware is applied in cmd/s3-server/main.go after the SSL bucket middleware and before the final route handling
• The detection logic mirrors how the S3 handler determines bucket ownership from the hostname
• Comprehensive test coverage verifies all pass-through scenarios (authenticated, presigned, virtual-host, non-root paths, and non-GET requests) still function correctly

Impact

This change improves the user experience by automatically directing web browsers to the panel interface when they visit the server's root URL, while maintaining full S3 API compatibility for all legitimate client requests.

[kody-ai]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​

[github-actions]

Docker image for testing

Pull the image for this PR:

docker pull ghcr.io/lumeweb/s3-server:sha-7b97f72

Or use in docker-compose:

services:
  s3-server:
    image: ghcr.io/lumeweb/s3-server:sha-7b97f72

The image is rebuilt on every push to this PR's branch.