URL-Rewriting not working

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

URL-Rewriting not working

Ajay Garg
Hi All.

When I setup the following, the authentication+proxying works perfect, with the url changing from http://1.2.3.4:2001 to http://1.2.3.4:2001/cgi-bin/webproc, and the proxied0server opening up perfectly.

############################################################################
server {
        listen 2001;
        location / {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
#############################################################################



However, I am not able to do the proxying if I perform url-rewriting.
Nothing of the following works ::

a)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


b)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


c)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

The URL does changes from http://1.2.3.4:2001/78 to http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.


d)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I getting a 404, even though the URL-change is perfect.


Any ideas please?


Thanks and Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Anoop Alias
I think you are confusing between url-rewrite and location

On Sat, Apr 8, 2017 at 6:39 PM, Ajay Garg <[hidden email]> wrote:
Hi All.

When I setup the following, the authentication+proxying works perfect, with the url changing from http://1.2.3.4:2001 to http://1.2.3.4:2001/cgi-bin/webproc, and the proxied0server opening up perfectly.

############################################################################
server {
        listen 2001;
        location / {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
#############################################################################



However, I am not able to do the proxying if I perform url-rewriting.
Nothing of the following works ::

a)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


b)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


c)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

The URL does changes from http://1.2.3.4:2001/78 to http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.


d)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I getting a 404, even though the URL-change is perfect.


Any ideas please?


Thanks and Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Anoop P Alias 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Ajay Garg
Hi Anoop.

As per http://serverfault.com/questions/379675/nginx-reverse-proxy-url-rewrite, the rewrite should be automatic.
But it does not work for me :(

On Sat, Apr 8, 2017 at 6:49 PM, Anoop Alias <[hidden email]> wrote:
I think you are confusing between url-rewrite and location

On Sat, Apr 8, 2017 at 6:39 PM, Ajay Garg <[hidden email]> wrote:
Hi All.

When I setup the following, the authentication+proxying works perfect, with the url changing from http://1.2.3.4:2001 to http://1.2.3.4:2001/cgi-bin/webproc, and the proxied0server opening up perfectly.

############################################################################
server {
        listen 2001;
        location / {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
#############################################################################



However, I am not able to do the proxying if I perform url-rewriting.
Nothing of the following works ::

a)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


b)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


c)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

The URL does changes from http://1.2.3.4:2001/78 to http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.


d)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I getting a 404, even though the URL-change is perfect.


Any ideas please?


Thanks and Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Anoop P Alias 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Anoop Alias
The 404 is thrown by whatever is working on port 2000 ;so you can check its access log and see 


On Sat, Apr 8, 2017 at 6:54 PM, Ajay Garg <[hidden email]> wrote:
Hi Anoop.

As per http://serverfault.com/questions/379675/nginx-reverse-proxy-url-rewrite, the rewrite should be automatic.
But it does not work for me :(

On Sat, Apr 8, 2017 at 6:49 PM, Anoop Alias <[hidden email]> wrote:
I think you are confusing between url-rewrite and location

On Sat, Apr 8, 2017 at 6:39 PM, Ajay Garg <[hidden email]> wrote:
Hi All.

When I setup the following, the authentication+proxying works perfect, with the url changing from http://1.2.3.4:2001 to http://1.2.3.4:2001/cgi-bin/webproc, and the proxied0server opening up perfectly.

############################################################################
server {
        listen 2001;
        location / {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
#############################################################################



However, I am not able to do the proxying if I perform url-rewriting.
Nothing of the following works ::

a)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


b)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


c)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

The URL does changes from http://1.2.3.4:2001/78 to http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.


d)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I getting a 404, even though the URL-change is perfect.


Any ideas please?


Thanks and Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Anoop P Alias 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Anoop P Alias 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Ajay Garg
The same thing works if I put "/" in the location.
The URL-change is the same, and things work seamlessly.

It is definitely something that I am missing while specifying a location other than "/", that is causing incomplete proxying under the hood.

On Sat, Apr 8, 2017 at 7:10 PM, Anoop Alias <[hidden email]> wrote:
The 404 is thrown by whatever is working on port 2000 ;so you can check its access log and see 


On Sat, Apr 8, 2017 at 6:54 PM, Ajay Garg <[hidden email]> wrote:
Hi Anoop.

