You could use a map to match proxy_pass URI to user names, and then use a
single password file for the auth_basic module.
​This removes the need of having specific location URI for each user,
although you could still keep doing it if they are part of your
requirements.
---
*B. R.*

On Fri, Apr 7, 2017 at 5:41 PM, Ajay Garg <ajaygargnsit@gmail.com> wrote:

> 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@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
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx