After upgrading to 1.6.5, console errors on /admin/login and 405 error with login

[slashk]

Pre-work

• I have read the docs.
• I have searched open and closed issues.
• I agree to follow this project's Code of Conduct.

Description

After upgrading to v1.6.5 (docker container), I can no longer login using Mac Safari (blank page) and I get errors in Goggle Chrome. I believe the heart of the issue is speediest-tracker is trying to load assets over an insecure URL even with the ASSET_URL set to https.

My setup is (url obfuscated):

internet --https://speedtest.xxxx.net--> HA Proxy --http://strongbox.xxxx.net:1234--> speedtest

I run this in a docker container with the ASSET_URL set to https://speedtest.xxxx.net

Here is the console bug in chrome (renders):

Mixed Content: The page at 'https://speedtest.xxxx.net/admin/login' was loaded over HTTPS, but requested an insecure script 'http://speedtest.xxxx.net/vendor/livewire/livewire.min.js?id=df3a17f2'. This request has been blocked; the content must be served over HTTPS.

Here is the console in Safari (doesn't not render):

The page at https://speedtest.xxxx.net/admin contains a form which targets an insecure URL http://speedtest.xxxx.net/admin/logout.
[blocked] The page at https://speedtest.xxxx.net/admin requested insecure content from http://speedtest.xxxx.net/vendor/livewire/livewire.min.js?id=df3a17f2. This content was blocked and must be served over HTTPS.

Once I login with Chrome (since it warns and doesn't block), I get the following error:

Oops! An Error Occurred
The server returned a "405 Method Not Allowed".
Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.

It seems like the 1.6.5 update doesn't respect the https in the ASSET_URL environmental variable. I assume this is somewhere in the filament code but don't know enough php or js to trace the codepath.

I assume this is the result of the warning above about the form targeting http: instead of https:

Expected Behavior

The /admin/login page should render and then allow me into the application after username / password input

Steps to Reproduce

1. Upgrade to 1.6.5
2. Set ASSET_URL as you are behind a HTTPS reverse proxy (mine in HA proxy).
3. Use Mac Safari or Mac Chrome to load https://speedtest.xxxx.net/admin

Deployment Environment

Docker Run

Application Information

{
  "environment": {
    "application_name": "Speedtest Tracker",
    "laravel_version": "12.20.0",
    "php_version": "8.4.10",
    "composer_version": "2.8.10",
    "environment": "production",
    "debug_mode": false,
    "url": "speedtest.xxxx.net",
    "maintenance_mode": false,
    "timezone": "UTC",
    "locale": "en"
  },
  "cache": {
    "config": true,
    "events": true,
    "routes": true,
    "views": true
  },
  "drivers": {
    "broadcasting": "null",
    "cache": "database",
    "database": "sqlite",
    "logs": "stderr",
    "mail": "log",
    "queue": "database",
    "session": "database"
  },
  "storage": {
    "\\/app\\/www\\/public\\/storage": false
  },
  "filament": {
    "version": "v3.3.31",
    "packages": "filament, forms, notifications, support, tables",
    "views": "NOT PUBLISHED",
    "blade_icons": "CACHED",
    "panel_components": "CACHED"
  },
  "livewire": {
    "livewire": "v3.6.4"
  },
  "speedtest_tracker": {
    "version": "v1.6.5"
  }
}

What browser(s) are you seeing the problem on?

Safari and Chrome

Logs

[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] done
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support the app dev(s) visit:
speedtest-tracker: https://github.com/sponsors/alexjustesen

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    10
───────────────────────────────────────
Linuxserver.io version: v1.6.5-ls102
Build-date: 2025-07-26T21:28:11+00:00
───────────────────────────────────────
    
using keys found in /config/keys
**** The following active confs have different version dates than the samples that are shipped. ****
**** This may be due to user customization or an update to the samples. ****
**** You should compare the following files to the samples in the same folder and update them. ****
**** Use the link at the top of the file to view the changelog. ****
┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐
│  old date  │  new date  │ path                                                                   │
├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤
│ 2024-12-17 │ 2025-05-31 │ /config/nginx/nginx.conf                                               │
│ 2024-07-16 │ 2025-05-31 │ /config/nginx/site-confs/default.conf                                  │
│ 2024-12-06 │ 2025-07-18 │ /config/nginx/ssl.conf                                                 │
└────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘
[custom-init] No custom files found, skipping...
crond[278]: crond (busybox 1.37.0) started, log level 5
crond[278]: user:root entry:*/15        *       *       *       *       run-parts /etc/periodic/15min
crond[278]: user:root entry:0   *       *       *       *       run-parts /etc/periodic/hourly
crond[278]: user:root entry:0   2       *       *       *       run-parts /etc/periodic/daily
crond[278]: user:root entry:0   3       *       *       6       run-parts /etc/periodic/weekly
crond[278]: user:root entry:0   5       1       *       *       run-parts /etc/periodic/monthly
crond[278]: user:abc entry:*       *       *       *       *       /usr/bin/php /app/www/artisan schedule:run -q
[ls.io-init] done.
[27-Jul-2025 16:46:28] NOTICE: fpm is running, pid 276
[27-Jul-2025 16:46:28] NOTICE: ready to handle connections
crond[278]: user:root entry:*/15****run-parts /etc/periodic/15min
crond[278]: user:root entry:0****run-parts /etc/periodic/hourly
crond[278]: user:root entry:02***run-parts /etc/periodic/daily
crond[278]: user:root entry:03**6run-parts /etc/periodic/weekly
crond[278]: user:root entry:051**run-parts /etc/periodic/monthly

[eleith]

i have an open [question] that documents another https bug with the public dashboard due to livewire being loaded over http (even though APP_URL and ASSET_URL are set to https values).

i will not i can't load the admin section either due to similar mixed content errors.

the workaround for now is to stay on 1.6.4.

in 1.6.4, livewire is loaded through a relative URL.

in 1.6.5 and 1.6.6 it is loading the full URL and without https the browser stops loading the page successfully.

[alexjustesen]

I run my instance using Traefik (with https) and I'm not having any issues with the Livewire assets so this doesn't seem to be global. Try a couple of things...

1. Clear the app's cache, you can do this by running php artisan cache:clear in the app/www directory. After you do this restart the app.
2. Make sure your proxy isn't caching assets.

As you can see, no issues here...

[eleith]

@alexjustesen thanks for the pushback.

i bypassed the reverse proxy and noticed that livewire still had the full url, but this time it was using the host i was accessing at (and not APP_URL or ASSETS_URL).

so that definitely pointed to a problem that i could solve with nginx.

in fact, this seems to have come up in discussion before: #889 (comment), i just haven't had any issues till now.

i can confirm it now works for me now by adding proxy_set_header X-Forwarded-Proto $scheme; to my proxy configuration.

[eleith]

proposed adding nginx to the existing documentation on proxies to help others in the future:

alexjustesen/speedtest-tracker-docs#82

[Deses]

Hi @eleith! So you fixed it by forwarding the headers and it just works?

I use Caddy, and I tried to do the same with

{
  servers {
    trusted_proxies static 192.168.0.0/21
  }
}

speedtest.home.lan {
    tls internal
    encode
    reverse_proxy 192.168.2.11:3080 {
        header_up Host {host}
        header_up X-Forwarded-Host {host}
        header_up X-Forwarded-Proto {scheme}
    }
}

But it still trying to serve content from http://192.168.2.11:3080/, and it's not just filament, the favicon also refuses to load.

Mixed Content: The page at 'https://speedtest.home.lan/' was loaded over HTTPS, but requested an insecure script 'http://192.168.2.11:3080/js/filament/support/support.js?v=3.3.34.0'. This request has been blocked; the content must be served over HTTPS.
Mixed Content: The page at 'https://speedtest.home.lan/' was loaded over HTTPS, but requested an insecure favicon 'http://192.168.2.11:3080/favicon.ico'. This request has been blocked; the content must be served over HTTPS.

Of course, env vars are set:

- APP_URL=https://speedtest.home.lan/
- ASSET_URL=https://speedtest.home.lan/

Any ideas? I can't figure out anything else. :(

And yes, pulling 1.6.4 works.

[eleith]

i had a few headers already setup, but i was missing the X-Forwarded-Proto header. the full headers (which i've documented in a proposed PR for the speedtest-tracker doc site) is:

location / {
 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-Server $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 proxy_pass http://speedtest-container-host:80;
}

for some reason, with the livewire update a few releases ago, this particular static asset is being loaded with a non-relative URL and that URL is dependent on a variety of forwarded heads (the majority of assets seems to use ASSET_URL instead).

when i loaded up the dashboard directly and also through my reverse proxy, i was able to debug what was missing.

[Deses]

That worked! I was missing two of the properties you used.

For Caddy, it should look like this:

speedtest.home.lan { 
    tls internal
    encode
    reverse_proxy http://192.168.2.11:3080 { #change the ip:port
        header_up X-Forwarded-Host {host}
        header_up X-Forwarded-Server {host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
}

Thank you very much for the help.

Would you be willing to add this to your PR? Thanks.