mirror of
https://github.com/koel/koel.git
synced 2026-04-25 16:56:02 +03:00
[GH-ISSUE #1796] [v7.0.y] Error 500 "Untrusted Host" until setting APP_URL #995
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#995
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @MichaIng on GitHub (Jul 16, 2024).
Original GitHub issue: https://github.com/koel/koel/issues/1796
Describe the bug
Prior to Koel v7.0.0, it was not needed to set
APP_URLto access the web interface. Since v7.0.0 (just tested also with v7.0.6), if the host inAPP_URLdoes not match the host of the client (protocol/scheme and port do not matter), the access fails with this exception:Click to expend
I guess it is not even related to a change in Koel itself, but probably a change in Laravel, in whether/how trusted hosts are checked based on
APP_URL. Either replacinglocalhostwith the IP or hostname you use solves it, or switching to forced HTTPS. When doing the latter, the middleware adds the client host to the list of trusted hosts automatically, basically disabling the Laravel trusted host feature: https://github.com/koel/koel/blob/master/app/Http/Middleware/ForceHttps.phpThe problem with
APP_URLis that it allows to set a single host only, while often multiple hostnames and IPs need to be accepted, especially when running Koel behind a proxy, or just for CLI vs LAN access etc. I guess there is a way to pass a list of multiple trusted hosts, probably even a native Laravel environment variable. I know this from other software like Nextcloud, where one can define a list, including*as wildcard.And not everyone can or wants to use HTTPS immediately, especially when aiming to setup Koel within LAN first, aiming to access via proxy, open port, public hostname etc later, or when it is just for development/testing purpose.
To reproduce
Steps to reproduce the behavior:
.env.exampleand configure the database (MariaDB) onlylocalhostinAPP_URLwith IP or hostname used to access from the browserExpected behavior
Login should at best work by default. Alternatively, there should be a documented way to configure multiple trusted hosts for Koel.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
Additional context
Probably the aim with this PR was somehow addressed again? #1706
But I could not find a related change, hence my guess that it has to do with the Laravel update.
@phanan commented on GitHub (Jul 16, 2024):
What's your suggestion? This is a change from Laravel, something beyond Koel's control.
@phanan commented on GitHub (Jul 16, 2024):
@MichaIng I found this in Laravel 10.x doc (Koel's version): https://laravel.com/docs/10.x/requests#configuring-trusted-hosts. Does it fix the issue?
@MichaIng commented on GitHub (Jul 16, 2024):
As yes, that is it. Interesting that is says it is disabled/commented by default. In Koel it is enabled by default since this commit, which is the issue.
Adding the correct host/IP to the array in
app/Http/Middleware/TrustHosts.phpsolves the issue, and to disable it, one can comment the$this->allSubdomainsOfApplicationUrl(),line inapp/Http/Middleware/TrustHosts.php, to return an empty array. This class is imported across a bunch of other scripts, like the one to enforce HTTPS, so it cannot be easily removed completely, and it is a good idea to have it easily available anyway.I wonder whether there is a way to define an array config key in
.env, and add that one toapp/Http/Middleware/TrustHosts.phpinstead. It could then be empty by default, so that all hosts are accepted, but users can easily configure it.Indeed this works:
Now I can define
TRUSTED_HOSTSin.env. If it is not defined or empty, access works regardless which host is used. If defined as comma-separated list of hosts, it works with those, and no other, e.g.:Nowadays, configs should be accessed differently, but requires another change then: https://stackoverflow.com/a/42393294
@phanan commented on GitHub (Jul 16, 2024):
We can go with
.env, exactly like how you suggested:Would you want to work on a PR?
@MichaIng commented on GitHub (Jul 16, 2024):
This won't work: If
APP_URLis defined, only the hostname defined in it (and all its sub domains) will be accepted. That way the list can be expanded, but by default access will still fail. I would suggest to have things working by default, and use trusted hosts entirely as optional feature, as intended by Laravel.@phanan commented on GitHub (Jul 16, 2024):
You're right, this should be opt-in, not opt-out. How about the edited version?
@MichaIng commented on GitHub (Jul 16, 2024):
Let me quickly test it, but that should work. Good to use the config this way with
config()as intended 👍.@MichaIng commented on GitHub (Jul 16, 2024):
Works perfectly fine, also with all variants: undefined, defined as empty string, containing the used host, not containing the used host (then access fails as intended).
EDIT: Btw, the issue with missing GUI elements I noted OP has been solved with one of the recent releases. Was there until v7.0.2, IIRC, but forgot to test this with the latest version.
@phanan commented on GitHub (Jul 16, 2024):
Great! Care to send the PR over?
@MichaIng commented on GitHub (Jul 16, 2024):
Will do so. But probably tomorrow, as it is already late at night here 😴.
@phanan commented on GitHub (Jul 16, 2024):
Of course. When you do, please tag me.
@MichaIng commented on GitHub (Jul 16, 2024):
PR is up: #1797
My concentration was still enough, hopefully error-free 😄. Will test it again tomorrow with this exact diff.
@phanan commented on GitHub (Jul 17, 2024):
Released in v7.0.8. Thanks for reporting and fixing.
Btw @MichaIng Where should I discuss this remark?
@MichaIng commented on GitHub (Jul 17, 2024):
🙈 No need to discuss, I'll remove this pros/cons. It is from several years ago, not done by me, and I am no fans or such pros/cons anyway, which are based on things which change, personal opinion or things which cannot be easily compared. If someone writes a blog post after comparing a bunch of web UI music streamers, with particular timestamp and transparent author, fine. But on an overview page like this it has no place. The "bulky" installation note e.g. might be from a time where Node.js was installed and frontend compiled, while we use the pre-compiled archive now. Since the builtin webserver is used, its base installation is even lighter than most other PHP applications we have install options for, while of course a webserver or proxy in front of it still makes sense, especially when running more web UI apps in the system.
@phanan commented on GitHub (Jul 17, 2024):
Amazing, thanks a lot @MichaIng!