As per http://serverfault.com/questions/379675/nginx-reverse-proxy-url-rewrite, the rewrite should be automatic.
But it does not work for me :(

On Sat, Apr 8, 2017 at 6:49 PM, Anoop Alias <[hidden email]> wrote:
I think you are confusing between url-rewrite and location

On Sat, Apr 8, 2017 at 6:39 PM, Ajay Garg <[hidden email]> wrote:
Hi All.

When I setup the following, the authentication+proxying works perfect, with the url changing from http://1.2.3.4:2001 to http://1.2.3.4:2001/cgi-bin/webproc, and the proxied0server opening up perfectly.

############################################################################
server {
        listen 2001;
        location / {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
#############################################################################



However, I am not able to do the proxying if I perform url-rewriting.
Nothing of the following works ::

a)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


b)
############################################################################
server {
        listen 2001;
        location /78 {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


c)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000/;
                }
        }
############################################################################

The URL does changes from http://1.2.3.4:2001/78 to http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.


d)
############################################################################
server {
        listen 2001;
        location /78/ {

                        auth_basic 'Restricted';
                        auth_basic_user_file /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
                        proxy_pass http://127.0.0.1:2000;
                }
        }
############################################################################

No URL change happens, and 404 (illegal-file-access) is obtained.


So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I getting a 404, even though the URL-change is perfect.


Any ideas please?


Thanks and Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Anoop P Alias 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Anoop P Alias 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Francis Daly
In reply to this post by Ajay Garg
On Sat, Apr 08, 2017 at 06:39:59PM +0530, Ajay Garg wrote:

Hi there,

> However, I am not able to do the proxying if I perform url-rewriting.
> Nothing of the following works ::

Note that if you want to reverse-proxy a back-end web service at a
different part of the url hierarchy to where it believes it is installed,
in general you need the web service to help.

That is, if you want the back-end / to correspond to the front-end /x/,
then if the back-end ever links to something like /a, you will need that
to become translated to /x/a before it leaves the front-end. In general,
the front-end cannot do that translation.

So you may find it easier to configure the back-end to be (or to act as
if it is) installed below /x/ directly.

Otherwise things can go wrong.

What that means is...

> a)
> server {
>         listen 2001;
>         location /78 {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass <a href="http://127.0.0.1:2000;">http://127.0.0.1:2000;
>                 }
>         }
> ############################################################################
>
> No URL change happens, and 404 (illegal-file-access) is obtained.

If you request http://1.2.3.4:2001/78, nginx should request
http://127.0.0.1:2000/78, and I guess that the back-end said 404.

What do the back-end logs say?

Can you show a specific "curl" command, with "-v" or "-i", that you can
use to show this error case?

> b)
> ############################################################################
> server {
>         listen 2001;
>         location /78 {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass http://127.0.0.1:2000/;
>                 }
>         }
> ############################################################################
>
> No URL change happens, and 404 (illegal-file-access) is obtained.

If you request http://1.2.3.4:2001/78, nginx should request
http://127.0.0.1:2000/. Does the 404 come from nginx or the back-end?

What do the back-end logs say?

(Did you request http://1.2.3.4:2001/78, or http://1.2.3.4:2001/78/ --
because the two urls arl different.)

> c)
> ############################################################################
> server {
>         listen 2001;
>         location /78/ {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass http://127.0.0.1:2000/;
>                 }
>         }
> ############################################################################
>
> The URL does changes from http://1.2.3.4:2001/78 to
> http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.

If you request http://1.2.3.4:2001/78, nginx should return 301
redirecting you to http://1.2.3.4:2001/78/. If you then request
http://1.2.3.4:2001/78/, nginx should request http://127.0.0.1:2000/. I
guess that the back-end then returns 301 redirecting you to
/cgi-bin/webproc. If you request http://1.2.3.4:2001/cgi-bin/webproc,
then nginx should return 404 (because /cgi-bin/webproc does not start
with /78/).

Can you see all of those requests and responses, especially the ones
involving the back-end?

> d)
> ############################################################################
> server {
>         listen 2001;
>         location /78/ {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass <a href="http://127.0.0.1:2000;">http://127.0.0.1:2000;
>                 }
>         }
> ############################################################################
>
> No URL change happens, and 404 (illegal-file-access) is obtained.

Similar to a)

> So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I
> getting a 404, even though the URL-change is perfect.

