Fix DisallowedHost error during initial setup from unknown hosts

[Copilot]

Description

Accessing NoHands from an external host (e.g., machine.local:8000) before initial setup caused a DisallowedHost error instead of showing the setup page. The middleware now gracefully handles database unavailability during host validation.

Changes:

• Added try/except around User.objects.exists() in InitialSetupMiddleware and DynamicAllowedHostsMiddleware
• Added try/except around AllowedHost.get_all_active_hosts()
• Catches specific DatabaseError and OperationalError exceptions
• When DB is unavailable, requests are allowed through (safe default for initial setup)

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Performance improvement
• Test addition/modification

How Has This Been Tested?

• Unit tests
• Integration tests
• Manual testing
• Test with real repositories

Added InitialSetupUnknownHostTest (5 tests) and DatabaseUnavailableMiddlewareTest (1 test) covering:

• Unknown external hosts during initial setup
• Various hostname formats (IPs, local domains, ports)
• Database unavailability scenarios

Test Configuration:

• Python version: 3.12
• Django version: 5.2.8
• Operating System: Linux

Checklist

• My code follows the style guidelines of this project (PEP 8, Black formatting)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Related Issues

Closes #(issue number)

Screenshots (if applicable)

N/A

Additional Notes

The existing test test_get_shows_form_when_oauth_not_configured in test_utils_views.py was already failing before these changes (unrelated template text mismatch).

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• dl.dagger.io
  • Triggering command: /usr/bin/python python manage.py test (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Still checking to see if current host is in the allowed host before the first initialization of the NoHands server</issue_title>
<issue_description>Still checking to see if current host is in the allowed host before the first initialization of the NoHands server.

Steps to reproduce:

1. On a distant machine (example, it is called machine.local), up the docker compose file that is in NoHands repository
2. Try to open the first configuration page. It should be at machine.local:8000\ adress, where obviously machine.local is the network name of the machine running the NoHands container.
3. The page that loads should say: A server error occurred. Please contact the administrator.

It is very import to me that you follow a step by step methodology.

1. Before anything else, in a TDD approach, develop new django unittests until the problem is found.
2. After the new tests are able to reproduce the problem (they should have failed with the same error), and only then, you can start debuging.
3. Debug until all tests passes. </issue_description>

Comments on the Issue (you are @copilot in this section)

@vbrunelle Here is the message that I get in the container log after trying to access the web UI for the first time.

`nohands-1 | System check identified some issues:
nohands-1 |
nohands-1 | WARNINGS:
nohands-1 | ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use: settings.ACCOUNT_LOGIN_METHODS = {'email', 'username'}
nohands-1 | ?: settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use: settings.ACCOUNT_SIGNUP_FIELDS = ['email', 'username*', 'password1*', 'password2*']
nohands-1 | Operations to perform:
nohands-1 | Apply all migrations: account, admin, auth, builds, contenttypes, projects, sessions, sites, socialaccount
nohands-1 | Running migrations:
nohands-1 | No migrations to apply.
nohands-1 | Watching for file changes with StatReloader
nohands-1 | Performing system checks...
nohands-1 |
nohands-1 | System check identified some issues:
nohands-1 |
nohands-1 | WARNINGS:
nohands-1 | ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use: settings.ACCOUNT_LOGIN_METHODS = {'username', 'email'}
nohands-1 | ?: settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use: settings.ACCOUNT_SIGNUP_FIELDS = ['email', 'username*', 'password1*', 'password2*']
nohands-1 |
nohands-1 | System check identified 2 issues (0 silenced).
nohands-1 | November 26, 2025 - 02:12:19
nohands-1 | Django version 5.2.8, using settings 'nohands_project.settings'
nohands-1 | Starting development server at http://0.0.0.0:8000/
nohands-1 | Quit the server with CONTROL-C.
nohands-1 |
nohands-1 | WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
nohands-1 | For more information on production servers see: https://docs.djangoproject.com/en/5.2/howto/deployment/
nohands-1 | Traceback (most recent call last):
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner
nohands-1 | response = get_response(request)
nohands-1 | ^^^^^^^^^^^^^^^^^^^^^
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/utils/deprecation.py", line 119, in call
nohands-1 | response = self.process_request(request)
nohands-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/middleware/common.py", line 48, in process_request
nohands-1 | host = request.get_host()
nohands-1 | ^^^^^^^^^^^^^^^^^^
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/http/request.py", line 202, in get_host
nohands-1 | raise DisallowedHost(msg)
nohands-1 | django.core.exceptions.DisallowedHost: Invalid HTTP_HOST header: 'ceos.home:8000'. You may need to add 'ceos.home' to ALLOWED_HOSTS.
nohands-1 |
nohands-1 | During handling of the above exception, another exception occurred:
nohands-1 |
nohands-1 | Traceback (most recent call last):
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner
nohands-1 | response = get_response(request)
nohands-1 | ^^^^^^^^^^^^^^^^^^^^^
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/utils/deprecation.py", line 120, in call
nohands-1 | response = response or self.get_response(request)
nohands-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 57, in inner
nohands-1 | response = response_for_exception(request, exc)
nohands-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
nohands-1 | File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 120, in respons...

Custom agent used: Fixer
Fix the bugs using the TDD approach

• Fixes Still checking to see if current host is in the allowed host before the first initialization of the NoHands server #35

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[vbrunelle]

@copilot Have you tried testing the problem by using the Docker-compose file for no hands and reproducing step by step?

[Copilot]

@copilot Have you tried testing the problem by using the Docker-compose file for no hands and reproducing step by step?

I wasn't able to build the Docker image in this sandboxed environment due to network restrictions, but I did simulate the Docker environment behavior by testing with the exact host from your issue (ceos.home:8000).

The test confirms the fix works:

Testing access from external host "ceos.home:8000" (from the issue)...
Root path response status: 302
Response URL (if redirect): /repositories/initial-setup/
Setup page response status: 200

SUCCESS: The fix works! External host ceos.home:8000 is allowed during initial setup.

The fix ensures that when no users exist (fresh install), any host is allowed through the middleware, preventing the DisallowedHost error. Once you rebuild and push the Docker image with these changes, the issue should be resolved.