I want to configure my nginx proxy server to only allow certain IPs to access it.
To my knowledge, this is normally done in the config file, with allow and deny lists, but I need a different option if possible, since my whitelist is very big. I also need to link this to a website, so that when a user is logged in, the user will be able to update the user's IP if it has changed.
In short, a whitelisted user will be able to use my proxy server, but if for any reason the user's IP changes, the user can still login to my site and update that whitelisted IP.
Where I Need Help
Is there a way for nginx to read an IP whitelist from an external source, from something like htaccess or mysql? If so, what would be the best format for that list, so that it can be easily linked to and automatically updated? I'm planning to get the site professionally built so that when users log in to their accounts, the whitelist is automatically updated. I would therefore like my whitelist to be in the optimal format for the designer to work with, to make it easier to integrate the whitelist with the user accounts.
There are two ways I know you could solve this problem.
Allow-list in separated config: Works on all common NginX installs
You can place all of the allow statements in a simple text file, per site, that contains nothing but allow statements. Include that under the client's server block. Use scripts as needed to alter the list. Finally reload (not restart) the nginx config every time you update the allow list. This might look as follows:
cat /var/www-allow/client1-allow.conf
allow 192.168.1.1;
allow 10.0.0.1;
cat /etc/nginx/sites/client1.conf
...
server {
include /var/www-allow/client1-allow.conf;
deny all;
}
echo Test NginX configuration
nginx -t
echo Reload NginX configuration (**adjust for your setup**)
service nginx reload
Use embedded Lua: Required custom compile of NginX
Recompile NginX from source with the 3rd party embedded Lua add on module. Use a lua script to actively deny unsupported IP addresses. See the second example under access_by_lua. There are a variety of ways you could use the add on. I suggest using access_by_lua_file to put the lua script in an external location.
Both of these approaches will still require some effort on your part. I don't believe a drop-in solution is already available for your specific objectives.
Maybe nginx.shared.dict (http://wiki.nginx.org/HttpLuaModule#lua_shared_dict) would help you?
Related
I came into a situation today. Please share your expertise 🙏
I have a project (my-app.com) and one of the features is to generate a status page consisting of different endpoints.
Current Workflow
User login into the system
User creates a status page for one of his sites (e.g.google) and adds different endpoints and components to be included on that page.
System generates a link for a given status page.
For Example. my-app.com/status-page/google
But the user may want to see this page in his custom domain.
For Example. status.google.com
Since this is a custom domain, we need on-demand TLS functionality. For this feature, I used Caddy and is working fine. Caddy is running on our subdomain status.myserver.com and user's custom domain status.google.com has a CNAME to our subdomain status.myserver.com
Besides on-demand TLS, I am also required to do reverse proxy as
shown below.
For Example. status.google.com ->(CNAME)-> status.myserver.com ->(REVERSE_PROXY)-> my-app.com/status-page/google
But Caddy supports only protocol, host, and port format for reverse proxy like my-app.com but my requirement is to support reverse proxy for custom page my-app.com/status-page/google. How can I achieve this? Is there a better alternative to Caddy or a workaround with Caddy?
You're right, since you can't use a path in a reverse-proxy upstream URL, you'd have to do rewrite the request to include the path first, before initiating the reverse-proxy.
Additionally, upstream addresses cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported. You may use the rewrite directive should you need this.
So you should be able to use an internal caddy rewrite to add the /status-page/google path to every request. Then you can simply use my-app.com as your Caddy reverse-proxy upstream. This could look like this:
https:// {
rewrite * /status-page/google{path}?{query}
reverse_proxy http://my-app.com
}
You can find out more about all possible Caddy reverse_proxy upstream addresses you can use here: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#upstream-addresses
However, since you probably can't hard-code the name of the status page (/status-page/google) in your Caddyfile, you could set up a script (e.g. at /status-page) which takes a look at the requested URL, looks up the domain (e.g. status.google.com) in your database, and automatically outputs the correct status-page.
I have a few apps running in a aws instance with Dokku. I'm using virtual hostname, and together with some DNS configuration of my registered domain, I have the following for one of them: mydomain.com is a CNAME record pointing to the aws instance address, and Dokku+nginx take care of redirecting to the correct app/process.
The path for all API calls is /parse, as I'm using the open source Parse Server. The final server url is mydomain.com/parse.
What I want to achieve, ideally, is the following: api.mydomain.com gets redirected to mydomain.com/parse, api.mydomain.com/someFunction to mydomain.com/parse/someFunction and so on.
When researching to see how this may be possible, I found that this can be done easily with nginx, like explained here in this answer.
I can even change manually the nginx config file, but I'm afraid that it will be overwritten in future changes. How can this ideally be achieved with nginx on Dokku?
I have a SaaS app where every user has a personal subdomain: username.domain.com. Every user has a personal blog at username.domain.com/blog.
Now I want to accept custom domains, e.g. www.mycustomblog.com would be an alias for username.domain.com/blog.
If someone browses to www.mycustomblog.com/123, the page username.domain.com/blog/123 should be served.
However, I do NOT want a redirect. The user should still see www.mycustomblog.com/123in their address bar.
How can I achieve this behaviour? I have looked into Nginx reverse proxies, DNS CNAME records... but nothing seems to suit my needs. I can access both the custom domain DNS settings and all of the server's config files.
I think what you're looking for is a rewrite. However your described logic doesn't work:
www.mycustomblog.com -> username.domain.com/blog
appears to be missing a piece of identifying information on the left side. Perhaps www.mycustomblog.com/username? After that, it's just a matter of writing out the match/map statements to change the request to match what you've got on the server.
I have a business requirement, where i should show a different URL in the address bar from the actual. Say for ex: I have hosted my site at Hum.com. But for some users, this URL should show up as CP.com at the address bar? Is it even possible?
The only way to do this is if you control both domains, hum.com and cp.com and if you configure your web server to serve the same application for cp.com and hum.com.
If above is the case (you control both domains), you can simply redirect the users to the appropriate domain using Response.Redirect.
This is easily done in Apache via NameVirtualHosts and I am sure IIS offers the same functionality.
Yes this is possible, but it's generally done at the DNS level and not within the application itself. You want the IP address of Hum.com to resolve to the same IP address as CP.com. This is how hosting sites such as Google Sites generally work.
To do this you need to own the DNS entry for your vanity domain name (i.e. CP.com) and you need to ensure that the hosting site is capable of associating requests for CP.com with the hosted website.
This can be done by redirect.
if(fUserOfCP && !HttpContext.Current.Request.RawUrl.Contains("cp.com/")){
Responce.Redirect(
HttpContext.Current.Request.RawUrl.Replace("hum.com/", "cp.com/")
, true);
}
This code is the idea, probably is better to break the RawUrl, check and reconstruct it on the redirect to avoid the existing of host on file name.
Assume that both names belong to you, and you have setup correctly the dns.
Rewrite is not possible on host name if this is your first thoughts.
HI,
I have issue in using Windows live API
Iam using asp.net, am not able to use the callback url on local
The signin link is working only if i provide live url, but i cant able to use local host.
Please help
It may help someone else also -
Please add following entry in hosts file (located at [%system drive%]\Windows\System32\drivers\etc)
127.0.0.1 www.example.com
#[Please replace example domain with your actual one]
Windows live server expects your return url to have http:// in it but chrome does not add it and IE do add it, I realized this after wasting sometime.
This should get you through testing api on your local machine.
Go and setup a dynamic dns and a name for your computer and make your tests this way.
For example you can setup on DynDns.com a name for your dynamic ip, and then setup your router with that name to automatic assign it (or do it manual from the pages), and then you can use this name, and not the localhost. Do not forget to open the port to your router so the other side can make requests.
Also on /windows/system32/drivers/etc/host you can also setup the same name to see your local host and make your tests and callbacks.
Your problem is that the callback address needs to be the same as the address you used to sign up with.
(In relation to your callback), from the documentation:
The domain name portion of the URL (for example, www.contoso.com) must
be the same as the one that you specified when you created your
application with Live Connect. The URL must use URL escape codes, such
as %20 for spaces, %3A for colons, and %2F for forward slashes.
So, based on what you have said, you are using localhost (which you can't). As #Aristos suggested, add an entry to /windows/system32/drivers/etc/host to the domain you have registered (eg www.contoso.com).
Use www.contoso.com instead of localhost to test.