Excluding Certain Path From Frontity Routing To Allow Server Side Response for "Let's Encrypt" Challenge


First post, so excuse any faux pas.

I’ve got a pretty good grip of the basics and had deployed my site properly.

That site was hosted on SpinupWP, which for the most part I can’t recommend enough.

They had a pretty handy function to allow you to enable an automated script of Certbot to create and get an authorised SSL certificate from Let’s Encrypt.

However, to allow this to happen, the Let’s Encrypt service needs to send a challenge to a specific sub-directory ‘example.com/.well-known/acme-challenge/’ and expects to find a text file containing a fingerprint on the server.

For the quick amongst you, you can probably already see the issue that I’ve got.

Frontity/React is capturing all URLs and routing it on the client-side - so that path is returning a 404 from the client-side and never reaching the server side.

I need to exclude that directory from the routing of frontity/react otherwise I can’t get an SSL certificate and my website “onepixelwide.co.uk” will not load.

After a couple of days of googling and prodding around to realise it wasn’t an Nginx/Ubuntu server issue, I’m now trying to see if it’s possible to allow certain paths to head to be excluded by Frontity.

Firstly, I hope the above made sense, and secondly, any help would be massively appreciated.



Hi @OnePixelWide! I’m currently working on the server extensibility, which would allow you to set custom middleware to the Koa server that runs Frontity. In the meanwhile, however, a workaround is to create a node server and set handlers before Frontity. You can access frontity from the server like this:

const frontity = require("./build/server");

server((req, res) => frontity.default(req, res));

I hope this points you in the right direction, at least until the server extensibility is released.

1 Like

Hi @orballo, thanks for getting back to me. Funnily enough, I found the discussion about server extensibility after I posted this. I ended up adding an Nginx location rule ahead of the proxy, seems to do the trick, but it’s good to know there is a workaround and the functionality is coming. Thanks for all your effort.