CSS not applying to site. Keter with Nginx Reverse proxy

[Xavier Waller]

Hello,

When I first set up my site, I was using keter with no reverse proxy or security cert following Yesod Book exactly with no deviations of note. My site worked as designed yet had no security cert or reverse proxy. 

Recently, I have added a letsencrypt security cert and added a reverse-proxy setup with nginx following the functor.tokyo tutorial here. Now the site is https, but the CSS does not apply. Before it was applying to the HTML. 

I have opened a stackoverflow question here. 

Are there any suggestions? 

Cheers,

Xavier

[Xavier Waller]

Also, the `yesod devel` still renders the site correctly on localhost.

[Michael Snoyman]

I’d recommend looking in the web browser’s dev tools and console to see if there are any errors, or perhaps some weird caching behavior occurring.

--

You received this message because you are subscribed to the Google Groups "Yesod Web Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to yesodweb+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/yesodweb/d3ff3b3f-0fce-4911-a9c8-40e62ef47b17n%40googlegroups.com.

[Xavier Waller]

Thanks, Michael.

The console gives these as warnings:

“[blocked] The page at [my domain] was not allowed to run insecure content from http://mydomain.com/static/css.bootstrap.css?etag.....”

“[blocked] The page at [my domain] was not allowed to run insecure content from http://mydomain.com/static/tmp/autogen-abcde12345.css.”

“The page at [my domain] was not allowed to run insecure content from http://mydomain.com/static/tmp/autogen-vwxyz67890.js.”

Further investigation shows:

<link rel="stylesheet" href=http://mydomain.com/static/tmp/autogen-abcde12345.css”>  Inline message from console:[blocked The page at https://mydomain.com was not allowed]

I’ve gone into the source of my project. In the "default-layer-wrapper.hamlet" file, that `href` is coming from:

^{pageHead pc}

This `pageHead pc` is expanding to http://mydomain.com instead of https://mydomain.com.

The `pc` is the standard Yesod convention for the output of the `widgetToPageContent`. Yet grepping for “pageHead” or “Head” only results in that widgetfile and a bunch of binaries. So I’m not sure where to troubleshoot this `pageHead`.

That’s what I’ve got so far!

Cheers,

Xavier

[jsch...@gmail.com]

I think it's because your reverse proxy server asks the web app using unencrypted http:// – that's why the web app assumes http://

I had the same issue and solved it in nginx with proxy_set_header, about like this:

    server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name xxx.xxx;

        ssl_certificate /etc/letsencrypt/live/intensovet.duckdns.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/intensovet.duckdns.org/privkey.pem;

        location / {
          proxy_pass http://localhost:3000$uri;
          proxy_set_header Host $host;
          proxy_set_header X-Forwarded-Proto https;
        }
    }

Before I did it like this, I thought, I have to also make the web app using https:// but that's not necessary.

See https://groups.google.com/g/yesodweb/c/qNz9KY4k6QA/m/ddO4yYMzBQAJ

[Xavier Waller]

Thank you. I will read the documentation for nginx regarding those and similar keywords.  

[Xavier Waller]

Hi,

I’ve been working through the book “Nginx HTTP Server” of and on since I asked this question. I’m still not quite sure what setting to change/add to the config file. The website I am building really is just a simple website, nothing fancy. I just decided to use Yesod as an excuse to learn/use Haskell (since that’s the only way you can get a Haskell job). By all intents, Yesod is overkill for my needs. With that being stated, I would think that my use case is the simplest case one could have for making a site with Yesod. I am going to attach the config file. Strictly speaking it's probably not good from an infosec standpoint, but considering that my site doesn’t work at all (no CSS), I am willing to take the risk. I can harden the file later.

Link to image of file (with annotations)

Any assistance would be helpful. It really is just a simple website using keter, nginx, and Yesod.

[jsch...@gmail.com]

I checked https://mathis.art/ – your Yesod web app returns HTML files with http links to CSS (instead of https links).

The line

proxy_set_header X-Forwarded-Proto https;

is correct in your nginx config.

But your Yesod app either ignores that header or the header is set back to http by keter (AFAIK keter is just another proxy).

Maybe you can change the appRoot of your app in one of the ways described here:

https://github.com/yesodweb/yesod/wiki/Overriding-approot

But I guess it's normally better to serve based on the request (default) instead of hard-code the appRoot. So I would look in keter documentation and check if keter changes the X-Forwarded-Proto header. You could also try without keter if you just want to have it working...

[Xavier Waller]

Thanks for taking a look. The keter documentation is largely the repo: https://github.com/snoyberg/keter/.

There are some FAQs with known issues with nginx on the main page, which I’ve already implemented. I’m open to a second opinion and/or set of eyes there. 

[jsch...@gmail.com]

Have you disabled HTTPS in your keter config?

[Xavier Waller]

I believe so. However, I have attached the two keter config files. One lives on the server and the other with the source code. I have labeled the folders as such. The link is here: https://www.dropbox.com/sh/u99iswgpxmz3zj4/AAD7Uoa4XPso88wf23VR5U4Va?dl=0

Thanks for any insights you may have.

[Xavier Waller]

Hi, Is there anyone who could look at those two files? They are just slightly modified versions of the files generated by the scaffolding.  Even the original lines are just commented out. It should be very easy for a seasoned eye to glance at it and see what's wrong. I'm just building a SPA blog. Very simple. 

[Michael Snoyman]

Probably the simplest solution here is to set the APPROOT environment variable in the Keter config. What seems to be happening is that the application you're running cannot detect that incoming requests are coming in over HTTPS instead of HTTP. Setting APPROOT explicitly to https://mathis.art would bypass the need for the guessing.

To view this discussion on the web visit https://groups.google.com/d/msgid/yesodweb/8350fa48-4c48-469e-946f-d1616df9eee4n%40googlegroups.com.