Nonstandard Response Headers

Is there a way to get Nginx to send nonstandard response headers (e.g.
“User-Header”); it looks like they’re being filtered.

Thanks,
Brendan

Brendan Schwartz wrote:

Is there a way to get Nginx to send nonstandard response headers (e.g.
“User-Header”); it looks like they’re being filtered.

Thanks,
Brendan

Check out the proxy_pass_header directive.

http://wiki.codemongers.com/NginxHttpProxyModule#proxy_pass_header

Evan

On Dec 29, 2007 5:48 PM, Evan M. [email protected] wrote:

http://wiki.codemongers.com/NginxHttpProxyModule#proxy_pass_header

Evan

This doesn’t seem to be working for me. Here’s an example of what I’m
trying to accomplish:

I have a local backend that returns a response that includes
X-Accel-Redirect, Authorization, and Some-Other-Header headers among
others.
And I have a /remote-proxy location whose job it is to proxy the
X-Accel-Redirect to a remote server.
See example configuration below.

I would like the proxy-pass request to the remote server to include
the Authorization and Some-Other-Header headers that were returned in
the local backend upstream response.

I’ve tried to use the proxy_pass_header directive, but haven’t had
much luck as my “custom” headers aren’t being passed to the remote
proxy server.

Am I using these directives correctly? Is what I’m trying to do
impossible?

Thanks,
Brendan


server {

standard config …

location /remote-proxy/ {
  internal;

  proxy_set_header  X-Real-IP  $remote_addr;

  # needed for HTTPS
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host remote.server.com;
  proxy_redirect false;
  proxy_max_temp_file_size 0;

  rewrite ^/remote-proxy/(.*)$ /$1 break;
  proxy_pass https://remote.server.com;
}

location / {

  proxy_set_header  X-Real-IP  $remote_addr;

  # needed for HTTPS
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $http_host;
  proxy_redirect false;
  proxy_max_temp_file_size 0;

  proxy_pass_header Authorization;
  proxy_pass_header Some-Other-Header;

  proxy_pass http://local_backend_upstream;

}
}

Brendan Schwartz ha scritto:

X-Accel-Redirect to a remote server.
Am I using these directives correctly? Is what I’m trying to do impossible?
location /remote-proxy/ {
rewrite ^/remote-proxy/(.*)$ /$1 break;
proxy_pass https://remote.server.com;

Here, instead of using a rewrite, try with

     proxy_pass https://remote.server.com/remote-proxy/
  proxy_max_temp_file_size 0;

  proxy_pass_header Authorization;
  proxy_pass_header Some-Other-Header;

  proxy_pass http://local_backend_upstream;

}
}

I’m not sure to understand what you are trying to do.
But try with:

    set $authorization upstream_http_authorization;
    set $some_other upstream_http_some_other_header;

in the / location

and:

    proxy_set_header Authorization $authorization;
    proxy_set_header Some-Other-Header $some_other;

in the remote-proxy location

However I’m rather sure that this will not work :).

Manlio P.

On Jan 20, 2008 4:07 PM, Manlio P. [email protected]
wrote:

others.
proxy server.

standard config …

  proxy_max_temp_file_size 0;

  proxy_pass_header Authorization;

But try with:

in the remote-proxy location

However I’m rather sure that this will not work :).

Manlio P.

Manlio,

Unfortunately this doesn’t seem to work. “set $authorization
upstream_http_authorization;” sets the $authorization variable to the
string “upstream_http_authorization”. If I change the line to “set
$authorization $upstream_http_authorization;”, it doesn’t work either.
I think that’s because in Location / the Authorization header isn’t
set yet – it’s set by the local backend.

I’m trying to use nginx as a proxy for a remote server. But in order
to access the content on the remote server, I need to pass an
Authorization header to it. The local backend is able to produce valid
authorization tokens.

So here’s what I want to happen: the local backend produces an
Authorization header which is then passed to the remote server
backend. The remote server accepts the authorized request and returns
the protect content to nginx which passes it on to the end user.

