URL-Rewriting not working

[Ajay Garg]

Got it Francis !!

server {
                listen 2001 ssl;

                ssl_certificate /etc/nginx/ssl/nginx.crt;
                ssl_certificate_key /etc/nginx/ssl/nginx.key;

                location / {
                                        auth_basic 'Restricted';
                                        auth_basic_user_file
/home/20da689b45c84f2b80bc84d651ed573f/.htpasswd;

                                        if ($remote_user =
"20da689b45c84f2b80bc84d651ed573f") {
                                                proxy_pass
https://127.0.0.1:2000;
                                        }

                }
        }



Love you !!! :P :P


Thanks and Regards,
Ajay

On Sun, Apr 9, 2017 at 6:16 PM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> Hi Francis.
>
> Thanks a ton for your suggestions.
>
> On Sun, Apr 9, 2017 at 5:58 PM, Francis Daly <francis at daoine.org> wrote:
>
>> On Sun, Apr 09, 2017 at 05:27:31PM +0530, Ajay Garg wrote:
>>
>> Hi there,
>>
>> > Unfortunately, our backen-service(s) (on port 2000 in the example) is
>> > ssh-reverse-tunnel, having two layers of machines behind them. The
>> > terminating-node for sure cannot be changed.
>>
>> "In general", reverse-proxying to a different part of the url hierarchy
>> needs back-end support. In the specific case of your system, maybe it
>> does not need anything special. Only you can tell.
>>
>> > Looking at your explanations, I guess then we will have to open a port
>> for
>> > every service.
>> > So, for example, port 2001 for proxying to service running on
>> ssh-tunnel at
>> > 2000,
>>
>> You could.
>>
>> Or, you could have nginx listening on public:2000 and proxy_pass'ing
>> to local:2000, so you don't have to remember the public/private port
>> mappings.
>>
>> Or you could have nginx listening on one port, and have multiple server{}
>> blocks, so that userA connects to A.example.com which proxy_pass'es
>> to local:2000; and userB connects to B.example.com which proxy_pass'es
>> to local:2002.
>>
>
> I doubt I would be allowed to do this, since we would be using a fixed IP
> (instead of the costly multiple DNS-addresses).
>
>
>
>>
>> Or, you could (potentially) have nginx listening on one port, with one
>> server{} block, where anyone who authenticates as userA is proxy_pass'ed
>> to local:2000 and anyone who authenticates as userB is proxy_pass'ed
>> to local:2002.
>>
>
> I would be very much interested if this case is possible.
> Kindly let know how to do the proxy-routing based upon credentials.
>
> This will really solve our last core issue (opening multiple ports), while
> preserving all the feature-sets.
>
> So, will be grateful to hear back from you on how to implement this :)
>
>
> Once again, thanks a ton for the speedy, detailed responses !!
>
>
> Thanks and Regards,
> Ajay
>
>
>>
>> In each of those cases, the reverse-proxying is not to a different part
>> of the url hierarchy, so the original concern does not apply.
>>
>> Each case has its own costs and benefits, regarding future maintenance
>> within nginx and external to nginx. All can work. Only you can decide
>> which suits you best.
>>
>> > That brings me to my last question as per
>> > http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html. If
>> there
>> > isn't an issue with opening multiple nginx-listening-ports to the
>> public,
>> > then I guess we are done.
>>
>> Until you exhaust resources on your system, nginx does not care how many
>> listening ports it opens.
>>
>> Good luck with it,
>>
>>         f
>> --
>> Francis Daly        francis at daoine.org
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170409/1c9604a7/attachment-0001.html>