Is it possible to allow a backdoor IP in the form of a subdomain? I.e. backdoor.domain.nl instead of something like 192.168.1.x?

[jflamy-dev]

Is it possible to allow a backdoor IP in the form of a subdomain? I.e. backdoor.domain.nl instead of something like 192.168.1.x?

Originally posted by @JDFS404 in #490 (comment)

[jflamy-dev]

Short answer is no, because what I get from HTTP headers is an IP address, and then a reverse lookup would need to be done and matched against the returned names. Given the sensitive nature of the backdoor address, I would rather keep it to a specific address (the public address of your internet access router). I would rather look at some form of challenge instead.

[JDFS404]

Thanks, like how fast you pick up on (potentially) solving these small 'hindrances'. So this is potentially a viable situation:

1. having the OWLCMS reverse proxied with some Firewall rules attached, maybe with my own 2FA via Authelia before the system itself;
2. In a venue, having the public address IP filled in as a backdoor (so no password needed right?)
3. To make sure nobody else except people responsible for the system have access via WiFi (and not the gym/club owner), adding a captcha or something?

In most cases, and from my experience, people in gyms/clubs/venues don't have any networking knowledge at all, so no need to worry about them but I can be very paranoid and don't like any chance of tampering with results.

[jflamy-dev]

That would work. But if it's a facility wifi in a crossfit gym, they can read the URL and some funny person will try to login. So I do recommend using a password - it only needs to be entered once per workstation. Given your correct observations, anything fancier is going to cause a mess. We have run some virtual competitions without passwords, but the information was being sent to officials only.

[jflamy]

Am not sure how that would work. Each display and technical official console at the competition site is an independent browser session. So adding a password/PIN that is entered once when opening the display should do the job. That is the current mechanism.

[jflamy-dev]

The part I don't see is how you could 2FA the reverse proxy. That's just as hard to deploy and just as confusing as adding a PIN or password on the pages.

[JDFS404]

Prob you're right and I'm overthinking. Reason for asking is that the guy that taught me how to operate OWLCMS didn't have the knowledge of running it Dockerized in multiple instances; he thought that only one instance had all the results, even of prior comps and that people with a password can tamper with the results.

Example: we're using this in our region in NL in the North, but want to let the South region also use this for their competition. Since we're competing in teams, it's beneficial to have higher numbers. So we don't want them to tamper with our numbers and them not tampering with our numbers. By running two Docker instances, reverse proxied to their own subdomain I can give them a clean and empty database to put their scores in. Will still put a password in, but I can safely give it to the official that is at the venue. And for our own instance we have another container with another password.

Long story short, I think a password is sufficient after giving it some thought and by not making it too difficult.

[jflamy-dev]

Containers being containerized is indeed nice, that's the very idea. Multi-tenancy in the same database would be evil. If people want historical data, they can export the json and feed that in whatever BI tool they want.

[jflamy-dev]

(p.s. it's late. if you have a chance, drop a mail to jf@jflamy.dev -- I always enjoy learning a bit more about the enthusiastic users, who they are, what their association/club does, etc.).