gotson / komga

Media server for comics/mangas/BDs/magazines/eBooks with API, OPDS and Kobo Sync support
https://komga.org
MIT License
4.11k stars 244 forks source link

Be able to set / use https in baseurl when running behind a reverse proxy #1242

Closed FlyveHest closed 1 year ago

FlyveHest commented 1 year ago

Describe your suggested feature

I've just installed Komga for the first time, running in Docker and running behind an Apache reverse proxy to supply https connectivity.

I've also setup oauth authentication against a Keycloak server, per https://komga.org/docs/installation/oauth2

But, the default setting for redirect-uri, {baseUrl}/{action}/oauth2/code/{registrationId} does not work in this configuration, it generates a http redirect, which should be https.

Hardcoding the complete string with https works, and authentication works as expected after doing that.

It would be nice to be able to set the baseurl as using https somewhere, or maybe note that this can be an issue.

(Tiny comment on the docs, Keycloak has dropped the auth part in their urls a while back, so http://localhost:8085/auth/realms/komgatest could be changed to http://localhost:8085/realms/komgatest :)

Other details

No response

Acknowledgements

gotson commented 1 year ago

I don't understand what's not working, can you explain more?

FlyveHest commented 1 year ago

When running Komga via docker, the webserver is using http. I am running Komga behind an Apache reverse proxy that uses https, and does not allow http connections at all.

When using OAUTH2, the redirect url generated for the client is using http, and because of this the authentication process never completes.

The redirect-url placeholders "{baseUrl}/{action}/oauth2/code/{registrationId}" are expanded into

"http://domain.tld/login/oauth2/code/keycloak" where in my case it should be "https://domain.tld/login/oauth2/code/keycloak"

I could fix it locally by just not using placeholders in the application.yml file, but it would be nice to just be able to configure the https scheme in the configuration for example.

Or, at least mention that this might be an issue when using keycloak or another idp running privately. (I'm guessing most people who run one are able to solve this problem themselves :)

gotson commented 1 year ago

You need to configure keycloak to hit your public https domain, and let your reverse proxy do the redirection to Komga.

gotson commented 1 year ago

You are also probably missing some setup in your reverse proxy, like x-forwarded-for

FlyveHest commented 1 year ago

Keycloak is configured correctly, valid redirect URIs is set to the https domain, but the redirect URL komga creates is http based and will not work.

Reverse proxy is configured correctly as well, I don't serve anything on http, so it will never work until Komga generates a https redirect URL.

As mentioned, I got it to work by hardcoding the redirect URL in application.yml, and as this is a set-it-and-forget-it parameter its not really an issue for me any longer.

But for future users I think it would be nice if they were able to configure the baseurl in Komga to be https, and not just that it assumes it to be http.

gotson commented 1 year ago

My RP works well, caddy sets proper forward headers. Do you set forward headers in your RP?

You say it's properly configured but you haven't shared any configuration of anything.

FlyveHest commented 1 year ago

The problem isn't in the reverse proxy at all, Keycloak rejects the authentication request because the redirect_url supplied by Komga does not match the valid redirect URL configured in the client in Keycloak.

gotson commented 1 year ago

You don't listen. Spring will interpret your reverse proxy forward headers to determine what is the actual origin.

It is most likely a reverse proxy mis-configuration. If the forward headers are not set, the server can't know where the request actually came from, whether it was http or https.

You mentioned you are using apache, which doesn't do anything out of the box for that. I asked you to share your config, but you still don't.

If you don't have forward headers, the server will consider localhost and http as the origin of the request, which obsiouvly won't work for oauth2.

That's how servers can serve the same content on multiple domain names for instance.

FlyveHest commented 1 year ago

My apache RP config is as follows, Komga is published to localhost on my server

  RemoteIPHeader X-Forwarded-For

  ProxyPreserveHost on
  ProxyRequests off
  AllowEncodedSlashes NoDecode

  ProxyPass / http://127.0.0.1:15012/ nocanon
  ProxyPassReverse / http://127.0.0.1:15012/

Note: Komga doesn't use localhost in the redirect URL, it uses the correct URL, just http instead of https, so it does get information about the proxying in front

gotson commented 1 year ago

You probably miss x-forwarded-proto then

FlyveHest commented 1 year ago

That was it! Thank you :)

Relevant working Apache configuration

  RemoteIPHeader X-Forwarded-For
  RequestHeader set X-Forwarded-Proto "https"

  ProxyPreserveHost on
  ProxyRequests off
  AllowEncodedSlashes NoDecode

  ProxyPass / http://127.0.0.1:15012/ nocanon
  ProxyPassReverse / http://127.0.0.1:15012/

A small note, this is in the https VirtualHost, so RequestHeader is hardcoded as https, if it is set in a http VirtualHost, just remove or omit it.