Login-Credentials based redirection?
Ajay Garg
ajaygargnsit at gmail.com
Fri Apr 7 15:41:56 UTC 2017
I have been searching if it is possible to do a one-to-one mapping,
something like ::
location /9000
{
auth_basic
auth_value username9000:password9000
proxy_pass http://localhost:9000
}
location /9001
{
auth_basic
auth_value username9002:password9002
proxy_pass http://localhost:9001
}
Also, ports 9000, 9001 will be firewalled from the public.
Above will ensure that someone wanting to get access to say port 9000, will
have to come via http://1.2.3.4/9000. and must know the credentials
username9000:password9000
Do I make sense?
If yes, can someone please point me out as to how to specify
username:password on the URL basis.
Thanks and Regards,
Ajay
On Fri, Apr 7, 2017 at 7:15 PM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> Hi All.
>
> We have setup multiple ssh-reverse tunnels, and our server will be
> listening to ports from 9000 to 10000.
> The server will have a public-IP, and we DO NOT want just anyone to look
> into any of the ports by trying ::
>
> http://1.2.3.4:9000
> http://1.2.3.4:9001 and so on ...
>
>
> So, we are wondering if we can do something like this ::
>
>
> 1. User types in a URL, let's say https://1.2.3.4/index.html
> 2. The user gets presented with a login/password page.
> 3. Depending upon the credentials passed, the user gets "proxied" to the
> appropriate end-url.
>
> So, a user with credentials for port 9000 will ONLY be able to see
> http://1.2.3.4:9000
> A user with credentials for port 9001 will ONLY be able to see
> http://1.2.3.4:9001, and so on ..
>
> An important point to note that the URLs http://1.2.3.4:9000,
> http://1.2.3.4:9001 must be not be directly accessible, else it defeats
> the purpose of authentication at first place.
>
> Is the above approach feasible logically and technically-via-nginx?
>
>
> Will be grateful for pointers.
>
>
> Thanks and Regards,
> Ajay
>
--
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170407/705a8054/attachment.html>
More information about the nginx
mailing list