esitarski / RaceDB

Web-based bike race registration application
16 stars 10 forks source link

Feature Request - https #66

Open stuartlynne opened 7 months ago

stuartlynne commented 7 months ago

This can be confusing and easily missed when trying to download CrossMgr file minutes before the event starts while breathing heavily because you just ran 400m from the finish line to get the new download etc.

image

It is possible to fix this in Chrome. But the flags seem to move around, following this I eventually did get it added.

How to Enable or Disable Insecure Download Warning in Chrome. You can also whitelist entire websites via Chrome's settings: Settings > Security and Privacy > Site Settings > Insecure Content. Under Allowed to show insecure content click “Add” and enter the main website URL and click “Add”

image

This appears to be an issue with "insecure" sites, as in HTTP vs HTTPS.

If RaceDB added HTTPS support it would eliminate the need for organizers to jump through hoops to keep Chrome happy.

esitarski commented 7 months ago

Short answer:

And please go easy on me. Browser warnings about non-https web sites are not my fault ;) hjttps is not feasible with a stand-alone install (part of the reason I proposed a central multi-tenant RaceDB website). However, it is possible for you to do this yourself https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu as the underlying toolkit, Django, supports if (eg with nginx and Gunicorn). There are a number of additional configuration steps to get and maintain your encryption certificate.

For example, www.racedb.ca is fully https and runs the same code line-for-line as github RaceDB. It is just deployed differently with nginx and Gunicorn.

Very long answer:

Briefly, a web site has 3 major components:

  1. web server (nginx, apache, etc.)
  2. application server (WSGI HTTP, Gunicorn, uWSG, etc.)
  3. database server (postgres, mysql, etc.)

The web server process does encryption (https), serves static files, protects against denial of service attacks, etc. High performance. It receives the raw url GET and POST requests from a web browser and figures out what to do with it. In a simple configuration, urls that begin with "static" are files retrieved from a folder. This enables high-performance retrieval of images, javascript, style sheets and other content that does not change.

For all other urls, the web server is configured to forward the url to the "application server". The application server is a wrapper process around the application code (in the case of RaceDB, it is written in Python using Django).

The application server then reads/writes data from the database server, applies logic as necessary, then returns a response (eg. html, Excel, pdf) back to the web server, which then encrypts it and finally sends it to the user's browser. Of course, this is all multi-threaded and I/O optimized.

Distinct servers enable scalability options. For example, each server could be deployed on a seperate computer, or there can be multiple instances of the same server across multiple computers, with load balancing software controlling the requests. This really isn't much of a concern for RaceDB which is a relatively very low-volume web app.

Back to the original question - supporting https:

RaceDB ships with a "toy" built-in web server that is embedded in the same process as the application. It performs OK, but does not support https. The web server and application server are merged into one. The database process remains separate.

To support https, you really should use a real web server like nginx or apache. In the RaceDB context, a web server would have to be included in the Docker install. I know this is possible, but I currently lack the Docker skills to do it. I recently discovered there is a pure-Python https server here https://gist.github.com/DannyHinshaw/a3ac5991d66a2fe6d97a569c6cdac534 or here https://piware.de/2011/01/creating-an-https-server-in-python/.

