I am currently deploying a django project using channel 2.x with uwgsi for http requests and daphne for background tasks.
Daphne by itself is running correctly as well as uwgsi.
Configuration for both is the following:
location /stream {
# daphne server running on port 8001 so we set a proxy to that url
proxy_pass http://0.0.0.0:8001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_redirect off;
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_set_header X-Forwarded-Host $server_name;
}
# These requests are handled by uwsgi
location / {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/app/project/socket;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# Make the following two variables accessible to the application:
uwsgi_param SSL_CLIENT_VERIFY $ssl_client_verify;
uwsgi_param SSL_CLIENT_RAW_CERT $ssl_client_raw_cert;
}
All background workers are preceded by /stream. All endpoints are protected. When login in and accessing endpoints such as /api/v1/resource it correctly returns the data but when triggering tasks via /stream I get permission denied (403). Debugging this behavior I have come to the conclusion that sessions are not persisted among Daphne and Uwsgi.
How can I achieve sessions to be shared between them?
Related
I'm having trouble exposing Zipkin UI (running in a container) behind Nginx.
I have a spring microservices that I have deployed on an ec2 instance on AWS, and I used Nginx as a load balancer to map locations to upstream using proxy_pass, and I've configured a location mapped to Zipkin upstream just like this:
location /tracing/ {
return 302 /tracing/;
}
location /tracing {
proxy_pass http://localhost:9411/;
}
but when I enter this location in the browser it redirects me to another location / which is binded to another upstream
location / {
proxy_pass http://localhost:4200/;
}
I think this may help you
location /zipkin {
proxy_pass http://localhost:9411;
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_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
}
I want to deploy django as backend server with nginx.
I use daphne as asgi server due to django channel
location /api {
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_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:10131;
}
as you can see, http://127.0.0.1:10131 is django which should be connected to http://my_domain.com/api
but django can't recognize requested uri.
surely, I set FORCE_SCRIPT_NAME to /api
What should I do further?
please help.
First check whether your daphne service is running on server or not & then try this
server {
listen 80; # can change to 10131
server_name http://my_domain.com;
location /api {
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_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:10131;
}
}
You can change listen port if you want your api accessible to specific port eg. 10131
If you're facing any issues then try to check your daphne logs like this
sudo journalctl -u daphne
and to check your api is running or not run this command
curl http://127.0.0.1:10131/api
you may need to install curl run this to install it
sudo apt install curl
I want to get public IP address of clients but I just get 127.0.0.1 almost always.
I tested some solution, but no right answer found with my configuration (Django, Nginx and Gunicorn)
Here is my Nginx proxy config.
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
First, you should make nginx pass the client's remote address to the upstream server (gunicorn):
server {
location / {
proxy_pass http://proxy_addr;
proxy_set_header X-Real-IP $remote_addr;
}
}
Then you can access the remote addr in the django request's META like this:
ip_address = request.META["HTTP_X_REAL_IP"]
Note that you can use also dict.get to avoid a KeyError while running runserver:
ip_address = request.META.get("HTTP_X_REAL_IP")
We are using the web console of https://aws.amazon.com/amazon-mq/ behind a reverse proxy.
Most of the basic functionality is working, however almost every active action (send message to queue, purge queue, ...) in the web panel ends up on the amazon internal url (https://b-asdfsad-fsdfasdf-asdfasdf.mq.eu-central-1.amazonaws.com), therefore evading the reverse proxy and ending up in an error since we prevent direct access to it for security reasons.
Any idea how to tell the web console, using the available AmazonMQ Configuration options, to prevent redirecting to anything but the URL under which the reverse proxy is reachable?
Update using Nginx Reverse with this config:
set $proxy_pass_url https://abc-def-xyz-1.mq.eu-central-1.amazonaws.com:8162;
location / {
proxy_pass $proxy_pass_url;
proxy_http_version 1.1;
proxy_set_header Authorization "Basic AUTHSTRING";
proxy_set_header X-Forwarded-User $remote_user;
proxy_set_header Host abc-def-xyz-1.mq.eu-central-1.amazonaws.com;
proxy_set_header Connection "Keep-Alive";
proxy_set_header Proxy-Connection "Keep-Alive";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
}
The Host Header isset already, but Active MQs Dashboard Jetty Config needs to know the Host anyway and its maybe not possible to do this in the Configurations AWS Provides atm.
[...]
set $proxy_pass_url https://abc-def-xyz-1.mq.eu-central-1.amazonaws.com:8162;
location / {
proxy_pass $proxy_pass_url;
proxy_http_version 1.1;
proxy_set_header Authorization "Basic AUTHSTRING";
proxy_set_header X-Forwarded-User $remote_user;
proxy_set_header Host abc-def-xyz-1.mq.eu-central-1.amazonaws.com:8162;
proxy_set_header Connection "Keep-Alive";
proxy_set_header Proxy-Connection "Keep-Alive";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
}
[...]
TLDR: How to share cookies between subdomains for a backend application sever that I cannot "configure" using nginx (1.8.x) as a proxy - some magical combination of proxy_*?
A tornado web server is running on "127.0.0.1:9999/ipython" that I cannot configure (it's running as part of an ipython notebook server). I'm using nginx to proxy from "www.mysite.com" to 127.0.0.1:9999 successfully (http traffic at least).
However, part of the backend application requires Websockets. Because I am using CloudFlare, I have to use a separate domain for Websockets ("Websockets are currently only available for Enterprise customers ... All other customers ... should create a subdomain for Websockets in their CloudFlare DNS and disable the CloudFlare proxy"). I'm using "ws.mysite.com".
When a user logs in at "https :// www.mysite.com", a cookie is set by the tornado web server for "www.mysite.com" (I can't seem to configure it, otherwise I would just set it to ".mysite.com"). When the websocket part of the application kicks in, it sends a request to "wss :// ws.mysite.com", but fails to authenticate because the cookie is set for a different domain("www.mysite.com").
Is it possible for nginx to "spoof" the domain so the tornado webserver registers it for ".mysite.com"? proxy_cookie_domain doesn't seem to work as I'd expect... Should I hard code "proxy_set_header Host"?
I was thinking a nginx conf similar to....
upstream ipython_server {
server 127.0.0.1:8888;
}
server {
listen 443;
server_name www.mysite.com;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
ssl on;
# **** THIS DOESN'T WORK ??? ****
proxy_cookie_domain www.mysite.com .mysite.com;
location /ipython/static {
proxy_pass https://ipython_server$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /ipython/api/sessions {
proxy_pass https://ipython_server$request_uri;
proxy_set_header Host $host;
proxy_set_header Origin "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /ipython {
proxy_pass https://ipython_server$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location / {
try_files $uri $uri/ =404;
}
}
server {
listen 443;
server_name ws.azampagl.com;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
ssl on;
# **** THIS DOESN'T WORK ??? ****
proxy_cookie_domain ws.mysite.com .mysite.com;
# This is the websocket location
location /ipython/api/kernels/ {
proxy_pass https://ipython_server$request_uri;
proxy_redirect off;
proxy_http_version 1.1;
chunked_transfer_encoding off;
proxy_buffering off;
proxy_read_timeout 86400;
proxy_set_header Host $host;
proxy_set_header Origin "";
proxy_set_header Upgrade websocket;
proxy_set_header Connection "upgrade";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
I've been looking in the nginx lua module? It looks like you can set cookie domains, but it looks hackish...
Thanks greatly in advance for your assistance!
(Side note: I do technically have access to the tornado configuration, but there is zero documentation on how to set the "cookie domain" for the server. i.e.
c.NotebookApp.tornado_settings = {'cookie_domain????':'.mysite.com'}
)