You have multiple possible configurations there. And you have not shown
the details of the requests and responses.

Can you show some requests that you want the client to make of nginx,
and then show the matching requests that you want nginx to make of
the back-end?

You can use "curl" on the nginx machine to make similar requests of the
back-end yourself, to see that actual response details. That might give
a hint as to what, if any, proxy_redirect directives are needed.

> Any ideas please?

Can you configure the web service on port 2000 to believe that all of
its useful urls are below /78/ ? If so, use configuration d).

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Ajay Garg
Hi Francis.

Thanks for your detailed analysis.

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.

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,
                         port 2003 for proxying to service running on ssh-tunnel at 2002, and so on.


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.


Would love to hear back your thoughts.



Thanks and Regards,
Ajay

On Sun, Apr 9, 2017 at 4:19 PM, Francis Daly <[hidden email]> wrote:
On Sat, Apr 08, 2017 at 06:39:59PM +0530, Ajay Garg wrote:

Hi there,

> However, I am not able to do the proxying if I perform url-rewriting.
> Nothing of the following works ::

Note that if you want to reverse-proxy a back-end web service at a
different part of the url hierarchy to where it believes it is installed,
in general you need the web service to help.

That is, if you want the back-end / to correspond to the front-end /x/,
then if the back-end ever links to something like /a, you will need that
to become translated to /x/a before it leaves the front-end. In general,
the front-end cannot do that translation.

So you may find it easier to configure the back-end to be (or to act as
if it is) installed below /x/ directly.

Otherwise things can go wrong.

What that means is...

> a)
> server {
>         listen 2001;
>         location /78 {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass http://127.0.0.1:2000;
>                 }
>         }
> ############################################################################
>
> No URL change happens, and 404 (illegal-file-access) is obtained.

If you request http://1.2.3.4:2001/78, nginx should request
http://127.0.0.1:2000/78, and I guess that the back-end said 404.

What do the back-end logs say?

Can you show a specific "curl" command, with "-v" or "-i", that you can
use to show this error case?

> b)
> ############################################################################
> server {
>         listen 2001;
>         location /78 {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass http://127.0.0.1:2000/;
>                 }
>         }
> ############################################################################
>
> No URL change happens, and 404 (illegal-file-access) is obtained.

If you request http://1.2.3.4:2001/78, nginx should request
http://127.0.0.1:2000/. Does the 404 come from nginx or the back-end?

What do the back-end logs say?

(Did you request http://1.2.3.4:2001/78, or http://1.2.3.4:2001/78/ --
because the two urls arl different.)

> c)
> ############################################################################
> server {
>         listen 2001;
>         location /78/ {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass http://127.0.0.1:2000/;
>                 }
>         }
> ############################################################################
>
> The URL does changes from http://1.2.3.4:2001/78 to
> http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.

If you request http://1.2.3.4:2001/78, nginx should return 301
redirecting you to http://1.2.3.4:2001/78/. If you then request
http://1.2.3.4:2001/78/, nginx should request http://127.0.0.1:2000/. I
guess that the back-end then returns 301 redirecting you to
/cgi-bin/webproc. If you request http://1.2.3.4:2001/cgi-bin/webproc,
then nginx should return 404 (because /cgi-bin/webproc does not start
with /78/).

Can you see all of those requests and responses, especially the ones
involving the back-end?

> d)
> ############################################################################
> server {
>         listen 2001;
>         location /78/ {
>
>                         auth_basic 'Restricted';
>                         auth_basic_user_file
> /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
>                         proxy_pass http://127.0.0.1:2000;
>                 }
>         }
> ############################################################################
>
> No URL change happens, and 404 (illegal-file-access) is obtained.

Similar to a)

> So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I
> getting a 404, even though the URL-change is perfect.

You have multiple possible configurations there. And you have not shown
the details of the requests and responses.

Can you show some requests that you want the client to make of nginx,
and then show the matching requests that you want nginx to make of
the back-end?

You can use "curl" on the nginx machine to make similar requests of the
back-end yourself, to see that actual response details. That might give
a hint as to what, if any, proxy_redirect directives are needed.

> Any ideas please?

Can you configure the web service on port 2000 to believe that all of
its useful urls are below /78/ ? If so, use configuration d).

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Francis Daly
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.

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.

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        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> wrote:
Hi Francis.