Does this make sense?

Thanks,
Brendan

Brendan Schwartz ha scritto:

    proxy_set_header Authorization $authorization;

Manlio,

Unfortunately this doesn’t seem to work. “set $authorization
upstream_http_authorization;” sets the $authorization variable to the
string “upstream_http_authorization”.

Yes, you are right, sorry.

If I change the line to “set
$authorization $upstream_http_authorization;”, it doesn’t work either.
I think that’s because in Location / the Authorization header isn’t
set yet – it’s set by the local backend.

Try to use $upstream_http_authorization directly in the remote-proxy
location.

If this does not work, then I have no idea on how to solve your problem.

Does this make sense?

Why don’t just ask the user to supply the Authorization header?

Moreover, since the remote-proxy is “internal”, I don’t see any need to
supply authorization info.

The authorization must be done in the local backend, and only if the
client is allowed to access the protected content, you set the
X-Accel-Redirect.

This content is only accessible by nginx, and not by external clients.

Thanks,
Brendan

Manlio P.

On Jan 20, 2008 11:34 PM, Eden Li [email protected] wrote:

need to do this in an fcgi handler or somesuch.

Eden, yes, you have it correct.

The fundamental problem here is around passing the auth token header to
the
remote proxy.
It appears that when using X-Accel-Redirect, nginx will not pass headers
generated by the backend through to the redirect target.

Igor, do I have this right?

if i understand correctly, you need to terminate the “local backend”
request at nginx before passing back data to the client.

  1. end user asks for protected content from nginx
  2. nginx asks for auth token from “local backend”
  3. nginx proxies the rest of the connection from (1) attaching the
    auth token from (2) to the request.

you probably need more than nginx for this. you might be able to
shove step (2) into an embedded perl module, but most likely you’ll
need to do this in an fcgi handler or somesuch.

On Jan 21, 2008 4:21 AM, Manlio P. [email protected]
wrote:

and:
Manlio P.
Yes, you are right, sorry.
location.

If this does not work, then I have no idea on how to solve your problem.

Unfortunately, this doesn’t work.

X-Accel-Redirect.

This content is only accessible by nginx, and not by external clients.

In my situation the end user shouldn’t (and doesn’t) have any
knowledge of the authentication mechanism between this “remote server”
and nginx. The remote-proxy is marked as “internal” to prevent users
from accessing that URL directly (without permission from the local
backend) and gaining access to the protected content on the remote
server.

What I’d like to have happen is this:
The end user authenticates with the local backend at which point nginx
will fetch the protected content from the remote server and serve it
to them.

On Jan 22, 2008 3:57 AM, Manlio P. [email protected]
wrote:

Unfortunately, this doesn’t work.

authorization tokens.
Moreover, since the remote-proxy is “internal”, I don’t see any need to
knowledge of the authentication mechanism between this “remote server”

But this is already supported by nginx.
You have to set the X-Accel-Redirect only when the end user successfully
authenticate with the local backend.

Yes, and that part has been working without a hitch. But in my
situation, the content that I’m X-Accel-Redirect’ing to is on another
server and that server requires an auth token in order to get at the
content. So, the piece that I can’t seem to figure out is how to get
Nginx to pass the auth token header I generate on the local backend to
the remote server.

The output from the local backend contains headers like this:
Authorization: mytoken123
X-Accel-Redirect: /remote-proxy/my_protected_asset

I would like the Authorization header to be passed to the
remote-proxy. However, I can’t figure out a way to do this.

Brendan Schwartz ha scritto:

I think the problem is with the two upstream being in two separate
locations.

Does this make sense?
This content is only accessible by nginx, and not by external clients.
The end user authenticates with the local backend at which point nginx
will fetch the protected content from the remote server and serve it
to them.

But this is already supported by nginx.
You have to set the X-Accel-Redirect only when the end user successfully
authenticate with the local backend.

Thanks,
Brendan

Manlio P.

Manlio P.