SSL behind reverse proxy

[Nebucatnetzer]

I noticed that when I run PyWishlist behind a reverse proxy that some URLs aren't using SSL encryption.
After a quick test I think this would be the solution:
https://stackoverflow.com/questions/14810795/flask-url-for-generating-http-url-instead-of-https

[oxivanisher]

Interesting. Can you provide me with an example of a "not SSL" request? In my installation, its always SSL (the browser is "happy").

[oxivanisher]

Btw, here is my nginx config. Yours might be missing X-Forwarded-Proto, which would explain the behavior. (And yes, I should update the documentation . . . )

Also with the static being delivered directly, its even faster:

server {
    listen :80;
    server_name wish.example.tld;
    return 301 https://$host$request_uri;

    access_log /var/log/nginx/redirect-access.log;
    error_log /var/log/nginx/redirect-error.log;
}
server{
    listen :443 ssl http2;

    server_name  wish.example.tld;

    ssl_certificate /etc/letsencrypt/live/wish.wish.example.tld/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/wish.wish.example.tld/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/wish.wish.example.tld/fullchain.pem;

    location / {
        proxy_pass http://127.0.0.1:3036/;
        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_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location ^~ /static/  {
        include /etc/nginx/mime.types;
        root /path/to/your/PyWishlist/pywishlist/;
    }

    access_log /var/log/nginx/wish.wish.example.tld-access.log;
    error_log /var/log/nginx/wish.wish.example.tld-error.log;

    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

[Nebucatnetzer]

Hm after rebuilding the Docker image the browser is happy again.
The only one not working now is this one here:

<img src="//www.gravatar.com/avatar/cf0092a6e0f0f5e5d181b6fcea78801c?d=http%3A%2F%2Fwichteln.2li.ch%2Fstatic%2Fimg%2Fplaceholder.png&amp;s=80" title="Andreas Zweili" class="profileAvatar glow">

Which has a different problem, it drops the http part completely.

[oxivanisher]

no this is no problem. this is the right way to make a link without a specified protocol, where the browser chooses the protocol. ;)
https://stackoverflow.com/questions/21293029/why-using-href-instead-of-href-http-in-html

[Nebucatnetzer]

Learned something new here :).
After a closer look the problem is with the second part of the link.
It points to the placeholder.png but with http.
Adding the scheme='https' part to that url generation doesn't fix it.
However I don't really know Flask to begin with :)

[oxivanisher]

I took a look at the code, and it seems OK. On my machine, it generates a gravatar URL with https encoded in the string. But did you add the before mentioned header in your nginx cfg?
Also, since there is no real versioning or so at the moment, you might want to build your container with --force to be sure its taking updated code into consideration.

[Nebucatnetzer]

I've deleted the container with docker-compose down --rmi local which rebuilds it as well. I don't use Nginx but Apache as a reverse proxy (legacy :)) I've searched for the option and it's working now. `RequestHeader set X-Forwarded-Proto https` was the missing option. I wonder why I never had to use this option with another self hosted project. Tiny Tiny RSS even fails to load when I use that option. October 6, 2019 11:52 PM, "Marc Urben" <notifications@github.com> wrote:

…

I took a look at the code, and it seems OK. On my machine, it generates a gravatar URL with https encoded in the string. But did you add the before mentioned header in your nginx cfg? Also, since there is no real versioning or so at the moment, you might want to build your container with --force to be sure its taking updated code into consideration. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.