[thelist] send HTTP authentication from PHP page?

Ken Schaefer ken.schaefer at gmail.com
Wed Oct 6 20:08:43 CDT 2004

On Wed, 06 Oct 2004 16:18:47 -0400, noah <noah at tookish.net> wrote:
> Theodore Serbinski wrote (06/10/2004 3:24 PM):
> 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?

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

> For example, if you have a password protected area of your site accessed
> via session-based authentication, there is no way of transparently
> linking to password-protected PDFs. You either have to put the PDFs in
> an unprotected directory, or you have to make the user re-enter his or
> her username and password. The latter appraoch is even more of a hassle
> when you consider that if you're dynamically adding and managing users
> you have to manage their username/password info in the authentication
> file as well as in the database.

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.

Given how HTTP authentication works (see my previous post in this
thread), how do you see application layer code somehow getting the
browser to authenticate transparently (using HTTP authentication) for
a resource when requests for every other resource, as far as the
browser is concerned, have been completely anonymous? I mean, you've
manually created some kind of mapping between Windows user accounts
and your custom, session-based, authentication system but the
*browser* is completely unaware of this.

--ASP Pages-- ( <- custom auth here )
--ASP Engine--      --Static Pages--
       |                            |  ( <- Windows auth here )
----------------- IIS --------------------------
            -- Browser --

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.

Now, there are ways around this. The IIS6 SDK includes something
called "customAuth", which, IIRC, is used by Exchange 2003 OWA. It's
implemented as an ISAPI filter than can intercept incoming HTTP
requests, and converts HTML based form input into HTTP based
authentication by modifying the incoming HTTP request headers. This
sits at the "IIS" level, so it's a way of intercepting all incoming
requests (for ASP pages, or Static files) and enforcing a common
authentication system.

Another way would be to have /all/ requests routed through the ASP
engine, and through your custom authentication system (as mentioned by
others). You can use an ASP page to authenticate the user, then use
the ADODB.Stream object to read data off the hard disk, and
Response.BinaryWrite() that data to the client.

If you're using ASP.NET there are other ways as well. I suppose you
could set PDF files to be handled by ASP.NET, and use a HTTPHandler to
handle all requests for PDF files. This would implement your
authentication/authorization code, and then stream the requested PDF
file if the user was authorised. Or you could use a HTTPModule as

There are lots of options available *but* you need to have a solid
grasp of what's actually occuring, and the limitations of what you're
dealing with.


More information about the thelist mailing list