Closed immanuelfodor closed 7 months ago
The 400 errors aren't CSRF errors, CSRF errors generate a 403 Forbidden page.
Set Debug to True
and it'll provide you with more context than just "Bad Request".
I'm running the latest version of the image and it works just fine:
Thank you for the quick reply!
Indeed, the debug mode complains of something else, the ALLOWED_HOSTS seem to be not recognized with an asterisk:
DisallowedHost at /
Invalid HTTP_HOST header: 'example.com'. You may need to add 'example.com' to ALLOWED_HOSTS.
This is strange, because the ALLOWED_HOSTS: "['*']"
has worked fine so far.
I'd check the specifics of what's allowed but the django website appears to be broken.
Try just *
without the brackets or quotes. I suspect this is something about the format expected for the env vs what we were doing before and writing to the local_settings file - for most stuff it's identical but for a few it's not.
Well, it looks like the readme now says -e ALLOWED_HOSTS= A comma-separated list of valid hostnames for the server. Default is: *.
Adding it as ALLOWED_HOSTS: "example.com"
(as a string, not as an array) solves the problem.
Also, adding *
as a string is also fine. So there was probably a change somewhere in the meantime from array to string.
However, there is now an SMTP error logged. Maybe there was also a change how to define no user/pass on the SMTP config? This is with the latest 3.2.20240209
build:
This is an output from the email integration test:
[pid: 192|app: 0|req: 7/7] 10.42.1.219 () {68 vars in 1376 bytes} [Fri Feb 9 18:20:06 2024] POST /integrations/2f79456a-22eb-4994-98e8-83731299dcd3/test/ => generated 0 bytes in 1972 msecs (HTTP/1.1 302) 9 headers in 473 bytes (1 swit
ches on core 0)
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.11/threading.py", line 1045, in _bootstrap_inner
self.run()
File "/app/healthchecks/hc/lib/emails.py", line 26, in run
self.message.send()
File "/lsiopy/lib/python3.11/site-packages/django/core/mail/message.py", line 300, in send
return self.get_connection(fail_silently).send_messages([self])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/lsiopy/lib/python3.11/site-packages/django/core/mail/backends/smtp.py", line 128, in send_messages
new_conn_created = self.open()
^^^^^^^^^^^
File "/lsiopy/lib/python3.11/site-packages/django/core/mail/backends/smtp.py", line 95, in open
self.connection.login(self.username, self.password)
File "/usr/lib/python3.11/smtplib.py", line 716, in login
raise SMTPNotSupportedError(
smtplib.SMTPNotSupportedError: SMTP AUTH extension not supported by server.
These are the email related envs which also worked fine so far. The SMTP server is on the same VLAN and doesn't need auth nor SSL/TLS:
EMAIL_HOST: "example.com"
EMAIL_PORT: "25"
EMAIL_HOST_USER: "False"
EMAIL_HOST_PASSWORD: "False"
EMAIL_USE_TLS: "False"
EMAIL_USE_SSL: "False"
Yes, it seems there was also a change. Now empty string is required for no auth for SMTP, so this works now:
EMAIL_HOST_USER: ""
EMAIL_HOST_PASSWORD: ""
I recommend adding "empty string for no auth" to the readme if you think it can be useful for others.
Thank you for the help! Now everything is back to normal.
Is there an existing issue for this?
Current Behavior
Bad Request (400) is displayed instead of the site, pings URLs also don't work.
The last Docker image that reliably works fine as expected:
lscr.io/linuxserver/healthchecks:3.1.20240122
. All other following images seem to be broken.There were 2 notable changes recently that might cause the issue with all the previous Docker images since
3.1.20240122
:Expected Behavior
The site is displayed fine as usual.
Steps To Reproduce
CSRF_TRUSTED_ORIGINS
set up in env values3.1.20240122
It doesn't matter if the
CSRF_TRUSTED_ORIGINS
env is not defined (should take up the value ofSITE_ROOT
automatically), or defined as a list (['https://example.com']
), or as a string with the site root ('https://example.com'
), or as an asterisk ('*'
or['*']
), the site never works. The/config/local_settings.py
is also empty.The only way to solve it is to remove the origins env, and use the
3.1.20240122
image as it still works fine.Environment
CPU architecture
x86-64
Docker creation
Envs used (can't disclose the confidental values)
Container logs