However, an https-capable web server in RaceDB does not get you https. You also need a certificate. The free option is Let's Encrypt https://letsencrypt.org/ where you can get the certificate and permission. You have to renew the certificate every month, or Let's Encrypt will delete it and https stops working. This is usually done with a cron job running on the web server (you can also do it manually, but don't ever forget).

That's a one-time deal if you are running from a hosted web site. It is more complicated when you have a local server.

Solution: hosted RaceDB?

This is yet another level of complexity required to run RaceDB standalone, and brings us back to the idea of a common multi-tenant RaceDb web server and usb RFID readers on site.

The only use case this doesn't cover for you is printing the bib numbers automatically.

There may be a solution. "Email to Print" (eg, https://github.com/aardsoft/cups-email) is a cron job configured to monitor an email address(s) and print documents received on it. Say there was a new option in RaceDB that tells it to email pdfs to certain email addresses corresponding to different "printers" instead of downloading them in the web browser. RaceDB users would print bibs, Instead of downloading pdfs, RaceDB would send those pdfs to those email address(es). Software running on your on-venue server checks those inboxes and prints the attachments on the correct printer. Rather than sending to multiple email addresses, RaceDB could put a description in the email text and mail to one (whatever is easier).

On Sun, Mar 17, 2024 at 5:44 PM Stuart Lynne @.***> wrote:

This can be confusing and easily missed when trying to download CrossMgr file minutes before the event starts while breathing heavily because you just ran 400m from the finish line to get the new download etc.

image.png (view on web) https://github.com/esitarski/RaceDB/assets/297561/81df2211-bfdc-47ba-8ee7-6dee8e95dd82

It is possible to fix this in Chrome. But the flags seem to move around, following this I eventually did get it added.

How to Enable or Disable Insecure Download Warning in Chrome. You can also whitelist entire websites via Chrome's settings: Settings > Security and Privacy > Site Settings > Insecure Content. Under Allowed to show insecure content click “Add” and enter the main website URL and click “Add”

image.png (view on web) https://github.com/esitarski/RaceDB/assets/297561/925aca31-80c3-4e9a-91f8-f7e10bc9c3f4

This appears to be an issue with "insecure" sites, as in HTTP vs HTTPS.

If RaceDB added HTTPS support it would eliminate the need for organizers to jump through hoops to keep Chrome happy.

— Reply to this email directly, view it on GitHub https://github.com/esitarski/RaceDB/issues/66, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGXKNHG4YQIUMHXJQCTPDYYYFDVAVCNFSM6AAAAABE2Q62Z2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4TAOBXHE3TENQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Edward Sitarski

stuartlynne commented 7 months ago

I totally understand your pain...

Was just hoping it would not be too hard to install a self-signed cert. Chrome still complains, but in a different and slightly easier way to deal with. You have to jump through some hoops to get past the warnings. But seemingly once you do that things work more or less normally.

What was (is) insidious with the current behaviour WRT to downloaded files is that Chrome sometimes will popup on the screen you are on and say something, albeit with a small easily missed dialog. But sometimes it doesn't, and unless you go into the Downloads screen you won't see any problem before you try and upload an empty xlsx file into CrossMgr.

I'm hoping that the CrossMgr direct connect to RaceDB works well enough that we can switch to that. I tried an old Android phone last weekend with a Data only SIMM and that worked quite nicely in one of our more cellular challenged venues. Hope to have a second one for this weekend.

esitarski commented 7 months ago

CrossMgr direct connect should be fixed now. Requires upgrading to the most recent version of CrossMgr.

On Tue, Mar 19, 2024 at 1:44 PM Stuart Lynne @.***> wrote:

I totally understand your pain...

Was just hoping it would not be too hard to install a self-signed cert. Chrome still complains, but in a different and slightly easier way to deal with. You have to jump through some hoops to get past the warnings. But seemingly once you do that things work more or less normally.

What was (is) insidious with the current behaviour WRT to downloaded files is that Chrome sometimes will popup on the screen you are on and say something, albeit with a small easily missed dialog. But sometimes it doesn't, and unless you go into the Downloads screen you won't see any problem before you try and upload an empty xlsx file into CrossMgr.

I'm hoping that the CrossMgr direct connect to RaceDB works well enough that we can switch to that. I tried an old Android phone last weekend with a Data only SIMM and that worked quite nicely in one of our more cellular challenged venues. Hope to have a second one for this weekend.

— Reply to this email directly, view it on GitHub https://github.com/esitarski/RaceDB/issues/66#issuecomment-2007784332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGXKLFKGP24HCLM4RJ2PTYZB2PDAVCNFSM6AAAAABE2Q62Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBXG44DIMZTGI . You are receiving this because you commented.Message ID: @.***>

--

Edward Sitarski

stuartlynne commented 7 months ago

Thanks! On my list of things to test.

Should have a second Android phone today, and a data SIM by the weekend. So some incentive!

On Tue, Mar 19, 2024 at 11:38 AM Edward Sitarski @.***> wrote:

CrossMgr direct connect should be fixed now. Requires upgrading to the most recent version of CrossMgr.

On Tue, Mar 19, 2024 at 1:44 PM Stuart Lynne @.***> wrote:

I totally understand your pain...

Was just hoping it would not be too hard to install a self-signed cert. Chrome still complains, but in a different and slightly easier way to deal with. You have to jump through some hoops to get past the warnings. But seemingly once you do that things work more or less normally.

What was (is) insidious with the current behaviour WRT to downloaded files is that Chrome sometimes will popup on the screen you are on and say something, albeit with a small easily missed dialog. But sometimes it doesn't, and unless you go into the Downloads screen you won't see any problem before you try and upload an empty xlsx file into CrossMgr.

I'm hoping that the CrossMgr direct connect to RaceDB works well enough that we can switch to that. I tried an old Android phone last weekend with a Data only SIMM and that worked quite nicely in one of our more cellular challenged venues. Hope to have a second one for this weekend.

— Reply to this email directly, view it on GitHub https://github.com/esitarski/RaceDB/issues/66#issuecomment-2007784332,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABGXKLFKGP24HCLM4RJ2PTYZB2PDAVCNFSM6AAAAABE2Q62Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBXG44DIMZTGI>

. You are receiving this because you commented.Message ID: @.***>

--

Edward Sitarski

— Reply to this email directly, view it on GitHub https://github.com/esitarski/RaceDB/issues/66#issuecomment-2007878904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACIUWJRALRWKQW6XUIF2WTYZCAYXAVCNFSM6AAAAABE2Q62Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBXHA3TQOJQGQ . You are receiving this because you authored the thread.Message ID: @.***>

-- __O____ -\<,____ ____()/()___


@.***>__604-518-1749(m)604-461-7532(h)

stuartlynne commented 6 months ago

Revisiting this, seeing how hard it would be to use a LetsEncrypt cert in (for example) Apache and have that act as a proxy to racedb.

I have been able to use certbot to manually get a LE cert, create a virtual host in Apache for the localized domain (racedb.ip.wimsey.co, which points at 192.168.40.16) and have that redirect to whiskey.wg:8080 which is the same IP, and RaceDB is running in a container with 8080:8000.

I can successfully get to RaceDB, and see the Hub, and get to the login, all with Chrome happy that the connection is "secure".

But when I try and login I run into Django issues with Cross Site Request Forgery protection. I'm not sure if this is an Apache virtualhost proxy configuration issue or django application configuration issue.

Apache is just a quick test (as I have done this before with Apache). But I think the goal is to use Traefik. It should do the proxying and will manage to get LE certs. As long as your RaceDB host is connected to the Internet periodically Traefik should just keep the cert current.

At least that is what I have been told by someone who uses it extensively to support home lab configurations (i.e. servers and vms behind double NAT that have never seen anything close to the public net).

Forbidden (403) CSRF verification failed. Request aborted.

Help Reason given for failure:

Origin checking failed - https://whiskey.ip.wimsey.co does not match any trusted origins.

In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django’s CSRF mechanism has not been used correctly. For POST forms, you need to ensure:

Your browser is accepting cookies. The view function passes a request to the template’s render method. In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL. If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data. The form has a valid CSRF token. After logging in in another browser tab or hitting the back button after a login, you may need to reload the page with the form, because the token is rotated after a login. You’re seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.

You can customize this page using the CSRF_FAILURE_VIEW setting.

stuartlynne commented 5 months ago

The suggested solution for the CSRF issue is to add CSRF_TRUSTED_ORIGINS to the settings.py file:

https://forum.djangoproject.com/t/csrf-verification-failed-request-aborted-after-putting-behind-ssl-proxy/29130/6

CSRF_TRUSTED_ORIGINS = ["https://my.site.com", "http://my.site.com"]

This seems to solve the issue in my tests. I added it to the docker container /RaceDB/RaceDB/settings.py

I'm open to suggestion on what would be an elegant way to get that done in the Docker setup. I.e. have the domain list set docker.env and added to /RaceDB/RaceDB/settings.

stuartlynne commented 5 months ago

I also have traefik running to act as an https reverse proxy. The learning curve is fairly steep.

I'm hoping that we can have a simple racedb_traefik image that will work with minimal configuration.

Effectively the only thing configuration required is:

  1. domain name, e.g. racedb.wimsey.dev (which also has to get into RaceDB settings.py)
  2. DNS API credentials.

The DNS credentials are a small hurdle. My (now old) DNS registrar was Hover and they do not support lets-encrypt with an API. Trying out namecheap.com. They are fairly inexpensive, but to prevent (reduce??) abuse they require a $50 balance in your account to unlock the DNS API key.

Once you have DNS API credentials traefik handles the initial request and then after 30 days will attempt to renew.

Assuming that you have RaceDB installed on a laptop that you take to events etc, then you would need to keep it plugged in and turned on at home, at least for a day or two every month between events.

esitarski commented 2 months ago

There appears to be a backdoor in some browsers (see here). Apparently, in Chrome, if you click on the unsafe page error message, then type "thisisunsafe", Chrome will disable the security check for the page. As discussed above, https security with LetsEncrypt is designed for web pages, not local web sites.

stuartlynne commented 2 months ago

I have a set of three containers that can be built from this project: https://github.com/stuartlynne/racedb_qlmux

This keeps Chrome happy allowing https://racedb.wimsey.online/RaceDB etc from Intranet devices (e.g. all the Chromebooks being used by registration.)

Traefik does require that you have a supported DNS provider that allows API access and that you have an access key.

I use namecheap.com which will give you API access if you have over 20(?) domains registered OR $50US credit in your account. wimsey.online cost $2/year.

On Fri, Sep 6, 2024 at 7:38 AM Edward Sitarski @.***> wrote:

There appears to be a backdoor in some browsers (see here https://cybercafe.dev/thisisunsafe-bypassing-chrome-security-warnings/). Apparently, in Chrome, if you click on the unsafe page error message, then type "thisisunsafe", Chrome will disable the security check for the page. As discussed above, https security with LetsEncrypt is designed for web pages, not local web sites.

— Reply to this email directly, view it on GitHub https://github.com/esitarski/RaceDB/issues/66#issuecomment-2334208643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACIUWPGAFJPQSPCCENM2CTZVG46BAVCNFSM6AAAAABE2Q62Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZUGIYDQNRUGM . You are receiving this because you authored the thread.Message ID: @.***>

-- __O____ -\<,____ ____()/()___


@.***>__604-518-1749(m)604-461-7532(h)