[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
>>altogether.
>
> 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.
Cheers,
--
Noah
More information about the thelist
mailing list