Proxy_pass url with a #

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Proxy_pass url with a #

Brian W.
In have this largely working aside from the above. If I proxy pass to the url with a # in it it's treated like a comment and ignores the rest. If I encode it with %23 I get a 404 error. What have you all done to get past this?

Brian

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

Re: Proxy_pass url with a #

Francis Daly
On Fri, Oct 05, 2018 at 08:59:21AM -0700, Brian W. wrote:

Hi there,

> In have this largely working aside from the above. If I proxy pass to the
> url with a # in it it's treated like a comment and ignores the rest. If I
> encode it with %23 I get a 404 error. What have you all done to get past
> this?

# is usually not included in a url that is sent in a request to a web server.

Can you describe what you want to achieve, and what you are currently doing?

Perhaps that will make clearer how to make it happen.

Cheers,

        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
|

Re: Proxy_pass url with a #

Brian W.
In summary I am trying to reverse proxy a group of windows web servers,
where there is a # in the url. I have it mostly working except this. I
used the nginx ldap auth modules, including their sample backend app. In
that app, when auth succeeds a page is presented with a hello world you
were successful message; what I want to do is actually load one of those
windows webservers. I've been trying to use the python requests module
via a typical import, but have not gotten this quite right. If I use #
then it is treated as a comment skipping the rest of the url, and if I
use %23 I get a 404 in a tcpdump. I dont think the hash is the whole
problem though, since if I try to load some other page after the
successful auth it also fails.

I know also that If I just do a straight proxy_pass to the url without
the ldap auth and then type in nginxserver/path#/with/pound that works.

Brian

On 10/6/18 3:41 PM, Francis Daly wrote:

> On Fri, Oct 05, 2018 at 08:59:21AM -0700, Brian W. wrote:
>
> Hi there,
>
>> In have this largely working aside from the above. If I proxy pass to the
>> url with a # in it it's treated like a comment and ignores the rest. If I
>> encode it with %23 I get a 404 error. What have you all done to get past
>> this?
> # is usually not included in a url that is sent in a request to a web server.
>
> Can you describe what you want to achieve, and what you are currently doing?
>
> Perhaps that will make clearer how to make it happen.
>
> Cheers,
>
> f

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

Re: Proxy_pass url with a #

Francis Daly
On Sun, Oct 07, 2018 at 06:54:54AM -0700, Brian Whalen wrote:

Hi there,

> In summary I am trying to reverse proxy a group of windows web servers,
> where there is a # in the url. I have it mostly working except this.

I'm afraid I still don't fully understand what specific problem you
are reporting.

However, from later in your mail, it appears that the # may not be
fully relevant.

> I dont think the hash is the whole problem though, since if I try
> to load some other page after the successful auth it also fails.

Can you show one specific request that you make, and show the response
that you get, and indicate how it is different from the response that you
want? That might make it possible for someone else to repeat the issue,
which might make it easier to identify the solution.

> I know also that If I just do a straight proxy_pass to the url without the
> ldap auth and then type in nginxserver/path#/with/pound that works.

Can you describe that in terms of http requests, perhaps made using the
"curl" command line client?

If you look in the access logs of nginx and the upstream for these
requests, do you see the # character appearing at all?

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
|

Re: Proxy_pass url with a #

Brian W.
I want to do a successful auth, which I can, and then after the successful auth be reverse proxied to the specified web server, not a simple 302 redirect, but actual reverse proxy. When I replace the hello world line with a get, I just get blank white screen. I can curl -i and get a 200. I can also reverse proxy without the auth and have it work. 

What I need to figure out is how do I do the reverse proxy to a web server on a different machine and send the user there via reverse proxy after a successful auth.

Brian

On Mon, Oct 8, 2018, 7:07 AM Francis Daly <[hidden email]> wrote:
On Sun, Oct 07, 2018 at 06:54:54AM -0700, Brian Whalen wrote:

Hi there,

> In summary I am trying to reverse proxy a group of windows web servers,
> where there is a # in the url. I have it mostly working except this.

I'm afraid I still don't fully understand what specific problem you
are reporting.

However, from later in your mail, it appears that the # may not be
fully relevant.

> I dont think the hash is the whole problem though, since if I try
> to load some other page after the successful auth it also fails.

Can you show one specific request that you make, and show the response
that you get, and indicate how it is different from the response that you
want? That might make it possible for someone else to repeat the issue,
which might make it easier to identify the solution.

> I know also that If I just do a straight proxy_pass to the url without the
> ldap auth and then type in nginxserver/path#/with/pound that works.

Can you describe that in terms of http requests, perhaps made using the
"curl" command line client?

If you look in the access logs of nginx and the upstream for these
requests, do you see the # character appearing at all?

Good luck with it,

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

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

Re: Proxy_pass url with a #

Francis Daly
On Mon, Oct 08, 2018 at 08:21:08AM -0700, Brian W. wrote:

Hi there,

> I want to do a successful auth, which I can, and then after the successful
> auth be reverse proxied to the specified web server, not a simple 302
> redirect, but actual reverse proxy. When I replace the hello world line
> with a get, I just get blank white screen. I can curl -i and get a 200. I
> can also reverse proxy without the auth and have it work.

I'm still unclear about what you mean by the above.

