Nonstandard Response Headers

[Brendan Schwartz]

On Jan 21, 2008 4:21 AM, Manlio Perillo <manlio_perillo at libero.it> wrote:

> Brendan Schwartz ha scritto:
> > [...]
>
> >> 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 Perillo
> >>
> >>
> >
> > 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.
>

Unfortunately, this doesn't work.

>
> > 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?
> >
>
> 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.
>

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.

> > Thanks,
> > Brendan
> >
> >
>
>
> Manlio Perillo
>
>