perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mer...@stonehenge.com (Randal L. Schwartz)
Subject hiding the technology behind static URLs
Date Mon, 19 May 2003 13:23:26 GMT

I have a client who is making the jump from "everything is Perl-mod_cgi"
to various combinations of Apache::Template and Apache::Registry.

Since they're starting afresh, they want to hide the implementing
technology from the user, both for security and for flexibility.  And,
to make it messier, some of the pages should be Auth-protected, while
others aren't, and that might change over time as well.

They've suggested to me a file structure that looks like:

        /pw/ - all password protected items
        /pw/cgi - mod_cgi (most existing things here)
        /pw/static - static html and images here
        /pw/registry - Apache::Registry (many CGI migrate here)
        /pw/template - Apache::Template (many HTML migrate to here)
        /public/ - same as above, no password
        /public/cgi/ - mod_cgi, no password
        /public/ ... etc ...

These directories would have the right <Directory> tags to trigger the
proper content handler and auth requirements.  The extension would
be used only to show the expected MIME return type, such as a public
static text file:

        server.example.edu/appname/foo.txt - /public/static/foo.txt

and a private Apache::Template'd HTML file:

        server.example.edu/appname/bar.html - /pw/template/bar.html

and so on.

I'm thinking of a PerlTransHandler that has either
(a) a search list with a cache per process (and maybe a timeout) or
(b) a huge static hash of THIS url maps to THAT resource

But I'm unclear on whether I would want $r->uri to update as a result
of this transhandler, or just $r->filename.

Also, should I return DECLINED?  Is it likely that I'd want no other
mod_'s trans handler to affect the filename or URI?  Especially if
there was an .htaccess somewhere deep... that might be a problem.

Regarding the search, the customer is familiar with Cache::FileCache,
and that's already been kicked around as a sharing solution.

And /appname/$unique_value might not be enough for the entire app.
What if I need to add subdirs for this?

So, has anyone else gone down this tunnel, and either backed away
slowly, or solved it?  What problems did you face?  What solutions did
you ultimately reject?  What examples can you feed me?

Just another guy trying hard not to reinvent the wheel needlessly...

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message