I *think* you are saying:

when your nginx.conf has

  server {
    location / {
      proxy_pass http://windows-server;
    }
  }

that everything works; you can "curl -v http://nginx/something" and get
the expected response from http://windows-server/something.

Am I correct in that much?


I also think you are saying:

when your nginx.conf has

  server {
    location / {
      auth_request /auth;
      proxy_pass http://windows-server;
    }
    location = /auth {
      # your ldap-related things that return http 200 when things are good,
      # and 401 or 403 when things are bad
    }
  }

then some parts fail in some way -- you request http://nginx/something,
and you expect one response but you get one other response -- possibly
a http 302 to some other url?

Am I correct in that?

> What I need to figure out is how do I do the reverse proxy to a web server
> on a different machine and send the user there via reverse proxy after a
> successful auth.

In nginx terms, that's auth_request -- http://nginx.org/r/auth_request

If we can understand where in the sequence things fail first, maybe it
will be clearer what needs to change in order to get things to succeed.

Cheers,

        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
|

Re: Proxy_pass url with a #

Brian W.
Ok I figured it out. A page I saw mentioned copying the ldap conf as the nginx.conf file and using that and I did. I erroneously thought the port 9000 connection in there was a necessary ldap connect piece and so I didn't change it, until today with your questioning.

Thanx
Brian 

On Mon, Oct 8, 2018, 11:22 AM Francis Daly <[hidden email]> wrote:
On Mon, Oct 08, 2018 at 08:21:08AM -0700, Brian W. wrote:

Hi there,

> I want to do a successful auth, which I can, and then after the successful
> auth be reverse proxied to the specified web server, not a simple 302
> redirect, but actual reverse proxy. When I replace the hello world line
> with a get, I just get blank white screen. I can curl -i and get a 200. I
> can also reverse proxy without the auth and have it work.

I'm still unclear about what you mean by the above.

I *think* you are saying:

when your nginx.conf has

  server {
    location / {
      proxy_pass http://windows-server;
    }
  }

that everything works; you can "curl -v http://nginx/something" and get
the expected response from http://windows-server/something.

Am I correct in that much?


I also think you are saying:

when your nginx.conf has

  server {
    location / {
      auth_request /auth;
      proxy_pass http://windows-server;
    }
    location = /auth {
      # your ldap-related things that return http 200 when things are good,
      # and 401 or 403 when things are bad
    }
  }

then some parts fail in some way -- you request http://nginx/something,
and you expect one response but you get one other response -- possibly
a http 302 to some other url?

Am I correct in that?

> What I need to figure out is how do I do the reverse proxy to a web server
> on a different machine and send the user there via reverse proxy after a
> successful auth.

In nginx terms, that's auth_request -- http://nginx.org/r/auth_request

If we can understand where in the sequence things fail first, maybe it
will be clearer what needs to change in order to get things to succeed.

Cheers,

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

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

Re: Proxy_pass url with a #

Francis Daly
On Mon, Oct 08, 2018 at 12:53:36PM -0700, Brian W. wrote:

Hi there,

> Ok I figured it out.

Good stuff.

> A page I saw mentioned copying the ldap conf as the
> nginx.conf file and using that and I did. I erroneously thought the port
> 9000 connection in there was a necessary ldap connect piece and so I didn't
> change it, until today with your questioning.

Ah, with hindsight, I think I understand what happened.

https://github.com/nginxinc/nginx-ldap-auth/blob/master/nginx-ldap-auth.conf

shows the backend as both handling /login and providing the common
response, while the ldap-auth daemon is separate.

And the login service issues a redirect itself.

In your case, I guess that the /login-equivalent (if it exists) is *not*
on the same server as the backend common content -- so "proxy_pass
http://backend/;" there becomes "proxy_pass http://windows-server/;"
in your case.

And hopefully the part with the # in the client-side url Just Works for
you too.

Glad you got it working,

        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
|

Re: Proxy_pass url with a #

Brian W.
Yes on both counts, I didnt see that the /logon could also be the backend proxy_pass. I was trying to stick all sorts of python gets in the backend-sample-app.py script which was not right, and the # issue was a non issue, because there is an auto redirect from / to the desired url.

Brian 

On Mon, Oct 8, 2018, 3:12 PM Francis Daly <[hidden email]> wrote:
On Mon, Oct 08, 2018 at 12:53:36PM -0700, Brian W. wrote:

Hi there,

> Ok I figured it out.

Good stuff.

> A page I saw mentioned copying the ldap conf as the
> nginx.conf file and using that and I did. I erroneously thought the port
> 9000 connection in there was a necessary ldap connect piece and so I didn't
> change it, until today with your questioning.

Ah, with hindsight, I think I understand what happened.

https://github.com/nginxinc/nginx-ldap-auth/blob/master/nginx-ldap-auth.conf

shows the backend as both handling /login and providing the common
response, while the ldap-auth daemon is separate.

And the login service issues a redirect itself.

In your case, I guess that the /login-equivalent (if it exists) is *not*
on the same server as the backend common content -- so "proxy_pass
http://backend/;" there becomes "proxy_pass http://windows-server/;"
in your case.

And hopefully the part with the # in the client-side url Just Works for
you too.

Glad you got it working,

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

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