WebFaction
Community site: login faq

Hello,

I'm trying to figure out a solution to set up a gated proxy server to restrict access to our staging and development servers. Ideally what I'm ultimately looking for is a way to restrict public access to an application without having to hardcode that information into the application's code.

Here's the intended architecture/requirements:

  • Request to someprototype.dev.mysite.com resolve to proxy
  • proxy acts as a gate to authenticate via ip whitelist and/or basic auth
  • if authenticated, proxies all traffic to staging/dev application
  • dev/staging application should not care/be aware of proxy, and should still think it's hostname is
  • someprototype.dev.mysite.com
  • solution should work for many different application types, such as the shared apache server, a static site, nodejs, or a custom application

(not as concerned about any performance overhead as this is not intended to be used for production applications)

My thought process here was to set up a simple static/cgi/php application and create an htaccess file to handle the authentication side of things, and probably use a combination of rewrite rules with the [p] flag to proxy the traffic appropriately. However the part that I'm struggling with is having everything forward to an application that is using the same domain name. The best solution I can come up with so far is to create two applications for the domain name here on webfaction, with the proxy using our primary ip address and the actual application using the secondary IP, then having to revert the nameservers for this domain to my registrar so that I can create manual dns entries so that it always points to the proxy IP so it can route accordingly. This adds another layer of complexity in managing our applications however, as now it requires us to separately manage our DNS. I'm completely open to other solutions if anyone can provide some assistance here.

Thank you, Scott

asked 24 Oct, 14:49

bh-scott
235
accept rate: 0%


I would suggest building nginx from source and using a custom application listening on port type app with a custom nginx proxy server.

This should provide a fast and stable server to act as proxy and also allow any configuration for authentication you might need now or in the future.

permanent link

answered 24 Oct, 21:19

johns ♦♦
5.3k212
accept rate: 23%

Thanks for the suggestion, I'll give it a try when I have a little bit more time to dig into it further and then I'll follow up.

(25 Oct, 13:18) bh-scott

Thanks, I've got this set up and mostly working, including basic auth, however am having trouble getting an ip whitelist working, as it's saying all requests are coming from 127.0.0.1 (I'm assuming due to the shared wf nginx instance). Is there any way I can get the actual ip address of the incoming request so I can filter out trusted clients?

(25 Oct, 23:44) bh-scott

Also just wanted to confirm, do I need to set up some sort of watchdog script to ensure nginx stays online? If so, what would be the best way to approach that?

(25 Oct, 23:45) bh-scott

You can specify the server IP in the nginx.conf,

listen PORT; server_name SERVERIP;

For a watchdog script, please check out

https://community.webfaction.com/questions/6157/watchdog-script-to-keep-process-running-with-cron

(26 Oct, 00:48) NickR ♦♦

Thanks NickR, I'll look into setting up the watchdog script. I think you might have misunderstood what I was asking about with the IP address.

I'm trying to use the following snippit to only allow access through the reverse proxy from users located on specific networks, or if they have a password. I'm using the following settings (where "my_username" is replaced with my webfaction username, and 1.2.3.4 is replaced with the IP I wish to whitelist):

# Basic auth
auth_basic              "Restricted Area";
auth_basic_user_file    /home/my_username/webapps/util_nginx_reverse_proxy/.htpasswd;`

# IP whitelist
satisfy any;

allow   1.2.3.4;
deny    all;

The problem is the ip that gets matched against 1.2.3.4 appears to always be 127.0.0.1 instead of the ip address of the user.

(26 Oct, 01:10) bh-scott

Okay, I think you want to make use of the proxy_set_header in your nginx.conf

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header

To implement the X-Forwarded-For header to obtain the original IP,

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

(26 Oct, 01:56) NickR ♦♦

I'm still confused by this comment. Would this not need to be on the WebFaction nginx config? From my understanding we don't have control over that.

This is a custom built version of nginx running as a custom application listening on port type as suggested by @johns above. From my understanding this configures the WebFaction nginx to act as a reverse proxy to my custom application, which is my own reverse proxy that I'm trying to configure above. By the time the request gets to my instance of nginx the client's IP has been replaced by 127.0.0.1. Does the WebFaction instance of nginx implement the X-Forwarded-For header? If so, how would I utilize this for my allow rules in my config?

(26 Oct, 02:05) bh-scott
showing 5 of 7 show 2 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×75
×30
×25

question asked: 24 Oct, 14:49

question was seen: 100 times

last updated: 26 Oct, 02:05

WEBFACTION
REACH US
SUPPORT
AFFILIATE PROGRAM
LEGAL
© COPYRIGHT 2003-2016 SWARMA LIMITED - WEBFACTION IS A SERVICE OF SWARMA LIMITED
REGISTERED IN ENGLAND AND WALES 5729350 - VAT REGISTRATION NUMBER 877397162
5TH FLOOR, THE OLD VINYL FACTORY, HAYES, UB3 1HA, UNITED KINGDOM