URL-Rewriting not working

[Ajay Garg]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170409/58a12d95/attachment.html>