I've got a flask app daemonized via supervisor. I want to proxy_pass a subfolder on the localhost to the flask app. The flask app runs correctly when run directly, however it gives 404 errors when called through the proxy. Here is the config file for nginx:
upstream apiserver {
server 127.0.0.1:5000;
}
location /api {
rewrite /api/(.*) /$1 break;
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_pass http://apiserver;
proxy_next_upstream error timeout http_502;
proxy_buffering off;
}
For instance, when I go to http://127.0.0.1:5000/me, I get a valid response from the app. However when I go to http://127.0.0.1/api/me I get a 404 from the flask app (not nginx). Also, the flask SERVER_NAME variable is set to 127.0.0.1:5000, if that's important.
I'd really appreciate any suggestions; I'm pretty stumped! If there's anything else I need to add, let me know!
I suggest not setting SERVER_NAME.
If SERVER_NAME is set, it will 404 any requests that don't match the value.
Since Flask is handling the request, you could just add a little bit of information to the 404 error to help you understand what's passing through to the application and give you some real feedback about what effect your nginx configuration changes cause.
from flask import request
#app.errorhandler(404)
def page_not_found(error):
return 'This route does not exist {}'.format(request.url), 404
So when you get a 404 page, it will helpfully tell you exactly what Flask was handling, which should help you to very quickly narrow down your problem.
I ran into the same issue. Flask should really provide more verbose errors here since the naked 404 isn't very helpful.
In my case, SERVER_NAME was set to my domain name (e.g. example.com).
nginx was forwarding requests without the server name, and as #Zoidberg notes, this caused Flask to trigger a 404.
The solution was to configure nginx to use the same server name as Flask.
In your nginx configuration file (e.g. sites_available or nginx.conf, depending on where you're defining your server):
server {
listen 80;
server_name example.com; # this should match Flask SERVER_NAME
...etc...
Related
I work on a Django project + django-rest-framework. On localhost, PATCH requests work perfectly fine. However, on server, PATCH requests do not work. I get a 400 Bad request error. I use nginx to configure the web server.
Here is my configuration:
server {
listen 80;
server_name x.y.z.com;
root /var/www/path-to/project;
location / {
error_page 404 = 404;
proxy_pass http://127.0.0.1:5555/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_intercept_errors on;
}
}
I get this error when I try PATCH requests on server :
How can I make so that django accept PATCH requests? The log does not show anything. As if it does not even receives the request. I run the django server like this:
python manage.py runserver 5555
Friend, I faced this problem, I made all the possible settings in nginx, but the problem was in my js fetch that tried with the patch method in lowercase, 'patch', changing to 'PATCH' worked normally.
I'm running a Django project on a DigitalOcean VPS using Nginx and Gunicorn. I made sure that i'm using HTTPS, but for some reason using request.is_secure() always returns False, and request.scheme returns HTTP, even though i made sure it's VPS.
What could be the reason for that? Here is my nginx config:
server {
listen 80;
server_name MY.SERVER.com;
location / {
include proxy_params;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://unix:/var/www/proj/myproj.sock;
}
}
And i also made sure to add to my Django settings SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https'). Any advice is appreciated
I ran into the same issue. And, it looks like, I found out why it doesn't work as expected.
Accordingly to the documentation, $scheme equals either http or https.
In the case of a location, which is declared in server that listens on 80 port, we get $scheme equal to http. Then, AFAIU, Django receives HTTP_X_FORWARDED_PROTO header which equals to http, and Django treats it as unsecured (i.e. request.is_secure() always returns False). Well, at least, it started to work well when I made the following change:
proxy_set_header X-Forwarded-Proto "https";
I'm writing a website with Flask. I use Flask-Secuirty to do authentication. I use nginx + gunicorn to deploy it.
The configuration of nginx as follow:
server{
listen 80;
server_name project.example.com;
location / {
proxy_pass http://127.0.0.1:5000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
}
}
And I use gunicorn -w worker_number -k gevent run:app -p app.pid -b 127.0.0.1:5000 to start gunicorn.
If the worker_number is 1, everything is ok.
If the worker_number is greater than 1 like 3, I can't login in with Flask-Security.
The output of server said the post request of login is 200. But the server redirect me to login page again.
After some search, I can't find direct reason of this. And I guess this might cause by SERVER_NAME config of Flask or the misuse of Flask-SQLAlchemy.
Is there anyone has met this situation before? Please give me some advices.
I met a similar problem with flask_login, when the worker_number is greater than 1, I could not login in.
My app.secret_key was set to os.urandom(24), so every worker will have another secret key.
Set app.secret_key to a string solved my problem.
Just use a fixed secret key.
Generate with following command.
$ openssl rand -base64 <desired_length>
If you don't want to hardcode the key inside source code which you shouldn't for security purposes.
Set up an environment variable and get it.
import os
# -- snip --
app.config["SECRET_KEY"] = os.environ.get("FLASK_APP_SECRET_KEY")
Use something like Flask-Session and use Redis as a session store. I'm not sure how Flask-Security works, but I assume it relies on Flask sessions, in which case it would solve the problem of a user session switching between application servers.
I'm using nginx as reverse proxy with gunicorn for my Django app, and am new to webserver configuration. My app has a postgres backend, and the machine hosting it has Ubuntu 14.04 lts installed.
I have reason to suspect that my nginx configuration is not forwarding proxy set header to the Django app correctly. Is there a way I can see (e.g. print?) the host, http_user_agent, remote_addr etc. forwarded, on the linux command line to test my gut feel?
Secondly, how do I check whether my Django app received the correct forwarded IP? E.g. can I somehow print?
/etc/nginx/sites-available/myproject:
server {
listen 80;
server_name example.cloudapp.net;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/mhb11/folder/myproject;
}
location / {
proxy_set_header Host $host;
proxy_set_header User-Agent $http_user_agent;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://unix:/home/mhb11/folder/myproject/myproject.sock;
}
error_page 500 502 503 504 /500.html;
location = /500.html {
root /home/mhb11/folder/myproject/templates/;
}
}
All you have to do is print out request.META at the Django project level to see what all of those values are being set to. This automatically happens for you if you get an error and debug is set to True (just scroll down, you'll see a big table with all request.META values populated therein).
Or you can print it yourself from your views.py, or if that doesn't work, then from any middleware you have. You can even write custom middleware for this. Let me know if you need further clarification on this, I can give you basic code snippets too.
This question was posted a long time ago but since I landed here when needed help, below are some code which I ended up using to attain the same goal for the help of other people.
def getClientIP(request):
x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
if x_forwarded_for:
ip = x_forwarded_for.split(',')[-1].strip()
else:
ip = request.META.get('REMOTE_ADDR')
return ip
I'm trying to load balance 2 gunicorn servers with nginx. I am required to have basic auth on the application, so I thought I would stick the auth on the nginx server.
However for some reason my Django completely fails when I enable basic auth the nginx server. Everything works perfectly after disabling basic in my nginx conf.
Here is my nginx conf.
upstream backend {
server 10.0.4.3;
server 10.0.4.4;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Real-IP $remote_addr;
add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_set_header REMOTE_USER $remote_user;
}
location /orders
{
auth_basic "off" ;
}
}
This is the error I'm getting:
Error importing module keystone_auth.backend: "No module named keystone_auth.backend"
I thought it might be some headers that I need to pass through. Is there another way to get basic auth on Django bearing in mind that it needs to be load balanced. Or is my ngnix config missing some stuff?
The keystone_auth.backend had mistakenly be included from another settings file, I was still unable to get BasicAuth working, but eventually solved the issue by writing my own Auth Back end as described here.
https://docs.djangoproject.com/en/dev/topics/auth/customizing/