Enhancement: Nginx HTTPS/SSL/Port 443

[HcNguyen111]

Can the nginx.conf (prod.conf) and Dockerfile be updated to also open/listen on port 443 for HTTPS/SSL?

Currently, when navigating to my Fireshare instance under https://, I get "ERR_SSL_PROTOCOL_ERROR" (Chrome) and notice that Nginx only does a "listen 80 default;". Will the addition of "listen 443 ssl;" make HTTPS work or is there more to it?

Please look into this.

[ShaneIsrael]

No it doesn't make sense to have Fireshare itself try and support SSL. If you want Fireshare to be behind ssl you need to put it behind a reverse proxy and have an ssl certificate setup and registered to the domain your reverse proxy uses.

If you want a real simple way to do this that doesn't require any advanced knowledge I recommend using this in your docker stack. https://nginxproxymanager.com/

[HcNguyen111]

Sadly, I do use NPM... and can't get Fireshare to "work" through https://. I wondered if it was a Fireshare "thing" as going to https://local-ip:8080/ also fails (http:// is fine).

Any ideas?

[ShaneIsrael]

https on the local port will fail because fireshare itself isn't managing the ssl connection. You need to go through npm which will proxy the ssl request to fireshare.

On your proxy for fireshare in npm do the following.

Domain: input the domain you have set up for fireshare. For example. I have mine set to "v.fireshare.net". Scheme: http (don't use https here) Forward Hostname / Ip: set this to the local ip address of fireshare Forward Port: set this to 8080 or whatever port you configured fireshare to use.

Now under the SSL Tab click the SSL Certificate drop down and request a new SSL certificate.

Save

That is all you need to do to have Fireshare behind SSL. If you are going to use a sub domain for your domain like what I did in my example "v.fireshare.net" instead of "fireshare.net" You'll need to look up how to configure a subdomain from within your domain registrars dns settings. This isn't something I'm going to walk you through, you'll have to do some googling and learning.

[HcNguyen111]

Thanks for the details. Can you confirm Fireshare should also work under a reverse proxied (NPM) subdirectory? - e.g. site.com/fireshare

[ShaneIsrael]

It should not. Fireshare is a react app, not having it run at the root level will break the page routing.

There may be a way to set it up so that the page routing doesn't break, or can be handled correctly if set up that way but it's not something I am going to put time into.

If you or somebody knows how to set up react routing to handle both situations, it's open source and I welcome the contribution.

On Sun, Aug 7, 2022, 3:35 PM Cong Hoang Nguyen @.***> wrote:

Thanks for the details. Can you confirm Fireshare should also work under a reverse proxied (NPM) subdirectory? - e.g. site.com/fireshare

— Reply to this email directly, view it on GitHub https://github.com/ShaneIsrael/fireshare/issues/123#issuecomment-1207489710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMZPD5H5CG3QH24TYTICTDVYATYRANCNFSM55Z3IMWQ . You are receiving this because you commented.Message ID: @.***>

[HcNguyen111]

I've done some research. Can you / the broader community look into whether doing the below will do it?

• add a new export/ENV defined as APPLICATION_ROOT=/ to Dockerfile, docker-compose.yml, .env.prod
• set app.config['APPLICATION_ROOT'] = os.getenv('APPLICATION_ROOT') in create_app()
• add , url_prefix=app.config['APPLICATION_ROOT'] to the 3 instances of app.register_blueprint()

Source: https://stackoverflow.com/questions/18967441/add-a-prefix-to-all-flask-routes

Apologies, I've no way/knowledge to test any of this on my end as I don't (hopefully "yet") know how to push my test edits to my own "DockerHub repo". I guess now's the perfect time to read up and learn how...

[ShaneIsrael]

Well you googled how to do that for a UI served by flask/python... The front end is a react app. Has nothing to do with Python.

It's a lot more involved than simply setting a root. Even in react you can set a root but that's only one part of the problem. Unless you have the entire apps routing logic designed around using a non root location there will be problems. It's not impossible but every time I've ever messed with non root react apps stuff breaks.

It makes more sense to simply use a subdomain. Why are you so against using a subdomain?

On Tue, Aug 9, 2022, 8:00 AM Cong Hoang Nguyen @.***> wrote:

I've done some research. Can you / the broader community look into whether adding:

• app.config['APPLICATION_ROOT'] = os.getenv('APPLICATION_ROOT') to create_app()
• a matching export/ENV defined as APPLICATION_ROOT=/ to Dockerfile, docker-compose.yml, .env.prod,
• , url_prefix=app.config['APPLICATION_ROOT'] to the 3 app.register_blueprint()s will do it?

Source: https://stackoverflow.com/questions/18967441/add-a-prefix-to-all-flask-routes

Apologies, I've no way/knowledge to test any of this on my end as I don't (hopefully "yet") know how to push my test edits to my own "DockerHub repo". I guess now's the perfect time to read up and learn how...

— Reply to this email directly, view it on GitHub https://github.com/ShaneIsrael/fireshare/issues/123#issuecomment-1209422170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMZPD74QPFES26NHJ3TID3VYJQATANCNFSM55Z3IMWQ . You are receiving this because you commented.Message ID: @.***>

[HcNguyen111]

Mainly because everything else I have running are under their own reverse proxied subfolders (via Nginx Proxy Manager), but really it's because the DynDNS service/plan I use (free) doesn't support custom CNAME/subdomains (unless I decide to pay extra for it).

I may be wrong but am pretty sure Fireshare is being served by gunicorn through a flask app. I've only looked into this side of things, and do realise that the React/UI side may need updates too.

I'll give this all a go one day, but like yourself I don't have time, and don't expect you to take time out of your life to work on something where there is already an alternative method (subdomain). It's just my arrogant thought of "if all these other things can do it, surely I can help make this one do it too".

NOTE: none of the above is intended to be aggressive/disagreeing. Thanks for the awesomeness that Fireshare is.

[ShaneIsrael]

Gunicorn is serving the python api which interfaces with the database. But the routes are all handled by an internal nginx process which proxies them to the python app. So the only thing that needs to be updated is the React Application to properly handle a non root address and probably some of the nginx configs. I'm sure I could figure it out it would just take some time and its not something I know how to do right off the top of my head. It would likely also require some additional setup because if changes to the nginx config are required I would need to have a script that properly updates those configs correctly if the user decides to use a "non root" path.

So maybe in the future this is something I can visit if it seems like there's a lot of push for that as a feature but for now I personally will pass on it. Once winter hits I'll likely have a lot more time to dedicate to my personal projects and may be able to look into adding this feature.

I do apologize that it won't work for you right out the gate though. However I am a little curious as to why DynDNS doesn't support a custom cname. I've never seen that. I pay for my domains through namecheap and google domains and both offer that by default.