Bad request - Error 400

[Braincoke]

Here is an error I encountered with its solution.

Expected Behavior

When using the docker-compose.yml file below and starting it with docker-compose up the application should work.

version: '2'
services:
  healthchecks:
    container_name: 'healthchecks'
    image: linuxserver/healthchecks:latest
    environment:
      - PUID=1000
      - PGID=1000
      - ALLOWED_HOSTS=["*"]
      - DEBUG=True
    volumes:
      - ./healthchecks_data:/config
    networks:
      host-macvlan-net:
        ipv4_address: 10.0.6.10
networks:
  host-macvlan-net:
    external:
      name: host-macvlan-net

Current Behavior

The docker seems to start properly without yielding errors but trying to access the application returns 400 errors.

GET / => generated 143 bytes in 85 msecs (HTTP/1.1 400) 2 headers in 86 bytes (1 switches on core 0)

This is usually a sign that "ALLOWED_HOSTS" is not properly configured but I did include the environment variable in the docker-compose file.

Solution

The mounted volume /config contains a file local_settings.py that seems to take precedence over the environment variables :

EMAIL_HOST = "smtp.gmail.com"
DEFAULT_FROM_EMAIL = "noreply@example.com"
BASE_URL = "healthchecks.example.com"
EMAIL_USE_TLS = True
SITE_ROOT = "https://healthchecks.example.com"
DEBUG = False
EMAIL_PORT = "587"
SITE_NAME = "healthchecks"
EMAIL_HOST_PASSWORD = "password"
EMAIL_HOST_USER = "username"
ALLOWED_HOSTS = ["healthchecks.example.com"]
CSRF_TRUSTED_ORIGINS = ["healthchecks.example.com"]

The solution is to modify the parameters directly in this file. Hope this saves some time for someone else.

[tmertz]

Getting the same with latest build of the container. Not using macvlan.

[tmertz]

I sorted it by reading the Production guide.

Still, note that there are always going to be sections of your debug output that are inappropriate for public consumption. File paths, configuration options and the like all give attackers extra information about your server.

It is also important to remember that when running with DEBUG turned on, Django will remember every SQL query it executes. This is useful when you’re debugging, but it’ll rapidly consume memory on a production server.

Finally, if DEBUG is False, you also need to properly set the ALLOWED_HOSTS setting. Failing to do so will result in all requests being returned as “Bad Request (400)”.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.