starred/panel
1
0
Fork 0
mirror of https://github.com/pelican-dev/panel.git synced 2026-02-25 03:14:39 +03:00
Code Issues 42 Packages Projects Releases 12 Wiki Activity

[PR #1685] [CLOSED] Fix mixed content issues when running behind HTTPS reverse proxy #1521

New Issue
Closed
opened 2026-02-04 19:53:50 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-04 19:53:50 +03:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/pelican-dev/panel/pull/1685
Author: @PaulaBras
Created: 9/9/2025
Status: ❌ Closed

Base: main ← Head: main

📝 Commits (3)

  • 8804fd6 Initial plan
  • 1814ab6 Implement HTTPS reverse proxy support with TrustProxies middleware and enhanced URL generation
  • 61ff9ff Merge pull request #1 from PaulaBras/copilot/fix-https-reverse-proxy-asset-loading

📊 Changes

6 files changed (+138 additions, -2 deletions)

View changed files

📝 .env.example (+5 -1)
➕ app/Http/Middleware/TrustProxies.php (+36 -0)
📝 app/Providers/AppServiceProvider.php (+12 -1)
📝 bootstrap/app.php (+2 -0)
📝 config/session.php (+26 -0)
📝 readme.md (+57 -0)

📄 Description

TL;DR PR fixes the HTTPS reverse proxy issue. For your scenario (HTTPS outside, HTTP inside container)

Problem

When deploying Pelican Panel behind an HTTPS reverse proxy (nginx, Apache, Cloudflare, etc.), the application generates HTTP asset URLs instead of HTTPS, causing browsers to block mixed content. This results in:

  • Mixed Content Errors: Mixed Content: Blocked loading mixed active content "http://example.com/css/app.css"
  • JavaScript Runtime Errors: TypeError: can't access property "then", a.default.detectStore(...) is undefined
  • Broken Filament Components: Alpine.js expressions fail with table is not defined and selectFormComponent is not defined
  • Failed Livewire Hydration: Components don't initialize properly due to blocked assets

Root Cause

Laravel wasn't detecting the original HTTPS protocol from reverse proxy headers because:

  1. Missing TrustProxies middleware - Laravel couldn't read X-Forwarded-Proto headers
  2. Insufficient HTTPS forcing - Only worked when APP_URL explicitly started with https://
  3. No proxy header detection - Production deployments behind proxies weren't handled

Solution

1. Added TrustProxies Middleware

Created app/Http/Middleware/TrustProxies.php that:

  • Trusts all standard forwarded headers (X-Forwarded-Proto, X-Forwarded-Host, etc.)
  • Supports configurable proxy trust via TRUST_PROXIES environment variable
  • Registered in application bootstrap for all requests

2. Enhanced HTTPS Detection

Modified AppServiceProvider.php to force HTTPS scheme when:

  • APP_URL starts with https:// (existing behavior)
  • OR running in production with X-Forwarded-Proto: https header (new)
  • OR X-Forwarded-SSL: on header is present
  • OR request is detected as secure

3. Secure Session Configuration

Added secure cookie settings to prevent session hijacking:

  • SESSION_SECURE_COOKIE - ensures cookies only sent over HTTPS
  • SESSION_SAME_SITE_COOKIE - CSRF protection with lax default

4. Updated Environment Defaults

Changed .env.example to be HTTPS-friendly by default:

APP_URL=https://example.com
TRUST_PROXIES=*
SESSION_SECURE_COOKIE=true

5. Added Documentation

Comprehensive reverse proxy setup guide in README with:

  • Required environment variables
  • Complete nginx configuration example
  • Clear instructions for deployment

AI

yes this was made with and by AI

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/pelican-dev/panel/pull/1685 **Author:** [@PaulaBras](https://github.com/PaulaBras) **Created:** 9/9/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `main` --- ### 📝 Commits (3) - [`8804fd6`](https://github.com/pelican-dev/panel/commit/8804fd699486882d8ceb10df465fef8ecd67de16) Initial plan - [`1814ab6`](https://github.com/pelican-dev/panel/commit/1814ab68e23b43b79c1f1696fe5af1fc7c1de1c6) Implement HTTPS reverse proxy support with TrustProxies middleware and enhanced URL generation - [`61ff9ff`](https://github.com/pelican-dev/panel/commit/61ff9ff8e27cf7b6d663fc8c5cad70b29564d908) Merge pull request #1 from PaulaBras/copilot/fix-https-reverse-proxy-asset-loading ### 📊 Changes **6 files changed** (+138 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `.env.example` (+5 -1) ➕ `app/Http/Middleware/TrustProxies.php` (+36 -0) 📝 `app/Providers/AppServiceProvider.php` (+12 -1) 📝 `bootstrap/app.php` (+2 -0) 📝 `config/session.php` (+26 -0) 📝 `readme.md` (+57 -0) </details> ### 📄 Description TL;DR PR fixes the HTTPS reverse proxy issue. For your scenario (HTTPS outside, HTTP inside container) ## Problem When deploying Pelican Panel behind an HTTPS reverse proxy (nginx, Apache, Cloudflare, etc.), the application generates HTTP asset URLs instead of HTTPS, causing browsers to block mixed content. This results in: - **Mixed Content Errors**: `Mixed Content: Blocked loading mixed active content "http://example.com/css/app.css"` - **JavaScript Runtime Errors**: `TypeError: can't access property "then", a.default.detectStore(...) is undefined` - **Broken Filament Components**: Alpine.js expressions fail with `table is not defined` and `selectFormComponent is not defined` - **Failed Livewire Hydration**: Components don't initialize properly due to blocked assets ## Root Cause Laravel wasn't detecting the original HTTPS protocol from reverse proxy headers because: 1. **Missing TrustProxies middleware** - Laravel couldn't read `X-Forwarded-Proto` headers 2. **Insufficient HTTPS forcing** - Only worked when `APP_URL` explicitly started with `https://` 3. **No proxy header detection** - Production deployments behind proxies weren't handled ## Solution ### 1. Added TrustProxies Middleware Created `app/Http/Middleware/TrustProxies.php` that: - Trusts all standard forwarded headers (`X-Forwarded-Proto`, `X-Forwarded-Host`, etc.) - Supports configurable proxy trust via `TRUST_PROXIES` environment variable - Registered in application bootstrap for all requests ### 2. Enhanced HTTPS Detection Modified `AppServiceProvider.php` to force HTTPS scheme when: - `APP_URL` starts with `https://` (existing behavior) - **OR** running in production with `X-Forwarded-Proto: https` header (new) - **OR** `X-Forwarded-SSL: on` header is present - **OR** request is detected as secure ### 3. Secure Session Configuration Added secure cookie settings to prevent session hijacking: - `SESSION_SECURE_COOKIE` - ensures cookies only sent over HTTPS - `SESSION_SAME_SITE_COOKIE` - CSRF protection with `lax` default ### 4. Updated Environment Defaults Changed `.env.example` to be HTTPS-friendly by default: ```env APP_URL=https://example.com TRUST_PROXIES=* SESSION_SECURE_COOKIE=true ``` ### 5. Added Documentation Comprehensive reverse proxy setup guide in README with: - Required environment variables - Complete nginx configuration example - Clear instructions for deployment ## AI yes this was made with and by AI --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
OVERLORD added the pull-request label 2026-02-04 19:53:50 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
not confirmed
pull-request
Mirrored from GitHub Pull Request
 👑 sponsor
💰 fund
🔴 hard
🟡 medium
🟡 medium
🟡 medium
🟢 easy
🟢 easy
🟢 easy
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/panel#1521
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?