I have a NGINX in front of Apache which has both Basic and Digest authentication turned on. I'd like a set up where a user connects to NGINX (using Basic or Digest) and NGINX simply proxy the request to the Apache where the actual authentication happens. I have the Basic case working but not the Digest. Here's how the config for Basic looks like:
location /basic {
proxy_set_header x-user $http_x_user;
proxy_pass http://my.apache.server; // where authentication happens
proxy_set_header X-Original-URI $request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
Could somebody help me out on how to accomplish the Digest case?
Here's a sample from a config that worked for me:
location /basic { # let nginx handle basic auth
auth_basic "Basic Authentication";
auth_basic_user_file conf/htpasswd;
}
location /digest { # pass digest auth to another server
proxy_pass http://my.apache.server;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Related
I'm trying to setup a reverse proxy to a sentry relay using Nginx. Config file as follows:
events {
worker_connections 768;
}
http {
server {
listen 0.0.0.0:80;
location /sentry-relay {
proxy_pass http://127.0.0.1:3001;
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;
}
}
}
Browsing directly to the relay server on port 3001 works fine:
However using the location path set in Nginx fails:
I've also put the redirect onto the default path: location / and it works fine. Why won't this custom path redirect properly?
I worked it out.
Nginx will append the location prefix to the proxy server request unless this prefix is replaced.
Thus to fix I changed:
proxy_pass http://127.0.0.1:3001;
to
proxy_pass http://127.0.0.1:3001/;
The extra slash is used to replace the sentry-relay path.
I have simple flask rest api that fetches data from database and gives result to user in json file. flask server gets parameters from html input fileds upon submit and these parameters are used to fetch data from database. It is working fine with flask inbuilt WSGI server. I wanted to deploy in production with nginx as my web server and gunicorn as application server. When I run docker container and access the root url, i can get html form for the user to input parameters. When I click on submit, another api resource call gets invoked, but I get either 'URL not found' or 'internal server error'. This surely problem with nginx location configuration for my get request api call with parameters in URL. Please help me how to configure nginx proxy_pass URL for this kind of request.
My browser request URL look something like this when I submit form.
http://IP address/api/v1/service?key=12345&name=abc&id=1234
HTML (form.html)
<form name="device" action="/api/v1/service">
Python view functions
#app.route('/')
def my_form():
return render_template('form.html')
#app.route('/api/v1/service', methods=['GET'])
def my_form_get():
..............
.............
nginx server
server {
listen 80;
location / {
proxy_pass http://localhost:5000/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /api/v1/service {
proxy_pass http://localhost:5000/api/v1/service;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Gunicorn configuration
[program:gunicorn]
command=/usr/bin/gunicorn run:app -b localhost:5000
directory=/deploy/app
You can use the following nginx configuration:
upstream v1service {
server v1servicecontainer:8080;
}
server {
listen 80;
location ~ ^/api/v1/service(.*)$ {
resolver 127.0.0.1;
proxy_pass http://v1service/api/$1$is_args$args;
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;
}
I am new to nginx.
I am having WCF Rest Service listening in the following url,
127.0.0.1:portHere/Service1.svc/RemainingRestURLTemplate.
Here is the config I am having.
http {
upstream servers_customserver {
server 127.0.0.1:62133;
server 127.0.0.1:62134;
server 127.0.0.1:62135;
}
server {
listen 8090;
server_name localhost;
location /two/ {
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;
proxy_pass http://servers_customserver;
}
}
}
Upon entering localhost:8090/two/, I thought the upstream will work,but the browser reports problem, as in the image.
But the browser works fine when I have removed the "/two/" from my location, as below.
So, how to make my upstream to work, only when the user typed the url ends with "/two/".
Could some one share some input on it.
Thx in advance.
Finally after some hrs, found that trailing slash did the work.
proxy_pass http://servers_customserver/ works instead of proxy_pass http://servers_customserver Correct me if am wrong.
Thx.
In our current architecture we have two apache front servers, in front of them, we have an nginx load balancer. And in front of that an nginx reverse proxy.
My problem is that i'm trying to run Apache Zeppelin through the reverse proxy, and i'm having some problems with the websockets.
I get an error like this : 400 HTTP method GET is not supported by this URL
And here is a screenshot of what the Chrome's Networks tab shows :
I add my reverse proxy config for Zeppelin:
error_log /var/log/nginx/nginx_error.log warn;
server {
listen 80;
server_name localhost;
location /zeppelin/ {
proxy_pass http://zeppelin:8080/;
proxy_http_version 1.1;
proxy_set_header Upgrade websocket;
proxy_set_header Connection upgrade;
}
# fallback
location / {
return 301 http://ci.blablalablab.com/app/;
}
}
Zeppelin is running inside a docker container, and i have exposes the 8080 port, its host name is : zeppelin.
If you have any questions on the architecture or so, don't hesitate to ask.
Thank you very much guys !
you can add to your reverse proxy configuration
location /ws { # For websocket support
proxy_pass http://zeppelin:8080/ws;
proxy_http_version 1.1;
proxy_set_header Upgrade websocket;
proxy_set_header Connection upgrade;
proxy_read_timeout 86400;
}
Reference: Zeppelin 0.7 auth docs
After a lot of digging around, i ended up with this configuration :
location /zeppelin/ {
proxy_pass http://zeppelin:8080/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_redirect off;
}
location /zeppelin/ws {
proxy_pass http://zeppelin:8080/ws;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
This is working pretty good, thank you everyone for your efforts ;)
I'm trying to expose a neo4j database to the internet.
For security reasons, I'd like to hide it behind a SSL/basic_auth combination via nginx. Here is the corresponding nginx config:
location /neo4j/ {
proxy_pass https://localhost:7473/;
proxy_read_timeout 600;
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 https;
proxy_set_header Host $http_host;
proxy_buffering off;
proxy_redirect off;
auth_basic "restricted";
auth_basic_user_file /etc/nginx/auth/htpasswd;
proxy_headers_hash_max_size 1024;
proxy_headers_hash_bucket_size 128;
proxy_ssl_session_reuse off;
rewrite /neo4j/(.*) /$1 break;
}
While I'm able to access https://example.com/neo4j/browser, the webinterface tells me, that it can't connect to the neo4j and my webbrowser's console gets filled up with OPTIONS https://example.com/db/data 405(Not allowed)
I also tried the neo4j built in https server in conjunction with the authentication extension (https://github.com/neo4j-contrib/authentication-extension).
With this option, I also can access the webinterface.
But the interface also displays, that it's not able to connect to the neo4j and the webbrowser's console gets filled up with OPTIONS http://example.com:7473/db/data/ net::ERR_EMPTY_RESPONSE and the hint The page at 'https://example.com:7473/browser/' was loaded over HTTPS, but displayed insecure content from 'http://example.com:7473/db/data/': this content should also be loaded over HTTPS.
Does anyone know, how to get it working? Many thanks in advance!
I came across the same problem and it's kind of weird the lack of info about Nginx as a webserver combined with neo4j. It's odd the only reference to a reverse proxy in the official doc is Apache - not impressed.
Just FYI I'm using a dockerised neo4j (https://github.com/neo4j/docker-neo4j/tree/master/2.3.2) as it comes by default (in case you want to know other settings). It should not matter if you run neo4j natively outside docker. The following Nginx conf will be the same.
location /neo4j/ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_buffering off;
proxy_pass http://YOUR-IP:7474/browser/;
}
location /db/data/ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_buffering off;
proxy_pass http://YOUR-IP:7474/db/data/;
}
Replace YOUR-IP by yours and change 7474 for 7473 if you are using HTTPS instead of HTTP.
This worked for me.
The OPTIONS request is needed to verify the connection to the Neo4j server. I think of it as a heartbeat to verify the connection. It seems that Nginx does not support OPTIONS requests, but the request can be intercepted with something like this:
location / {
if ($request_method = OPTIONS ) {
add_header Access-Control-Allow-Origin "https://example.com";
add_header Access-Control-Allow-Methods "GET, OPTIONS";
add_header Access-Control-Allow-Headers "Authorization";
add_header Access-Control-Allow-Credentials "true";
add_header Content-Length 0;
add_header Content-Type text/plain;
return 200;
}
}
Source: http://blog.rogeriopvl.com/archives/nginx-and-the-http-options-method/