Brat Wizard wrote:
>
> So basically you're saying create a directory on my system
>
> /usr/lib/<wherever perl goes>/Apache/ASP/Share/Wizard
>
> and put my modules (*.pm) in there...
>
Only if you wanted to share them with others. You
could start developing them with
use lib qw(some_dir);
use Apache::ASP::Share::Wizard;
Then you would create the directory structure
of some_dir/Apache/ASP/Share/ and drop in Wizard.pm
Then when it some time to create your own CPAN distribution,
its all ready to go.
> Then I could:
>
> use Apache::ASP::Share::Wizard::MyModule;
>
Right, create some_dir/Apache/ASP/Share/Wizared
and drop MyModule into it too.
>
> I have tons of '#' comments sprinkled throughout my code but never got in the
> habit of doing the perldoc way. Perhaps now is a good time to get started.
> You may be doing me a back-handed favor ;)
>
From Mythical Man Month, making a bit of code well documented
a reusable can take 3x the time, so only do so if you feel
like its worth the effort. Its will pay off long term should
anyone else ever have to look at your code, and doing a CPAN
type distribution can make you a better developer besides,
especially with the peer review you can garner.
>>Did you know that in the body of an XMLSubs, you can do things
>>like <%= $Object->URL %> instead of the __URL__.
>
>
> Unless I misunderstand your meaning, I don't think that would do what I want
> in this instance since the __TOKENS__ are not being processed until they get
> inside the subroutine, and more to the point, the values of the tokens are
> undefined until given meaning (scoped into context) by the page-item
> iteration loop. Also, what you're suggesting takes place before the
> subroutine anyway... yes?
>
Right, that would not work then.
>
> If you REALLY REALLY wanted to do the world a favor (well, the asp community
> anyway)-- make up a nice set of methods to abstract/obscure db results
> paging. That is arguably one of the BIGGEST pain-in-the-ass chores there is
> as well as an oft-used construct. Surely there could be a better way. ;)
>
Right, mine too. I think others have tried to do this well,
but have no links for you on this at the moment.
>
> Is there any way to handle the "quotes-not-required" bit? (Probably not, but
> asking anyway ;)
>
For XMLSubs to evolve, I believe no unfortunately. XML attributes
need to be quoted, and I try to have them live up to their
name as well as possible.
> Its only a minor annoyance to me personally (and is always good for a santyx
> error when I go to run the code ;) But my real concern-- and none of the
> above really has anything to do with it, since use of the <% %> tags is the
> real issue-- is that if an end-user (someone who is allowed to make html
> pages using custom tags, etc) is really savvy and perceptive, they could
> fathom out some of the inner workings of the apache/perl engine and
> application environment and there is a potential security issue in all this.
>
Yes. There is nothing particularly dumbed down or secure about writing
ASP pages. For example, what would happen if a user did:
<% `rm -rf /`; %>
There is nothing in the system that will protect against this.
I have considered creating some tag that would NULL all <% %>
blocks in a page being parsed, and only allow for XMLSubs to
be used by an end user. I would only add this after 3.0
release at this point, and it could be used to secure XMLSubs
that are only interpolating arguments in <%= %>, not the 2.xx
XMLSubsPerlArgs type functionality.
> Since any legal perl code can be operated between <% %> tags, a
> suitably-mischievous person could potentially access, (ab)use, or hijack some
> portion of the system (that the apache server process has permissions for).
> If you (the programmer/webmaster) keep complete control over the pages you're
> safe, but you can't safely share it with a unknown (eg non-trusted) user, and
> this is a real shame because the potential for giving the end-user some
> really nifty items is there (as well as a mechanism for obscuring nasty or
> complex code/issues.
Generally, mod_perl is not secure for arbitrary users in a shared
hosting environment because the code is always run as the web server.
This will supposedly be changed in apache 2.0 when they add per user
per virtual host based process model. However, until then the most
secure you can run Apache::ASP is to use the asp-perl script to
run a script in CGI mode. Its slow, but it works, and you could
give your users the features, while keeping things secure with
per user CGI execution functionality.
> Now I have a question for you... ever since I first started programming ASP
> projects I have been trying to fathom how to use the "default module" that
> goes along with a project?? Its sorta seems like a dingleberry but I've
> always included it mostly out of habit but partly for not knowing better.
> Lately I've been looking through it with a more critical view and I just
> can't see how its relevant. It appears to be just setting up for some
> hypothetical module that might be created, perhaps to run CGI-ish code.
>
If you have an object that is your Application object, or Model in MVC,
then you can abstract things away from your views which are the ASP scripts.
The controller is Apache::ASP itself, plus whatever you add to
Script_OnStart that might affect how the script gets loaded, if at all!
This application object can then be used to centralize & streamline
code bits that occur all over your site. For example, instead of
having a register_user.inc include that you call at the right time,
you can do instead:
<% $App->register_user; %>
This $App object might be of class Wizard::App that other objects
subclass off of, and you might also be able to call it from nightly
running cron & other various back end business logic that have
nothing to do with ASP scripts.
Though in breaking of the MVC paradigm, I often also do nice little
view shorthands & place them in the app object for the web site like:
# global.asa
use vars qw($App); # declare global
sub Script_OnStart {
$App = Wizard::App::ASP->new(Request => $Request);
# $App->{form} get created below
}
# Wizard::App::ASP
@ISA = qw(Wizard::App);
package Wizard::App::ASP;
sub new {
my($class, %args) = @_;
$args{Request} || die("no Request object to new");
my $self = $class->SUPER::new(%args);
my $Request = $args{Request};
$self->{form} = $Request->Form;
$self->{query} = $Request->QueryString;
$self;
}
and so on. Then you can reference this kind of data
differently in your scripts like:
<%= $App->{form} %>
with the added advantage that the app object already
has the HTTP data available to it if you need it in
on of its methods. For something like register_user,
you might have a core App object that takes params:
package Wizard::App;
sub register_user {
my($self, %args) = @_;
...
}
& then in the ASP subclass, you can override it with
the right values:
sub register_user {
my $self = shift;
# error checking code on params
$self->SUPER::register_user(%{$self->{form}});
}
You don't need to init the object with the $Request->Form
data at Script_OnStart however, as you can always
reference it via $main::Request->form from any package.
> ex.
>
> #! /bin/perl
>
> package WIZORG;
> use File::Basename;
>
> sub new {
> my($request) = $main::Request;
> my($env) = $request->ServerVariables();
>
> my $basename = &File::Basename::basename($0);
> my($title) = join(': ', "WIZORG", $basename);
Well I like $App->{basename} defined already, but you
can just as easily do:
# global.asa
use File::Basename qw(basename);
# in script
<%= &basename($0) %>
>
> So... Is it safe to junk it or have I missed a core concept?
It really starts to help lift reusable code out of
your ASP scripts, into some central object, so you can
reuse it better in other places. Having a central
object can help you from having to define lots of
other globals to do your dirty work.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
