I'm using a reverse proxy in front of a web application I do not have a hand on.
To connect my user automatically, I use Basic Auth. So I pass an argument in base 64 in the url like this http://mysiteweb/monurl?User=credentialsBase64Encoded
Unfortunately, the web application behind my url proxy encodes my query string parameter. So the authentication is not good when my proxy passes it in the header.
Here is my Nginx configuration.
server {
listen 80;
root /usr/share/nginx/www;
index index.html index.htm;
server_name mydomain.com;
location /mywebapp/ {
set $basicAuth "Basic $arg_user";
proxy_pass http://localhost:3524/;
proxy_set_header Authorization $basicAuth;
}
}
How can I fix the problem without having access to the web application behind the proxy?
Thank you in advance for your answers.
Related
I'm looking for a solution to prevent hot-linking with NGINX for JWPlayer. Say I have a NGINX server configured as a reverse proxy at http://mydomain1.com, I'll get the url http://mydomain1.com/file.mp4 to put on my website hosted on another VPS at http://mydomain2.com. How do I restrict the file so it can be played on http://mydomain2.com only and nowhere else?
I tried allow & deny directives but then I realized this is a HTML5 streaming so the directives will block the stream to users.
On nginx of mydomain1.com. Make sure you have one additional block which listens to default host and deny all traffic. Then in the existing listen block we add a rule to allow only www.mydomain2.com
map $http_referer $not_allowed {
default 0;
"~www.mydomain2.com" 1;
}
server {
listen 80 default_server;
server_name _;
deny all;
}
server {
listen 80;
server_name www.mydomain1.com
location / {
if ($not_allowed)
{
return 404 "Not sure its there";
}
}
}
Because the mp4 url will be put in a HTML5 player, this means the remote address (user's machine) will always communicate directly with the reverse proxy. So that's impossible to restrict the access using other methods except nginx secure link module. With this module I'm now able to restrict the access basing on the user's ip, expiration time, url and a secret word.
So this is my context:
I have a frontend local app on port 4203.
A nginx server on port 3000 would point all requests at '/' to localhost:4203
all requests to localhost:3000/api are proxied to https://example.com/api which would also set a cookie on my browser. After acquiring the cookie, every request to a relative path like /api/resource work fine with the cookie included in the header.
The problem is that I have some absolute links on my frontend app which I would like not having to parse them. So I'll have requests to https://example.com/api/anotherResource on which I can't apply the cookie for some reason so they are failing.
Is it even possible to add the cookies on this absolute path requests ?
Or maybe a way to proxy requests at https:/example.com/api/anotherResource to first acquire the cookie on localhost.
here is my nginx config:
server {
listen 3000;
server_name localhost;
location ^ ~ /api/ {
proxy_pass https://example.com/api;
}
location / {
proxy_pass http://localhost:4203;
}
}
I need to achieve below test case using nginx:
www.example.com/api/ should redirect to ABC.com/api,
while www.example.com/api/site/login should redirect to XYZ.com/api/site/login
But in the browser, user should only see www.example.com/api.... (and not the redirected URL).
Please let me know how this can be achieved.
The usage of ABC.com is forbidden by stackoverflow rules, so in example config I use domain names ABC.example.com and XYZ.example.com:
server {
...
server_name www.example.com;
...
location /api/ {
proxy_set_header Host ABC.example.com;
proxy_pass http://ABC.example.com;
}
location /api/site/login {
proxy_set_header Host XYZ.example.com;
proxy_pass http://XYZ.example.com;
}
...
}
(replace http:// with https:// if needed)
The order of location directives is of no importance because, as the documentation states, the location with the longest matching prefix is selected.
With the proxy_set_header parameter, nginx will behave exactly in the way you need, and the user will see www.example.com/api... Otherwise, without this parameter, nginx will generate HTTP 301 redirection to ABC.example.com or XYZ.example.com.
You don't need to specify a URI in the proxy_pass parameter because, as the documentation states, if proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed.
You can specify your servers ABC.example.com and XYZ.example.com as domain names or as IP addresses. If you specify them as domain names, you need to specify the additional parameter resolver in your server config. You can use your local name server if you have one, or use something external like Google public DNS (8.8.8.8) or DNS provided for you by your ISP:
server {
...
server_name www.example.com;
resolver 8.8.8.8;
...
}
Try this:
location /api {
proxy_pass http://proxiedsite.com/api;
}
When NGINX proxies a request, it sends the request to a specified
proxied server, fetches the response, and sends it back to the client.
It is possible to proxy requests to an HTTP server (another NGINX
server or any other server) or a non-HTTP server (which can run an
application developed with a specific framework, such as PHP or
Python) using a specified protocol. Supported protocols include
FastCGI, uwsgi, SCGI, and memcached.
To pass a request to an HTTP proxied server, the proxy_pass directive
is specified inside a location.
Resource from NGINX Docs
Use case:
Using nginx as a frontend for several websites / services running on both 80 and 443 (several virtual hosts).
Having service x running on localhost that serves http:8090 and https:8099
How do I need to configure nginx so people can access using only the name, without specifying the port.
This a fairly normal setup. Configure the hosts served directly on Nginx as normal. Since they need to listen on both 80 and 443, each host entry would have this in it:
server {
listen 80;
listen 443 ssl;
}
The Nginx SSL docs has the full details.
Then proxy traffic for one server{} definition to the backend service:
server {
server_name example.com;
location / { proxy_pass http://127.0.0.1:8090; }
}
You only need one proxy connection to the backend server, either 'http' or 'https'. If the connection between the two servers is secure, you can 'http', even for connections that arrive to nginx over https. This might be appropriate if the service is on the same machine. Otherwise, all the traffic could be proxied through https if the connection between nginx and the backend server needs to be secured.
We use the following with our host:
http {
server {
server_name ~^(www\.)?(?<domain>.+)$;
listen *:80;
location / {
proxy_pass $scheme://<origin>$uri$is_args$args;
include basic-proxy-settings.conf;
}
}
server {
server_name ~^(www\.)?(?<domain>.+)$;
listen *:443 ssl;
location / {
proxy_pass $scheme://<origin>$uri$is_args$args;
include basic-proxy-settings.conf;
}
include ssl-settings.conf;
}
}
This allows our upstream proxy to talk to our origin server over HTTP when a request is made by a client for an insecure resource, and over SSL/HTTPS when a request is made for a secure one. It also allows our origin servers to be in charge of forcing redirects to secure connections, etc.
Next time, why not provide a code sample detailing what you've tried, what has worked, and what hasn't?
I need to set up nginx so that requests via SSL to port 443 are routed to Rails Application A or Application B (say a PHP app) depending on the request path. Is this even possible to configure?
Yes, it is possible and depends on how is your backend applications handled. You need to use location to match request path and route request to appropriate backend with proxy_pass, fastcgi_pass etc.
Example:
server {
listen 443;
ssl on;
location /appa/ {
proxy_pass http://appa_backend/;
}
location /appb/ {
proxy_pass http://appb_backend/;
}
}