Skip to content
This repository has been archived by the owner on Jan 2, 2021. It is now read-only.

login issues with https reverse proxy #2037

Closed
icebal opened this issue Jul 27, 2018 · 7 comments
Closed

login issues with https reverse proxy #2037

icebal opened this issue Jul 27, 2018 · 7 comments

Comments

@icebal
Copy link

icebal commented Jul 27, 2018

while using traefik to do reverse proxying, mylar with form based login doesn't redirect to https (provided by the reverse proxy) but instead redirects the http (mylar setting). i also have noticed with the popup login it redirects to /index.html/home instead of /home, without the reverse proxy it redirects to /home like normal.

@evilhero
Copy link
Owner

which version of Mylar are you running (branch / commit) ?

I know several users are using Mylar with nginx reverse proxy (a couple are actually the ones that helped iron out some other bugs with the proxy paths) - so we know it's working.

I'm just not sure what the difference is between nginx and traefik when it comes to the reverse proxy (considering I have zero knowledge in reverse proxy stuff, so I can't really be of much help). Maybe someone who is successfully running Mylar behind a reverse proxy might be able to offer some more insight/help, as of right now all I can think of asking is what your web_root is set to in the config.ini

@BRTPOB
Copy link

BRTPOB commented Jul 28, 2018

icebal, how do you have your proxy setup and what's the webroot you've got in your mylar.ini? I'm one of the aforementioned users running with nginx, and yeah there were a few issues originally, but those are all ironed out and it's working like a champ now.

@icebal
Copy link
Author

icebal commented Jul 28, 2018 via email

@barbequesauce
Copy link
Contributor

Are you running any other Headphones-derivative (Headphones, SB/SG/SR, LazyLibrarian) in this manner? They all work basically the same. Anyway, if there's a problem forwarding the traffic internally it should show up in Traefik's error log...

That said, all my HP-derivatives work in nginx with a few more headers, most notably the Forwarded_For header:

  location /mylar {
    proxy_pass http://internalhost.local:8090;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect http:// https://;
    access_log /var/log/nginx/mylar.access.log;
    error_log /var/log/nginx/mylar.error.log;
  }

@icebal
Copy link
Author

icebal commented Jul 31, 2018

I use mostly the sonarr derivitives, which work fine. ill try to add the extra headers, but usually when this happens its an issue with not using magic urls, and fully qualifying redirects

@gsemet
Copy link

gsemet commented Aug 11, 2018

Hello. I have a similar problem with Synology (I am using Mylar in a docker container, and works pretty great!). The Synology DSM Reverse proxy use ngnix but with an hardcoded template (see this page for enabling websocket on this reverse proxy). Hardcoding http to https redirection in here means enable it for every app.

When enabling https in mylar, it expects to receive a https header and validate the connection with a certificate. In my case, DSM handles the SSL verification and strip out the https header to the server. We also do that at work with Traefik in front of our Kubernetes cluster.

Is it possible to optionalize the connection verification? The "Enable HTTPS" would display a sub option, enabled by default: "verify connection". If set, this will use the provided certificated and key to validate the connection. If unset, connection would not be validated, but the url of the application should starts by https.

@barbequesauce
Copy link
Contributor

Struggling to find an example of how this would be implemented with CherryPy. Have you seen it done anywhere that we could reference?

@evilhero evilhero closed this as completed Jan 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants