authentication being passed to php

[István]

no worries

;)

On Thu, Jul 23, 2009 at 4:29 AM, nginx.mailinglist <
nginx.mailinglist at xinio.info> wrote:

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


-- 
the sun shines for all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090723/c60ea928/attachment.html>