[thelist] send HTTP authentication from PHP page?

noah noah at tookish.net
Wed Oct 6 20:57:44 CDT 2004

Ken Schaefer wrote (06/10/2004 9:08 PM):
> On Wed, 06 Oct 2004 16:18:47 -0400, noah <noah at tookish.net> wrote:
>>It's frustrating that Microsoft, rather than fixing the security problem
>>that made this sort of URL potentially dangerous, just disabled it
> Well, it was never RFC compliant, so I suppose there was no reason why
> it /had/ to be there. Perhaps the cost of fixing the problem properly
> would have been too prohibitive?

Microsoft obviously has the right to do whatever they want with their 
product, and since it's the most widely used browser in the world, if 
they choose to do something that breaks my site that's clearly my 
problem. However, since every other major browser maker has managed to 
deal with this without removing the functionality, I don't think it's 
unreasonable for me to wish that Microsoft had too.

>>It's something that I've run into a number of times.
> Actually, what you have described below appears to be completely
> /unrelated/ to what you are talking about above, so I don't understand
> the "number of times" comment.

I don't see why it's unrelated. The original poster wanted to provide 
HTTP authentication information from PHP. I have wanted to do the same 
thing on several occasions. I used to be able to do it by embedding the 
username and password in the URL. Now I can't do that.

> Well, HTTP authentication is implemented between browser and
> webserver, and your session based authentication mechanism (whether
> this is ASP, Cold Fusion or whatever) is implemented in your
> application layer code.
> . . .
> Your custom authentication system is implemented in the "ASP Pages"
> level above, but requests for static pages (like PDF files) are never
> routed to that branch of the tree - requests come in from the browser,
> go through the IIS level, and then get routed to "Static Pages". I am
> unsure how a link from a ASP page that contains some custom
> authentication system is supposed to influence the browser's behaviour
> when it goes through a different branch of the tree.

I don't know enough about this stuff actually works, and I do appreciate 
your explanation. As for influencing the browser's behaviour with a 
custom authentication system, that was trivial up until something like 
eight months ago:

<a href="http://username:password@www.example.com/protected/foo.pdf">

Where "username" and "password" are provided by the custom 
authentication system, and the "protected" directory requires 
authentication. That worked, and continues to work in every browser 
except IE/Win. It would obviously be madness to protect truly sensitive 
data this way, but there's still a use for this sort of thing.

As to whether Microsoft was right or wrong to remove this functionality, 
it's not my place to decide. If it was never RFC compliant, then there 
certainly is a valid argument that there's nothing wrong with removing it.


More information about the thelist mailing list