AWS, Django, Apache, ALLOWED_HOSTS not working 400 Bad Request - django

I have two Django applications working on the AWS Lightsail. First one is working great with www.firstapp.com and firstapp.com, but when I try to visit the second app without www in URL, it returns 400 Bad Request. In both apps, DEBUG set to False, and I have necessary hosts in settings.py like this:
ALLOWED_HOSTS = [
'.secondapp.com'
]
I have tried with '*' and also tried to write down all possible hosts in ALLOWED_HOSTS but it didn't work. I am able to see website with www.secondapp.com but secondapp.com always return Bad Request (400)
After any update in settings.py, I always restart Apache (tried to reload also) nothing changes, still getting 400 Bad Request. Any ideas? Maybe I should set up AWS in some way, this is my first experience with Django

For anyone who will face this kind of issues, check your VirtualHost configurations. In my VirtualHost configurations I had ServerName as www.secondapp.com when I add ServerAlias secondapp.com it works. Now I am able to see my app with www.secondapp.com and secondapp.com.
P.S.: However I don't have ServerAlias for first application but it still working as www.firstapp.com and firstapp.com, not sure why this casing an issue for the second one.

Related

Django Invalid HTTP_HOST header: '<ip>'. You may need to add '<ip>' to ALLOWED_HOSTS

<ip> is showing an actual ip address, I just didn't include it in the title.
I believe this ip address is the internal ip of my EC2 instance. I'm using AWS Elastic beanstalk to host.
I see this question has been answered a lot on SO, and the answer is always to add the ip address to the ALLOWED_HOSTS, but in my case I've set ALLOWED_HOSTS=['*'] and I'm still getting the error.
The weird thing is, I'm only getting the error when I try to access the site from my phone. When I access from the desktop browser, it works fine...
Things I've tried:
I've double checked my elastic beanstalk deployment and the changes are definitely deployed.
Ok so this probably won't be the answer for other people but it was for me..
In my case, I was doing an http GET request from my frontend and forgot the extra "/" at the end of the url. My django urls.py defines the url with a slash at the end. My fix was to add the extra "/" when doing the http GET.
On my desktop, this was automatically handled because django would reply with an automatic redirect (302) and my desktop browser would go to the url with / at the end, but my phone was not doing the redirect!
This somehow was throwing the invalid HTTP_HOST header error.
For most people, the fix for an error message like this is to add all of your domains to the list of ALLOWED_HOSTS.
Oh and if you're using elasticbeanstalk like me, don't forget to add the AWS domain name. It should look something like this:
ALLOWED_HOSTS = ['<your-unique-id>.elasticbeanstalk.com',
'example.com', '<your-subdomain>.example.com']
DON'T do ALLOWED_HOSTS = ['*'] in prod!!

Invalid HOST Header from router IP

I keep getting an Invalid HOST Header error which I am trying to find the cause of. It reads as such:
Report at /GponForm/diag_Form
Invalid HTTP_HOST header: '192.168.0.1:443'. You may need to add '192.168.0.1' to ALLOWED_HOSTS
I do not know what /GponForm/diag_Form is but from the looks of it, it may be a vulnerability attacked by malware.
I also am wondering why the IP is from a router 192.168.0.1 as well as why it is coming through SSL :443
Should I consider putting a HoneyPot and blocking this IP address? Before I do, why does the IP look like a local router?
The full Request URL in the report looks like this:
Request URL: https://192.168.0.1:443/GponForm/diag_Form?style/
I am getting this error at least ~10x/day now so I would like to stop it.
Yes, this surely represents a vulnerability - someone tried to access this url on router (which usually have ip 192.168.0.1).
It looks so because request from attacker contains HOST header with this value.
Maybe django is run locally with DEBUG=True.
You may consider running it more production wised with web-server (i.e. nginx) in front filtering unwanted requests with nginx config and further adding fail2ban to parse nginx error logs and ban ip.
Or make site available only from specific ips / ads simple authorization, i.e. Basic Auth on web-server level.
Previous irrelevant answer
ALLOWED_HOSTS option specifies domains django project can serve.
In running locally - python manage.py runserver or with DEBUG=True - it defaults to localhost, 127.0.0.1 and similar.
If you are accessing django via different url - it will complain in such a manner.
To allow access from another domains - add them to ALLOWED_HOSTS: ALLOWED_HOSTS = ['localhost', '127.0.0.1', '[::1]', '192.168.0.1'].

How to set ALLOWED_HOSTS Django setting in production when using Docker?

I always set my ALLOWED_HOSTS from an environment variable in Django. In my development .env I always set ALLOWED_HOSTS=.localhost,.127.0.0.1 and in production ALLOWED_HOSTS=mydomain.dom,my_ip_address
Now I am currently getting acquainted with Docker, and the question is what is the value of the ALLOWED_HOSTS in production. Should it remain as localhost, since I understand localhost will refer to the host container or should I set it as my domain. I am using Nginx for reverse proxy to forward requests.
You should set it to your domain. ALLOWED_HOSTS is used to determine whether the request originated from the correct domain name.
If you look at the docs for ALLOWED_HOSTS, you'll see that it is compared to the request's Host header, which is set by the User agent of the person visiting your site.
So although the Docker container is serving to it's own localhost, the request is originating from example.com
Check out this part of the docs to see exactly why host header validation is necessary, and you will probably better understand the purpose of ALLOWED_HOSTS
You can just use your regular domain/IP address. ALLOWED_HOSTS has to do with the headers of the user matching the IP of the server. The internal mechanics on the server are not the concern of it.
ALLOWED_HOSTS=mydomain.dom,my_ip_address
Is what you should go with.
Thanks for the answers and I did confirm its true. I would like to add that I also remembered that this can be confirmed by adding your domain to /etc/hosts pointing to 127.0.0.1. If the domain is not included in /etc/hosts, Django will throw a debug error telling you that the domain is not added to ALLOWED_HOSTS

Django error when entering from multiple domains

I'm by setting two domains that point to the same IP of Django, but I can just logging in to one, on the other just will not let me, from the admin or web always redirects me to the logging box, tried everything but nothing.
In test environment I have django running on runserer and the / etc / hosts as follows:
# This if it works
127.0.0.1 talleres.host1.com
# This one does not work
127.0.0.1 talleres.host2.com
I think the problem is with django but not to start looking, anyone know about this?
Make sure your ALLOWED_HOSTS looks like this:
ALLOWED_HOSTS = ['.host1.com',
'.host2.com',]

Django forms redirecting to internal IP on Amazon AWS

I have two sites that share the same problem, they are both hosted on Amazon EC2.
The machines are Debian 6.0, with an nginx server in front serving media, and proxying to apache+mod_wsgi to serve django.
Normal navigation on the site works fine, but whenever I click on a link without a trailing slash, or I submit a form, instead of redirecting me to www.domain.com/path/to/page/ I will be shown ip-11-111-11-111/path/to/page/, with ip-11-111-11-111 being my AWS internal IP address. The forms/links are working as the python code is executed, but when the templates are called, the url is 'built' wrong. Setting APPEND_SLASH = True doesn't fix it, and the same behaviour happens with the admin site, so I suspect it is some general issue rather than a bug in my code.
Has anybody encountered this problem? Any suggestions on how to solve it?
I've been googling this for weeks now and still can't figure it out, any ideas on where I should be looking would be appreciated as well.
In case anybody else has the same problem, the issue was apache redirecting non-www sites to the address it was listening on, which was the internal ip. I fixed it by forcing www. in nginx so that apache will never need to redirect.