Thanks a ton for your suggestions.

On Sun, Apr 9, 2017 at 5:58 PM, Francis Daly <[hidden email]> 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        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Francis Daly
On Sun, Apr 09, 2017 at 06:36:51PM +0530, Ajay Garg wrote:

Hi there,

> Got it Francis !!

Good news.

>                 location / {
>                                         auth_basic 'Restricted';
>                                         auth_basic_user_file
> /home/20da689b45c84f2b80bc84d651ed573f/.htpasswd;
>
>                                         if ($remote_user =
> "20da689b45c84f2b80bc84d651ed573f") {
>                                                 proxy_pass
> <a href="https://127.0.0.1:2000;">https://127.0.0.1:2000;
>                                         }
>
>                 }

When you come to add the second user, you will see that you want one
file with all the user/pass details.

You will probably also see that it will be good to use a map
(http://nginx.org/r/map) to set a variable for the port to connect to,
based on $remote_user. Then your main config becomes just "proxy_pass
<a href="http://127.0.0.1:$per_user_port;">http://127.0.0.1:$per_user_port;".

Note that I have not tested that, and expect that there may be some more
subtleties involved, such as perhaps requiring an explicit proxy_redirect
directive.

Note also that you will probably want to set a default value for
$per_user_port, and make sure that something sensible happens when that
value is used -- probably a response along the lines of "something isn't
fully set up on the server yet; please wait or let us know", so the user
is not confused.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Ajay Garg
Hi Francis.

On Sun, Apr 9, 2017 at 8:47 PM, Francis Daly <[hidden email]> wrote:
On Sun, Apr 09, 2017 at 06:36:51PM +0530, Ajay Garg wrote:

Hi there,

> Got it Francis !!

Good news.

>                 location / {
>                                         auth_basic 'Restricted';
>                                         auth_basic_user_file
> /home/20da689b45c84f2b80bc84d651ed573f/.htpasswd;
>
>                                         if ($remote_user =
> "20da689b45c84f2b80bc84d651ed573f") {
>                                                 proxy_pass
> https://127.0.0.1:2000;
>                                         }
>
>                 }

When you come to add the second user, you will see that you want one
file with all the user/pass details.
 

Yes, I have already changed it to use just one file.
Upon that, would not just multiple sections of "if" checks for $remote_user suffice, something like ::

#########################################################################
server {
                listen 2000 ssl;

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

                location / {
                                        auth_basic 'Restricted';
                                        auth_basic_user_file /etc/nginx/ssl/.htpasswd;

                                        if ($remote_user =  "user1") {
                                                proxy_pass https://127.0.0.1:2001;
                                        }

                                        if ($remote_user =  "user2") {
                                                proxy_pass https://127.0.0.1:2002;
                                        }

                                       # and so on ....

                }
         }
#########################################################################

Looking forward to hearing back from you.


Thanks and Regards,
Ajay


 

You will probably also see that it will be good to use a map
(http://nginx.org/r/map) to set a variable for the port to connect to,
based on $remote_user. Then your main config becomes just "proxy_pass
http://127.0.0.1:$per_user_port;".

Note that I have not tested that, and expect that there may be some more
subtleties involved, such as perhaps requiring an explicit proxy_redirect
directive.

Note also that you will probably want to set a default value for
$per_user_port, and make sure that something sensible happens when that
value is used -- probably a response along the lines of "something isn't
fully set up on the server yet; please wait or let us know", so the user
is not confused.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Lucas Rolff-2
In general try to avoid using the if directive too much.
https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

For what you're trying to do, using a map would be the cleanest (and nicest) way I believe – someone can correct me if they want :-D

From: nginx <[hidden email]> on behalf of Ajay Garg <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Sunday, 9 April 2017 at 17.37
To: "[hidden email]" <[hidden email]>
Subject: Re: URL-Rewriting not working

Hi Francis.

On Sun, Apr 9, 2017 at 8:47 PM, Francis Daly <[hidden email]> wrote:
On Sun, Apr 09, 2017 at 06:36:51PM +0530, Ajay Garg wrote:

Hi there,

> Got it Francis !!

Good news.

>                 location / {
>                                         auth_basic 'Restricted';
>                                         auth_basic_user_file
> /home/20da689b45c84f2b80bc84d651ed573f/.htpasswd;
>
>                                         if ($remote_user =
> "20da689b45c84f2b80bc84d651ed573f") {
>                                                 proxy_pass
> https://127.0.0.1:2000;
>                                         }
>
>                 }

When you come to add the second user, you will see that you want one
file with all the user/pass details.
 

Yes, I have already changed it to use just one file.
Upon that, would not just multiple sections of "if" checks for $remote_user suffice, something like ::

#########################################################################
server {
                listen 2000 ssl;

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

                location / {
                                        auth_basic 'Restricted';
                                        auth_basic_user_file /etc/nginx/ssl/.htpasswd;

                                        if ($remote_user =  "user1") {
                                                proxy_pass https://127.0.0.1:2001;
                                        }

                                        if ($remote_user =  "user2") {
                                                proxy_pass https://127.0.0.1:2002;
                                        }

                                       # and so on ....

                }
         }
#########################################################################

Looking forward to hearing back from you.


Thanks and Regards,
Ajay


 

You will probably also see that it will be good to use a map
(http://nginx.org/r/map) to set a variable for the port to connect to,
based on $remote_user. Then your main config becomes just "proxy_pass
<a href="http://127.0.0.1:$per_user_por">http://127.0.0.1:$per_user_port;".

Note that I have not tested that, and expect that there may be some more
subtleties involved, such as perhaps requiring an explicit proxy_redirect
directive.

Note also that you will probably want to set a default value for
$per_user_port, and make sure that something sensible happens when that
value is used -- probably a response along the lines of "something isn't
fully set up on the server yet; please wait or let us know", so the user
is not confused.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: URL-Rewriting not working

Ajay Garg
Thanks a ton Lucas .. moved to map :)

Thanks a ton again !!!



Thanks and Regards,
Ajay

On Sun, Apr 9, 2017 at 9:17 PM, Lucas Rolff <[hidden email]> wrote:
In general try to avoid using the if directive too much.

For what you're trying to do, using a map would be the cleanest (and nicest) way I believe – someone can correct me if they want :-D

From: nginx <[hidden email]> on behalf of Ajay Garg <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Sunday, 9 April 2017 at 17.37
To: "[hidden email]" <[hidden email]>
Subject: Re: URL-Rewriting not working

Hi Francis.

On Sun, Apr 9, 2017 at 8:47 PM, Francis Daly <[hidden email]> wrote:
On Sun, Apr 09, 2017 at 06:36:51PM +0530, Ajay Garg wrote:

Hi there,

> Got it Francis !!

Good news.

>                 location / {
>                                         auth_basic 'Restricted';
>                                         auth_basic_user_file
> /home/20da689b45c84f2b80bc84d651ed573f/.htpasswd;
>
>                                         if ($remote_user =
> "20da689b45c84f2b80bc84d651ed573f") {
>                                                 proxy_pass
> https://127.0.0.1:2000;
>                                         }
>
>                 }

When you come to add the second user, you will see that you want one
file with all the user/pass details.
 

Yes, I have already changed it to use just one file.
Upon that, would not just multiple sections of "if" checks for $remote_user suffice, something like ::

#########################################################################
server {
                listen 2000 ssl;

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

                location / {
                                        auth_basic 'Restricted';
                                        auth_basic_user_file /etc/nginx/ssl/.htpasswd;

                                        if ($remote_user =  "user1") {
                                                proxy_pass https://127.0.0.1:2001;
                                        }

                                        if ($remote_user =  "user2") {
                                                proxy_pass https://127.0.0.1:2002;
                                        }

                                       # and so on ....

                }
         }
#########################################################################

Looking forward to hearing back from you.


Thanks and Regards,
Ajay


 

You will probably also see that it will be good to use a map
(http://nginx.org/r/map) to set a variable for the port to connect to,
based on $remote_user. Then your main config becomes just "proxy_pass
<a href="http://127.0.0.1:$per_user_por" target="_blank">http://127.0.0.1:$per_user_port;".

Note that I have not tested that, and expect that there may be some more
subtleties involved, such as perhaps requiring an explicit proxy_redirect
directive.

Note also that you will probably want to set a default value for
$per_user_port, and make sure that something sensible happens when that
value is used -- probably a response along the lines of "something isn't
fully set up on the server yet; please wait or let us know", so the user
is not confused.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



--
Regards,
Ajay

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Loading...