no worries<br><br>;)<br><br><div class="gmail_quote">On Thu, Jul 23, 2009 at 4:29 AM, nginx.mailinglist <span dir="ltr">&lt;<a href="mailto:nginx.mailinglist@xinio.info">nginx.mailinglist@xinio.info</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hmm<div><br></div><div>sorry for mix up i think i confused myself</div><div><br></div><div>whatever happened i now get the following entries in my php&#39;s $_SERVER</div>
<div><br></div><div><br></div><div><div>[HTTP_AUTHORIZATION] =&gt; Basic dGVzdDEyMzphYmM1Njc=</div>
</div><div><div>[PHP_AUTH_USER] =&gt; test123</div><div>[PHP_AUTH_PW] =&gt; abc567</div><div><br></div><div><br></div><div>which is exactly what i wanted, i can take the above values now and perfrom authentication against the database</div>

<div><br></div><div>sorry for all the confusion</div><div>i dont think this was an issue at all in first place</div><div>just my tests were wrong</div><div><br></div><div>thanks for the prompt help</div></div><div><div></div>
<div class="h5"><div><br></div>
<div><br><br><div class="gmail_quote">On Thu, Jul 23, 2009 at 12:13 PM, István <span dir="ltr">&lt;<a href="mailto:leccine@gmail.com" target="_blank">leccine@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

he is mixing up two different things<br><br><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html" target="_blank">http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html</a><br><br><h3><a>14.8</a> Authorization</h3>



<pre>      A user agent that wishes to authenticate itself with a server--<br>      usually, but not necessarily, after receiving a 401 response--does<br>      so by including an Authorization request-header field with the<br>


      request.  The Authorization field value consists of credentials<br>      containing the authentication information of the user agent for<br>      the realm of the resource being requested.<br></pre>
<pre>          Authorization  = &quot;Authorization&quot; &quot;:&quot; credentials<br></pre>
<pre>      HTTP access authentication is described in &quot;HTTP Authentication:<br>      Basic and Digest Access Authentication&quot; <a rel="bibref" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec17.html#bib43" target="_blank">[43]</a>. If a request is<br>


      authenticated and a realm specified, the same credentials SHOULD<br>      be valid for all other requests within this realm (assuming that<br>      the authentication scheme itself does not require otherwise, such<br>


      as credentials that vary according to a challenge value or using<br>      synchronized clocks).<br></pre>
<pre>      When a shared cache (see section 13.7) receives a request<br>      containing an Authorization field, it MUST NOT return the<br>      corresponding response as a reply to any other request, unless one<br>      of the following specific exceptions holds:<br>


</pre>
<pre>      1. If the response includes the &quot;s-maxage&quot; cache-control<br>         directive, the cache MAY use that response in replying to a<br>         subsequent request. But (if the specified maximum age has<br>


         passed) a proxy cache MUST first revalidate it with the origin<br>         server, using the request-headers from the new request to allow<br>         the origin server to authenticate the new request. (This is the<br>


         defined behavior for s-maxage.) If the response includes &quot;s-<br>         maxage=0&quot;, the proxy MUST always revalidate it before re-using<br>         it.<br></pre>
<pre>      2. If the response includes the &quot;must-revalidate&quot; cache-control<br>         directive, the cache MAY use that response in replying to a<br>         subsequent request. But if the response is stale, all caches<br>


         MUST first revalidate it with the origin server, using the<br>         request-headers from the new request to allow the origin server<br>         to authenticate the new request.<br></pre>
<pre>      3. If the response includes the &quot;public&quot; cache-control directive,<br>         it MAY be returned in reply to any subsequent request.<br></pre><div><div></div><div><br><br><div class="gmail_quote">
2009/7/23 Igor Sysoev <span dir="ltr">&lt;<a href="mailto:is@rambler-co.ru" target="_blank">is@rambler-co.ru</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Thu, Jul 23, 2009 at 11:22:19AM +0100, nginx.mailinglist wrote:<br>
<br>
&gt; Thank you<br>
&gt; I see that works fine for that particular user:pass combo<br>
&gt;<br>
&gt; but (sorry to be a pain)<br>
&gt;<br>
&gt; that means i have to encode the user:pass combination into the config file<br>
&gt;<br>
&gt; what happens if there are thousands of user:pass combinations?<br>
&gt;<br>
&gt; how can this info be dynamically passed to the php backend for<br>
&gt; authentication to occur there (by looking up in a database for example)?<br>
&gt;<br>
&gt; i cant be updating the config file everytime a new user is added that can be<br>
&gt; crazy especially if there are thousands or more users<br>
&gt;<br>
&gt; Regards<br>
&gt;<br>
&gt; edit: i google and found this old email conversation on nginx mailinglist<br>
&gt; <a href="http://markmail.org/message/tl7h2fclizgptwnr#query:NGINX%20PHP%20AUTHENTICATION+page:1+mid:f3xw2gjllat6urff+state:results" target="_blank">http://markmail.org/message/tl7h2fclizgptwnr#query:NGINX%20PHP%20AUTHENTICATION+page:1+mid:f3xw2gjllat6urff+state:results</a><br>



<br>
</div>I do not understand your problem.<br>
nginx passes client&#39;s user:pass in Authorization header transparently.<br>
<div><br>
&gt; 2009/7/23 Igor Sysoev &lt;<a href="mailto:is@rambler-co.ru" target="_blank">is@rambler-co.ru</a>&gt;<br>
&gt;<br>
&gt; &gt; On Thu, Jul 23, 2009 at 10:50:12AM +0100, nginx.mailinglist wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hello<br>
&gt; &gt; &gt; just a quick question<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; in lighttpd i was able to pass the username and pass from the url to php<br>
&gt; &gt; &gt; backend<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; but nothing happens in nginx?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; let me explain<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; lets say you have a URL like this<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; <a href="http://userX:passY@example.com/bleh.php" target="_blank">http://userX:passY@example.com/bleh.php</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; i expect my php backend to have user and pass entries in the $_SERVER<br>
&gt; &gt; &gt; variable as happens with lighttpd<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; am i missing something with nginx? is it even possible?<br>
&gt; &gt;<br>
&gt; &gt; $echo userX:passY | perl -MMIME::Base64 -lne &#39;print encode_base64 $_&#39;<br>
&gt; &gt; dXNlclg6cGFzc1k=<br>
&gt; &gt;<br>
&gt; &gt;      proxy_pass <a href="http://example.com/bleh.php" target="_blank">http://example.com/bleh.php</a>;<br>
&gt; &gt;      proxy_set_header  Authorization &quot;Basic dXNlclg6cGFzc1k=&quot;;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Igor Sysoev<br>
&gt; &gt; <a href="http://sysoev.ru/en/" target="_blank">http://sysoev.ru/en/</a><br>
&gt; &gt;<br>
&gt; &gt;<br>
<br>
</div>--<br>
<div><div></div><div>Igor Sysoev<br>
<a href="http://sysoev.ru/en/" target="_blank">http://sysoev.ru/en/</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br>the sun shines for all<br>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>the sun shines for all<br>