You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Randal L. Schwartz" <me...@stonehenge.com> on 2003/05/19 15:23:26 UTC
hiding the technology behind static URLs
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
<me...@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
Re: hiding the technology behind static URLs
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Randal" == Randal L Schwartz <me...@stonehenge.com> writes:
Randal> I have a client who is making the jump from "everything is
Randal> Perl-mod_cgi" to various combinations of Apache::Template and
Randal> Apache::Registry.
Sorry... Posted to dev by mistake. I resent this to the main list.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@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
Re: hiding the technology behind static URLs
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Perrin" == Perrin Harkins <pe...@elem.com> writes:
Perrin> On Tue, 2003-05-20 at 15:11, Randal L. Schwartz wrote:
>> There's a political battle at this organization to minimize the number
>> of changes to "the config files". So, once they get a basic setup
>> working, all they'll be able to do afterward is add more files into
>> various places, or move things around. No more config changes.
Perrin> The problem with that attitude is that changing URL is bad. It breaks
Perrin> bookmarks, search engines, etc.
Uh, hence the title of the message that started this thread. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@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!
Re: hiding the technology behind static URLs
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2003-05-20 at 15:11, Randal L. Schwartz wrote:
> There's a political battle at this organization to minimize the number
> of changes to "the config files". So, once they get a basic setup
> working, all they'll be able to do afterward is add more files into
> various places, or move things around. No more config changes.
The problem with that attitude is that changing URL is bad. It breaks
bookmarks, search engines, etc.
You could try doing something with an access handler that checks its own
config file to see what is protected, but that's certainly more work
than either moving files or changing httpd.conf.
- Perrin
Re: hiding the technology behind static URLs
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Perrin" == Perrin Harkins <pe...@elem.com> writes:
Your other points are interesting, but I wanted to respond to this:
Perrin> I wouldn't put /pw/ in the URLs, unless there is no other way to
Perrin> organize things that allows the protected content to be identified. An
Perrin> access handler can be attached to any directory or URI, so technically
Perrin> it is not necessary to put all protected content in one place.
There's a political battle at this organization to minimize the number
of changes to "the config files". So, once they get a basic setup
working, all they'll be able to do afterward is add more files into
various places, or move things around. No more config changes. Yes,
it seems a bit crazy, and I've been working hard this week to convince
the admins that these kind of config changes are integral to deploying
a new application, but I'm having only limited success.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@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!
Re: hiding the technology behind static URLs
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2003-05-20 at 04:31, Aaron Trevena wrote:
> Any progress on this ? I haven't seen any responses on the modperl users
> list.
I replied, but I think it was on another list. Here it is, for
reference:
On Mon, 2003-05-19 at 09:23, Randal L. Schwartz wrote:
> 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 ...
I wouldn't put /pw/ in the URLs, unless there is no other way to
organize things that allows the protected content to be identified. An
access handler can be attached to any directory or URI, so technically
it is not necessary to put all protected content in one place.
> 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
We had a lot of pages at eToys that used static-looking URLs. The
approach we used was to map directories to different handlers (you can
do this with Registry by setting up a script to be the index for a
directory or using a transhandler to map to a script), and then let the
handler decide which template it wants based on path_info. Typically a
URL would look something like this:
/my/app/12345/
The 12345 part would be an ID to the resource we want to display, and
the application would use that to figure out which template to grab.
For example, the app might look up a product based on this ID, find that
it's a book, and pull the name of the book template file from the app's
configuration.
> Also, should I return DECLINED?
Yes.
> And /appname/$unique_value might not be enough for the entire app.
> What if I need to add subdirs for this?
Why wouldn't you use the whole URI?
- Perrin
Re: hiding the technology behind static URLs
Posted by Aaron Trevena <aa...@tuskerdirect.com>.
Hi Merlyn,
Any progress on this ? I haven't seen any responses on the modperl users
list.
I have been looking at something similar for a smaller application space
(probably about 5 handlers/scripts front end, another 10 backend) and
would be interested in the best approach.
something like :
https://hostname/backend/ [$authtoken](login | taska | taskb | etc )
http://hostname/ (foo | bar | baz ) /[$sessiontoken/][$requiredinfo/][$key/]
My approach initially would be to use only values that are absolutely
required by the handler - the kind of thing that changes its behaviour
entirely like mode/action, session tokens, and possibly a required
record key.
All other information would be passed as normal cgi params either with a
get (afixing the url with ?param=value) or post - I much prefer to have
a url point at something with the basic information to either return the
right page or give you a page that links to the right page with
optional values posted with a form than a nasty mix of params in the url
and posted.
cheers,
A.
Re: hiding the technology behind static URLs
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-05-19 at 09:23, Randal L. Schwartz wrote:
> 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 ...
I wouldn't put /pw/ in the URLs, unless there is no other way to
organize things that allows the protected content to be identified. An
access handler can be attached to any directory or URI, so technically
it is not necessary to put all protected content in one place.
> 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
We had a lot of pages at eToys that used static-looking URLs. The
approach we used was to map directories to different handlers (you can
do this with Registry by setting up a script to be the index for a
directory or using a transhandler to map to a script), and then let the
handler decide which template it wants based on path_info. Typically a
URL would look something like this:
/my/app/12345/
The 12345 part would be an ID to the resource we want to display, and
the application would use that to figure out which template to grab.
For example, the app might look up a product based on this ID, find that
it's a book, and pull the name of the book template file from the app's
configuration.
> Also, should I return DECLINED?
Yes.
> And /appname/$unique_value might not be enough for the entire app.
> What if I need to add subdirs for this?
Why wouldn't you use the whole URI?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org