authentication being passed to php

[nginx.mailinglist]

Hmm
sorry for mix up i think i confused myself

whatever happened i now get the following entries in my php's $_SERVER


[HTTP_AUTHORIZATION] => Basic dGVzdDEyMzphYmM1Njc=
[PHP_AUTH_USER] => test123
[PHP_AUTH_PW] => abc567


which is exactly what i wanted, i can take the above values now and perfrom
authentication against the database

sorry for all the confusion
i dont think this was an issue at all in first place
just my tests were wrong

thanks for the prompt help



On Thu, Jul 23, 2009 at 12:13 PM, István <leccine at gmail.com> wrote:

> he is mixing up two different things
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>
> 14.8 Authorization
>
>       A user agent that wishes to authenticate itself with a server--
>       usually, but not necessarily, after receiving a 401 response--does
>       so by including an Authorization request-header field with the
>
>       request.  The Authorization field value consists of credentials
>       containing the authentication information of the user agent for
>       the realm of the resource being requested.
>
>           Authorization  = "Authorization" ":" credentials
>
>       HTTP access authentication is described in "HTTP Authentication:
>       Basic and Digest Access Authentication" [43] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec17.html#bib43>. If a request is
>
>       authenticated and a realm specified, the same credentials SHOULD
>       be valid for all other requests within this realm (assuming that
>       the authentication scheme itself does not require otherwise, such
>
>       as credentials that vary according to a challenge value or using
>       synchronized clocks).
>
>       When a shared cache (see section 13.7) receives a request
>       containing an Authorization field, it MUST NOT return the
>       corresponding response as a reply to any other request, unless one
>       of the following specific exceptions holds:
>
>       1. If the response includes the "s-maxage" cache-control
>          directive, the cache MAY use that response in replying to a
>          subsequent request. But (if the specified maximum age has
>
>          passed) a proxy cache MUST first revalidate it with the origin
>          server, using the request-headers from the new request to allow
>          the origin server to authenticate the new request. (This is the
>
>          defined behavior for s-maxage.) If the response includes "s-
>          maxage=0", the proxy MUST always revalidate it before re-using
>          it.
>
>       2. If the response includes the "must-revalidate" cache-control
>          directive, the cache MAY use that response in replying to a
>          subsequent request. But if the response is stale, all caches
>
>          MUST first revalidate it with the origin server, using the
>          request-headers from the new request to allow the origin server
>          to authenticate the new request.
>
>       3. If the response includes the "public" cache-control directive,
>          it MAY be returned in reply to any subsequent request.
>
>
>
> 2009/7/23 Igor Sysoev <is at rambler-co.ru>
>
>> On Thu, Jul 23, 2009 at 11:22:19AM +0100, nginx.mailinglist wrote:
>>
>> > Thank you
>> > I see that works fine for that particular user:pass combo
>> >
>> > but (sorry to be a pain)
>> >
>> > that means i have to encode the user:pass combination into the config
>> file
>> >
>> > what happens if there are thousands of user:pass combinations?
>> >
>> > how can this info be dynamically passed to the php backend for
>> > authentication to occur there (by looking up in a database for example)?
>> >
>> > i cant be updating the config file everytime a new user is added that
>> can be
>> > crazy especially if there are thousands or more users
>> >
>> > Regards
>> >
>> > edit: i google and found this old email conversation on nginx
>> mailinglist
>> >
>> http://markmail.org/message/tl7h2fclizgptwnr#query:NGINX%20PHP%20AUTHENTICATION+page:1+mid:f3xw2gjllat6urff+state:results
>>
>> I do not understand your problem.
>> nginx passes client's user:pass in Authorization header transparently.
>>
>> > 2009/7/23 Igor Sysoev <is at rambler-co.ru>
>> >
>> > > On Thu, Jul 23, 2009 at 10:50:12AM +0100, nginx.mailinglist wrote:
>> > >
>> > > > Hello
>> > > > just a quick question
>> > > >
>> > > > in lighttpd i was able to pass the username and pass from the url to
>> php
>> > > > backend
>> > > >
>> > > > but nothing happens in nginx?
>> > > >
>> > > > let me explain
>> > > >
>> > > >
>> > > > lets say you have a URL like this
>> > > >
>> > > > http://userX:passY@example.com/bleh.php
>> > > >
>> > > >
>> > > > i expect my php backend to have user and pass entries in the
>> $_SERVER
>> > > > variable as happens with lighttpd
>> > > >
>> > > > am i missing something with nginx? is it even possible?
>> > >
>> > > $echo userX:passY | perl -MMIME::Base64 -lne 'print encode_base64 $_'
>> > > dXNlclg6cGFzc1k=
>> > >
>> > >      proxy_pass http://example.com/bleh.php;
>> > >      proxy_set_header  Authorization "Basic dXNlclg6cGFzc1k=";
>> > >
>> > >
>> > > --
>> > > Igor Sysoev
>> > > http://sysoev.ru/en/
>> > >
>> > >
>>
>> --
>> Igor Sysoev
>> http://sysoev.ru/en/
>>
>>
>
>
> --
> the sun shines for all
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090723/29c1afb2/attachment.html>