The problem is that I test the django helloworld on two virtual (ubuntu server) machine.
one's virtual ip is xxx.xxx.xxx.xxx(example 123.4.5.6),
physical ip is yyy.yyy.yyy.yyy(example 9.87.6.5),
another is xxx.xxx.xxx.xxx(example 123.4.5.7)
physical ip is yyy.yyy.yyy.yyy(example 9.87.6.4),
all these are static "virtual ip"
and static ip
The problem is,
while loading the page of the first django helloworld, everything is fine
(these two helloworld are same coded and are independent to each other),
but when I try building the second django helloworld and connect to the server it said
Page not found (404)
Request Method: GET
Request URL: http://9.87.6.4/http:/9.87.6.4/
{'path': 'http://9.87.6.4/'}
You're seeing this error because you have DEBUG = True in your Django
settings file. Change that to False, and Django will display a
standard 404 page.
and the server debugger said
Performing system checks...
System check identified no issues (0 silenced).
November 30, 2017 - 12:13:18
Django version 1.11.7, using settings 'helloworld.settings'
Starting development server at http://123.4.5.7:80/
Quit the server with CONTROL-C.
Not Found: /http:/9.87.6.4:80/
[30/Nov/2017 12:13:19] "GET http://9.87.6.4:80/ HTTP/1.1" 404 1666
Notice that there's an extra http:/9.87.6.4/
in the Request URL
I have tried reinstall the apache2
(but most likely it is not related to apache2 but to the virtual machine I think)
and it still didn't work.
my virtual machine is based on OPENSTACK.
since sometimes the django-debugger even print things like
[30/Nov/2017 12:37:58] "GET http://nova.clouds.archive.ubuntu.com/ubuntu/dists/xenial-updates/multiverse/binary-amd64/Packages HTTP/1.1" 400 61127
Invalid HTTP_HOST header: 'windowbox.me'. You may need to add 'windowbox.me' to ALLOWED_HOSTS.
or
[30/Nov/2017 12:37:58] "GET http://google.com HTTP/1.1" 400 61127
Invalid HTTP_HOST header: 'google.com'. You may need to add 'google.com' to ALLOWED_HOSTS.
when I visit the google page using the physical machine(not the virtual one) after visit the problem virtual machine,
so I am thinking maybe there's some false setup on my second virtual machine.
By the way, if I use lynx from my first virtual machine to visit the helloworld page in the problem virtual machine, EVERYTHING IS FINE. there's no http 404 and no duplicate URL
Related
I got my React/Django website running on an AWS EC2 instance using Nginx and Supervisor. I'm trying to do a proper deployment rather than just put up my development environment.
When I set DEBUG to False in Django's settings.py, the supervisor logs give me the error "CommandError: You must set settings.ALLOWED_HOSTS if DEBUG is False." However, every combination I've tried so far has given me errors. I know that Nginx is essentially sending every request I get through my IP to localhost on the server (right?) so I figured just having 'localhost' would work but that gives me 404 errors when trying to retrieve the static files. Then I tried using my domain (currently just my public DNS from AWS since I haven't connected the domain yet) and that gives me a 400 (Bad Request) error. Using both also gets me a 404. Then I tried the wildcard ('*') since I figure Nginx is handling the traffic anyway but I STILL get a 404.
TL;DR table
ALLOWED_HOSTS value Result
-----------------------------------------------------
['localhost'] 404 (Not Found)
-----------------------------------------------------
['http://....amazonaws.com/'] 400 (Bad Request)
-----------------------------------------------------
['localhost', 404 (Not Found)
'http://....amazonaws.com/']
-----------------------------------------------------
['*'] 404 (Not Found)
-----------------------------------------------------
all three 404 (Not Found)
-----------------------------------------------------
['34.xxx.xx.xx'] 400 (Bad Request)
-----------------------------------------------------
I don't know what else to try. Any direction would be greatly appreciated.
I'm trying to connect an Android device to my ObtainAuthToken endpoint from the django-rest-framework.
If I just call it with http://localhost/api-token-auth it works fine:
[21/Dec/2017 16:04:34] "POST /api-token-auth HTTP/1.1" 400 68
But if I change that to http://192.168.1.4/api-token-auth my dev server throws me a 404, like so:
[21/Dec/2017 16:05:00] "POST /api-token-auth HTTP/1.1" 404 0
I've tried adding my IP number 192.168.1.4 to ALLOWED_HOSTS but no dice. Trying to Google this issue just brings up a bunch of unrelated stuff.
Anyone knows what might be causing this?
I had a similar issue which I resolved by running the Django project on 0.0.0.0 rather than localhost.
I've been getting many of these error emails from my django site. They look like they are triggered from some automated exploit. Here is one example.
Referrer: http://example.com/fck/editor/filemanager/upload/test.html
Requested URL: /fck/editor/filemanager/upload/test.html
User agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90)
IP address: 127.0.0.1
Please help me answer 2 questions:
How can I configure Django to log the real ip origin of the exploiter, i.e., something along the lines of REMOTE_ADDR instead of the localhost ip.
Is there a way to reject requests with fake referrers to begin with? The requested and referred URLs are certainly not valid links from my own example.com site, and have never been.
Thanks
I figured out my own problem so in case anyone else need this info, here goes...
I kept getting the localhost ip in the error email because my django server lives behind a reverse proxy on the same machine. In this scenario REMOTE_ADDR is always the localhost address.
There is no template or custom error reporting mechanism to get other variables into the broken link email because the email is hardcoded in django's CommonMiddleware The custom error reports mentioned in previous comments has nothing to do with this.
So in order to get the real ip address, I wrote a middleware to replace REMOTE_ADDR with HTTP_X_FORWARDED_FOR. Supposedly there is a security issue involved since HTTP_X_FORWARDED_FOR can be easily faked but that is all that can be done without a CommonMiddleWare patch to actually include both ip variables.
Server Spec:
Wordpress 3.0.1
PHP Version 5.3.8-1+b1
MYSQL 5.1
Apache/2.3.16
Linux
The Problem
Simple really. A website that I helped to build and install a while back has just been transferred to a new host. The front end of the website isn't presenting any issues, but when I try to login to the admin area, I get a 501 'Unsupported Method ('POST') error.
I'm a bit lost, my guess would be it's a server config issue, but are there any specific wordpress issues that might be at fault?
My site is localized using a string in the URL (e.g. /DE/certificate gets the German version, /US/certificate gets en-US, etc.) For some URLs on the site, leaving out the localization part redirects to a best-guess (usually /US/<url>) but for others I just get a blank page.
This is a Django site. Django is running through mod_python on Apache, listening on port 8000. Nginx is on port 80. When a request comes in, Nginx checks memcached for the page, and if it's in the cache, serves directly from the cache. If memcached misses, Nginx proxies the request back to Apache. Django stores the output of most GET requests into memcached. Traffic is very spiky for this site, and this method helps us get the most from a relatively low-powered server.
The problem described above is not present if I skip Nginx and the cache, and send requests directly to Apache on port 8000. This leads me to suspect the problem is in the Nginx/memcached layer.
Watching Apache's log on a successful request shows a 302 being returned for the unlocalized request, and a new request for the corrected URL. Watching Nginx's log for a failed request shows a 200 response, and an apparently empty response. My hunch is that an empty page is being stored in memcached. Is there any way to investigate the keys in memcached to confirm this hunch, or should I be looking for some other information to debug the problem?
Here's the relevant section of the nginx configuration:
location / {
if ($request_method = POST) {
proxy_pass http://production;
break;
}
default_type "text/html; charset=utf-8";
set $memcached_key "/key-$uri";
memcached_pass localhost:11211;
error_page 404 502 = /django;
}
location = /django {
proxy_pass http://production;
break;
}
Would it help for me to include my Django caching middleware? I set it up following this article pretty much exactly.
use "#django" (on both lines) instead of "/django"