Take a look at: ftp://ftp.isi.edu/in-notes/rfc2617.txt To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials. basic-credentials = base64-user-pass base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char/line> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT Userids might be case sensitive. If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See section 4 for security considerations associated with Basic authentication. In article <[EMAIL PROTECTED]> you write: >Authentication Question... > >My company subscribes to several pay-to-view e-commerce sites that >require >htaccess-type authentication. To keep things simple for our users and >to >ensure that our users don't use these accounts w/out our permission, we >would >like to keep the account IDs and passwords from the user's direct view. >A >simple but not entirely effective solution is to include the id/password >in the >URL... > > http://user:[EMAIL PROTECTED]/index.html > >The problem with the above-noted method is that the account ID and >password >are clearly visible. What I would rather do is point the users at a PHP > >script that then redirects them to the correct site with authentication >already handled. I can easily handle the redirect using... > > header("Location: ... ") > >What I haven't figured out is how to include the authentication in the >redirect. I understand how to use base64_encode() to encode the >ID:password string. What I can't figure out is how to pass this info >along with >the redirect. Any thoughts on if/how this could be accomplished? > >For the record, I tried a different approach where I used fsockopen(), >fputs(), and fpassthru() to successfully connect/authenticate and >receive >the HTML stream. This will actually display the results (messy). The >problem with this approach is that the links on the page are all broken >as the user's browser is still pointing at the local web server. > >In a nutshell, how can I redirect a web client to a remote site and >include >the authentication info as part of the redirect. > >Thanks, > >Stan > > > >-- >PHP General Mailing List (http://www.php.net/) >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PROTECTED] > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
