Menu
▾
▴
nms-cgi-devel
|
From: Dave C. <da...@da...> - 2001-11-13 10:58:12
|
From: Jonathan Stowe <gel...@ge...> Date: 11/13/01 8:31:22 AM >On Mon, 12 Nov 2001, Dave Cross wrote: > >> Hey look, we have people on the list. Thanks for >> joining :) >> >> Some things that need doing: >> >> 1/ Test, test, test. On as many platforms as possible. >> > > Maybe we ought to get a Tripod or Virtual Avenue account - > as this is likely to be very much the environment most of > the user base will be in - besides we won't mind so much > if the site gets r00ted ;-} Good idea. >> 2/ Document, document, document. Currently the scripts >> have READMEs that are very closely (in some cases, _too_ >> closely) modelled on Matt's. Better docs are important. > > We probably want to come up with a boilerplate to do with > the general configuration and troubleshooting of CGI > programs. We shouldnt worry too much about not > reinventing stuff that can be found elsewhere because it > is unlikely that the target audience are going to find > the stuff in the first place - give them enough to stop > them from becoming guest of honour at a flamewar on > comp.lang.perl.misc. Yep. I'd love it if we had a really simple guide to installing CGI scripts included with every nms tarball. We should assume no knowledge at all on the part of the users. >> 3/ Peer review. Most of the code was written by me in >> the course of a ten hour hackfest one weekend. It can no >> doubt be improved. I'd love suggestions. > > In the first instance I have taken the duplicated code > out of some of the files (it looks like you may have > done ':r' in vi twice :) Hmm... unlikely as I'm an emacs user :) Don't where that came from. > and added CGI::Carp in those places where the script > might die() this will at least produce something > moderately less confusing than a plain 500 in the event > of failure I don't like this idea. I think that web servers give vanilla 500 errors for a good reason. The more information a user gets from an error message then the more information they have about the workings of the script and the more chance they have of cracking the site. I'm happy to have CGI::Carp included in the scripts and used for development and debugging - but I'd like it commented out of anything checked into CVS. > - I think in the long term it would be best to come up > with a slightly different and more configurable strategy > that can be used consistently across the programs. Agreed. > I think something that we ought to be looking at in the > programs is introducing better ways of doing things - it > is not absolutely necessary that we emulate the original > programs down to the strange methods of storage (for > instance) if they are being deployed in a green field site > that has not yet been tainted with Matt's scripts. But don't forget, that we are supposed to be creating _drop-in_ replacements for MSA. I see a lot our users being people who have Matt's scripts in place who want to move to something "better" (for some meaning of the word). It's therefore important that we can deal with all of Matt's baroque interface ideas. > You will for instance see in 'ffa.pl' the variable > $emulate_matts_ffa : although not completely implemented > yet when this is switched off the program will store its > data in a flat file and generate the HTML page on the fly > rather than updating the HTML page directly as it does > now. The guestbook and wwwboard should have this option > as well although we do have to retain compatibility with > Matt's peculiar storage mechanisms if we are to hope to > encourage to upgrade to our programs :) I thought I had > started doing this with the guestbook but I can't find > the code anywhere :( Agreed. Maybe rename the variable to $emulate_matts_code and use the same one in all scripts. The default should, of course, be on. >> 4/ Comments. At last week's london.pm meeting, it was >> suggested to me that a higher than usual level of >> comments might be a good idea - given the number of >> people that learned Perl from MSA. > > I've started on that with FFA - elucidating in some > detail what the configurable bits mean. Great. I'll take a look at those later. > I would consider it moot whether we should start > introducing a quantity of tutorial material into the > code - perhaps we could provide an annotated set of > source as part of the project documentation (actually > this might be a valuable project in its own right). Damn right. Actually, I'm considering writing it all up into something that might just become a replacement for Matt Wright's excreable book :) [snip stuff about IIS fuckwittage] Thanks for the detail. That's something that needs to make it into the docs. Probably a FAQ. > Oh yeah by the time you read this I will have tinkered > with the CVS so that you can check out the whole thing > with 'co NMS' - this does mean that you will need to edit > CVSROOT/modules if you add a new module - that'll be > man 5 cvs to you ;-} Cool. Thanks. Dave... -- <http://www.dave.org.uk> "Let me see you make decisions, without your television" - Depeche Mode (Stripped) |
|
From: Jonathan S. <gel...@ge...> - 2001-11-13 20:36:36
|
On Tue, 13 Nov 2001, Dave Cross wrote:
> From: Jonathan Stowe <gel...@ge...>
>
> > and added CGI::Carp in those places where the script
> > might die() this will at least produce something
> > moderately less confusing than a plain 500 in the event
> > of failure
>
> I don't like this idea. I think that web servers give vanilla
> 500 errors for a good reason. The more information a user gets
> from an error message then the more information they have about
> the workings of the script and the more chance they have of cracking
> the site.
>
> I'm happy to have CGI::Carp included in the scripts and used
> for development and debugging - but I'd like it commented out
> of anything checked into CVS.
>
I've got a better idea:
use CGI::Carp qw(fatalsToBrowser set_message);
use vars qw($DEBUGGING);
BEGIN
{
$DEBUGGING = 1;
$error_handler = sub
{
my ($mesg) = @_;
print "text/html\n\n";
print "<strong>Something nasty happened</strong>";
print "Perl said : $message" if $DEBUGGING;
}
set_message($error_handler);
}
I'm not sure when that feature came about :)
Then you get the best of both worlds :) It has to be borne in mind that
someone installing the application and configuring it is likely to find
themselves debugging their install environment - it would be nice to be
able to tell them to just alter the $DEBUGGING variable to display
suitable diagnostics - not that I'm subscribed to the support list ;-}
> > - I think in the long term it would be best to come up
> > with a slightly different and more configurable strategy
> > that can be used consistently across the programs.
>
> Agreed.
>
With the above we can postpone that awhile although someone might want to
look at making some standard niceness we can use across the whole , er,
suite ;-}
> > I think something that we ought to be looking at in the
> > programs is introducing better ways of doing things - it
> > is not absolutely necessary that we emulate the original
> > programs down to the strange methods of storage (for
> > instance) if they are being deployed in a green field site
> > that has not yet been tainted with Matt's scripts.
>
> But don't forget, that we are supposed to be creating _drop-in_
> replacements for MSA. I see a lot our users being people who
> have Matt's scripts in place who want to move to something "better"
> (for some meaning of the word). It's therefore important that
> we can deal with all of Matt's baroque interface ideas.
>
You started typing that before you finished reading the (albeit overlong)
sentence didn't you :)
> > You will for instance see in 'ffa.pl' the variable
> > $emulate_matts_ffa : although not completely implemented
> > yet when this is switched off the program will store its
> > data in a flat file and generate the HTML page on the fly
> > rather than updating the HTML page directly as it does
> > now. The guestbook and wwwboard should have this option
> > as well although we do have to retain compatibility with
> > Matt's peculiar storage mechanisms if we are to hope to
> > encourage to upgrade to our programs :) I thought I had
> > started doing this with the guestbook but I can't find
> > the code anywhere :(
>
> Agreed. Maybe rename the variable to $emulate_matts_code and
> use the same one in all scripts. The default should, of course,
> be on.
>
done.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Dave C. <da...@da...> - 2001-11-13 21:13:33
|
On Tue, Nov 13, 2001 at 07:15:15PM +0000, Jonathan Stowe (gel...@ge...) wrote:
[on CGI::Carp]
> I've got a better idea:
>
> use CGI::Carp qw(fatalsToBrowser set_message);
>
> use vars qw($DEBUGGING);
>
> BEGIN
> {
> $DEBUGGING = 1;
>
> $error_handler = sub
> {
> my ($mesg) = @_;
> print "text/html\n\n";
> print "<strong>Something nasty happened</strong>";
>
> print "Perl said : $message" if $DEBUGGING;
> }
>
> set_message($error_handler);
> }
>
> I'm not sure when that feature came about :)
This is important to know. I've made the (arbitrary) decision that nms
scripts should work under standard Perl 5.004_04. If we insist on anything
later we'll alienate a large part of our potential audience. I still run
web sites on hosted servers that run 5.004_04!
> Then you get the best of both worlds :) It has to be borne in mind that
> someone installing the application and configuring it is likely to find
> themselves debugging their install environment - it would be nice to be
> able to tell them to just alter the $DEBUGGING variable to display
> suitable diagnostics - not that I'm subscribed to the support list ;-}
I certainly like this way of doing things. If it works under our target
version then I'll be more than happy to use it.
I'll see if I can find out which version of CGI and CGI::Carp shipped with
Perl 5.004_04.
Dave...
--
Don't dream it... be it
|
|
From: Jonathan S. <gel...@ge...> - 2001-11-13 21:22:53
|
On Tue, 13 Nov 2001, Dave Cross wrote: > > I certainly like this way of doing things. If it works under our target > version then I'll be more than happy to use it. > I altered all the programs to use it anyhow as I got bored on the train :) I'll take it out or think of an alternative if it transpires that its a no go - it's not all that much code in Carp.pm anyhow - we could implement it in our own code if necessary. /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: ryan.311 <rya...@os...> - 2001-11-14 01:05:20
|
Hey guys, sorry I haven't been responding in a while; I've been busy.
Anyways, here are some thoughts:
>You also changed the shebang line to #!perl -wT. We need to agree on a
>standard for shebang lines, but it'll probably be #!/usr/bin/perl -wT
Well, I was under NT when I was running it... I changed it when I uploaded
it this time. Apologies!
>I don't agree with having use CGI::Carpi qw(fatalsToBrowser) in production
>code. It gives too much information to anyone trying to crack the site. The
>standard CGI error message is vague for a good reason. The full error
>messsage is written to the server error log where the webmaster can read
>it. By all means add it to the code - but comment it out in released
>versions.
I thought Jonathan's idea of using CGI::Carp's set_message function was an
excellent idea.
However, the code snippet he provided didn't work ;) I changed it to this:
BEGIN{set_message(sub{print"[Error]"})if!$DEBUGGING;}
That will output "[Error]" whenever there is an error in the script when
$DEBUGGING is set to 0.
However, if there is an error earlier in the BEGIN statement, CGI::Carp
will output errors regardless
of what $DEBUGGING is set to.
In addition, I added all of the "config" variables to global variable
declarations and placed them
inside the begin. $DEBUGGING needed to be a pre-declared value in order
for set_message
to work correctly; and I figured that all of the "config" variables should
be placed together to
prevent confusion.
>Maybe we should have used the query_string functixpno from CGI.pm as that
>probably does the URL unencoding.
Hmmm... I couldn't find that function in the pod.
Are you talking about unescape() in CGI::Util?
Good idea, I'll put that in.
>Otherwise, we _can't_ change the format of the parameters as this script is
>supposed to work exactly the same way as Matt's. Users are supposed to be
>able to copy our version on top and Matt's and it'll work straight off. If
>you change the format, then that's not going to happen. I agree that your
>format makes far more sense, but because of the rules of nms, we're stuck
>with Matt's format.
Ugh... Fine. I added support for both ways, however:
my @query_string = split(/,/, length param("date") > 0 ? param("date") :
unescape($ENV{QUERY_STRING}));
@from_date = @query_string if(@query_string == 6);
This will let you use either countdown.pl?2002,9,7,0,0,0 or
countdown.pl?date=2002,9,7,0,0,0.
>> 4. I removed the start_html and end_html, big bold headers, etc. A script
>> like this will most likely be used via SSI, so it makes sense
>> to only output what is needed. Let the designer decide the output format :)
>
>Another good idea, but again we're stuck with Matt's definition of the
>output. What would be good would be to have a simple template stored in the
>__DATA__ filehandle. The default would need to be Matt's version, but it
>would be easy to edit to something else.
I don't thing it really matters whether the start_html, etc. are not
included; however, it does make a difference
if they are. If the script is used as stand-alone, the page will still
display despite lack of head information; however,
html head information in the middle of the document is NOT a good idea. If
the end user wants big boldness, then
they can wrap the SSI in <h1> tags. Lets not make the same mistake Matt
did. :)
Also, some extra notes:
First of all, the version of CGI::Carp that we need is 1.09, according to
its pod. However, I am not sure what version first became start of the
standard distribution.
Secondly, I am not sure how to upload on sourceforge. For the time being,
I re-uploaded to jcwren's server (http://jryan.perlmonk.org/nms/countdown.txt).
Thirdly, I have two midterms coming up over the next two days, so my time
for NMS will be limited until my midterms are over. I should be able to
thoroughly look over another script during that time, however, so
suggestions for the next script to pick apart are welcome.
Forthly (to Dave): My last name is Ryan, not my first. Call me Joe please :)
|
|
From: Jonathan S. <gel...@ge...> - 2001-11-14 20:30:55
|
On Tue, 13 Nov 2001, ryan.311 wrote:
> Hey guys, sorry I haven't been responding in a while; I've been busy.
> Anyways, here are some thoughts:
>
> >You also changed the shebang line to #!perl -wT. We need to agree on a
> >standard for shebang lines, but it'll probably be #!/usr/bin/perl -wT
>
> Well, I was under NT when I was running it... I changed it when I uploaded
> it this time. Apologies!
>
You don't need to change the Shebang for IIS - of course you might do if
you are running these with Apache on windows which fakes up the Unix
execvp behaviour but uses the path.
I am going to do up the FAQ about running this stuff nicely on Windows - I
am having an enforced refamilarisation with it right now :)
>
> >I don't agree with having use CGI::Carpi qw(fatalsToBrowser) in production
> >code. It gives too much information to anyone trying to crack the site. The
> >standard CGI error message is vague for a good reason. The full error
> >messsage is written to the server error log where the webmaster can read
> >it. By all means add it to the code - but comment it out in released
> >versions.
>
> I thought Jonathan's idea of using CGI::Carp's set_message function was an
> excellent idea.
> However, the code snippet he provided didn't work ;) I changed it to this:
>
> BEGIN{set_message(sub{print"[Error]"})if!$DEBUGGING;}
>
Bloody did! ;-}
I have tested this code:
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser set_message);
use vars qw($DEBUGGING);
#
# $DEBUGGING must be set in a BEGIN block in order to have it be set before
# the program is fully compiled.
# This should almost certainly be set to 0 when the program is 'live'
#
BEGIN
{
$DEBUGGING = 0;
}
BEGIN
{
my $error_message = sub {
my ($message ) = @_;
print "<h1>It's all gone horribly wrong</h1>";
print $message if $DEBUGGING;
};
set_message($error_message);
}
die "Wahay!\n";
Which is the boilerplate for what I have placed in all the programs and
some stuff to make it work and it works fine for me with perl 5.6.1.
It might be that some construct I am using doesnt extend back all the way
to 5.004.04 here but the only diff I can see between what you are doing
and I am doing is the anonymous subroutine and I can't believe that that
hasnt been around since we we have had references (in 5.001m ?)
This code is basically shorthand for a larger nicer error message that is
fit to be presented to the punters - I am waiting for someone who can be
arsed with making nice HTML to do that.
Obviously if one was in control of the server itself one would configure
it so that the '500' status page was nice enough that you could just let
programs die.
> That will output "[Error]" whenever there is an error in the script when
> $DEBUGGING is set to 0.
> However, if there is an error earlier in the BEGIN statement, CGI::Carp
> will output errors regardless
> of what $DEBUGGING is set to.
>
Well yes, there is almost certainly nothing we could do to prevent error
leakage at some point - we just need to endeavour to reduce the
possibility of that ... unfortunately the configuration of the server is
going to cause the program to fail before compilation. Thats the shit ;-}
<snip>
>
> Ugh... Fine. I added support for both ways, however:
>
Er.. I'll start a new thread ;-}
>
> Secondly, I am not sure how to upload on sourceforge. For the time being,
> I re-uploaded to jcwren's server (http://jryan.perlmonk.org/nms/countdown.txt).
>
You need to be able to access the CVS - we can discuss working with CVS if
you are unfamiliar with this.
> Thirdly, I have two midterms coming up over the next two days, so my time
> for NMS will be limited until my midterms are over. I should be able to
> thoroughly look over another script during that time, however, so
> suggestions for the next script to pick apart are welcome.
>
Hey, I have to give annual reviews to two of my little helpers and ensure
that the four projects we are working on are on track, integrate two
billing systems that exist in our German operation and propose the
architecture for the european rollout of two software systems ;-}
And that is this week ;-}
This is volunteer stuff matey don't worry ...
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Joseph F. R. <rya...@os...> - 2001-11-14 22:14:33
|
Hi. In response to Jonathan:
>You don't need to change the Shebang for IIS - of course you might do if
>you are running these with Apache on windows which fakes up the Unix
>execvp behaviour but uses the path.
Yeah, I was running Apache under windoze (I am on that boot a lot of the
time because I am a Starcraft addict ;)
>Bloody did! ;-}
>
>I have tested this code:
>
>#!/usr/bin/perl -w
>
>use strict;
>
>use CGI;
>use CGI::Carp qw(fatalsToBrowser set_message);
>use vars qw($DEBUGGING);
>
>#
># $DEBUGGING must be set in a BEGIN block in order to have it be set before
># the program is fully compiled.
># This should almost certainly be set to 0 when the program is 'live'
>#
>
>BEGIN
>{
> $DEBUGGING = 0;
>}
>
>BEGIN
>{
> my $error_message = sub {
> my ($message ) = @_;
> print "<h1>It's all gone horribly wrong</h1>";
> print $message if $DEBUGGING;
> };
>
> set_message($error_message);
>}
>
>
>die "Wahay!\n";
Hehe, that wasn't what you sent :)
Here is what I got:
>use CGI::Carp qw(fatalsToBrowser set_message);
>use vars qw($DEBUGGING);
>BEGIN
>{
>$DEBUGGING = 1;
>$error_handler = sub
>{
>my ($mesg) = @_;
>print "text/html\n\n";
>print "<strong>Something nasty happened</strong>";
>print "Perl said : $message" if $DEBUGGING;
>}
>set_message($error_handler);
>}
That has a few syntax errors in it, these two lines most blatently:
my ($mesg) = @_; # should be: my $message = shift; since you used $message
later on :)
print "text/html\n\n"; #forgot Content-type:! iti sn't even needed, however...
No worries, at any rate. :) I have a better idea (2 of em actually):
1:
----------
BEGIN {
# **** Configuration ****
# @from_date = (yyyy,mm,dd,hh,mm,ss);
# Which means: (year,month,day,hour,minute,second)
@from_date = (2002,9,7,0,0,0); # the default date to find the difference from
$delimiter = " "; # what gets printed between output.
$DEBUGGING = 1; # set to 1 to turn on debugging mode, 0 to
turn it off (recommended)
# **** End configuration ****
eval ("use CGI::Carp qw(fatalsToBrowser)") if $DEBUGGING;
----------
This would load CGI::Carp only on demand; The user gets a standard 500
error if debugging is turned off, and fatalsToBrowser if not. However,
this still suffers from the same problem as before; if there is an error in
the config, the standard 500 error gets shoved out. This, however, does not:
2:
----------
use CGI::Carp qw(fatalsToBrowser set_message);
BEGIN {set_message(sub{print"[Error in Script Setup Config]"})}
BEGIN {
# **** Configuration ****
# @from_date = (yyyy,mm,dd,hh,mm,ss);
# Which means: (year,month,day,hour,minute,second)
@from_date = (2002,9,7,0,0,0); # the default date to find the difference from
$delimiter = " "; # what gets printed between output.
$DEBUGGING = 1; # set to 1 to turn on debugging mode, 0 to
turn it off (recommended)
# **** End configuration ****
set_message(sub{print"[Error]"})if!$DEBUGGING;
set_message("")if$DEBUGGING;
}
----------
This will not only handle errors in the config section, but allow us to
state that the error is specifically in the startup section. However, it
suffers from the drawback of not using the standard 500 error. <babble
type="mindless">Perhaps we could pipe in the error message from a dummy
script through a system call and then... *inane babble continues*</babble>
>This code is basically shorthand for a larger nicer error message that is
>fit to be presented to the punters - I am waiting for someone who can be
>arsed with making nice HTML to do that.
Hey, I was primarily a web designer for about 6 years before moving on to
grander things. What exact did you have in mind? I'm not half bad, if I do
say so myself!
>You need to be able to access the CVS - we can discuss working with CVS if
>you are unfamiliar with this.
Yeah, I haven't the slightest clue what CVS is, other than an overpriced
drug store chain. I would be greatful if you were to enlighten me :)
In response to Dave:
>Note that I've added parens around the lists. This solves the problem
>quite well. The script needs some other changes so that it doesn't cause
>so many warnings when values aren't initialised, but that's an exercise
>for the reader?
>So, um, does someone want to make the appropriate changes to the CVS
>version and announce a bug fix to Wayne?
Yeah, I'll start on that tonight (plus give it a good fixen) after my calc
midterm. Speaking of that... I am running a bit late, gotta go :)
|
|
From: ryan.311 <rya...@os...> - 2001-11-14 01:29:47
|
A quick fix:
>Ugh... Fine. I added support for both ways, however:
>
>my @query_string = split(/,/, length param("date") > 0 ? param("date") :
>unescape($ENV{QUERY_STRING}));
>@from_date = @query_string if(@query_string == 6);
>
>This will let you use either countdown.pl?2002,9,7,0,0,0 or
>countdown.pl?date=2002,9,7,0,0,0.
Wog from perlmonks informed me that calling param("keywords") will return
2002,9,7,0,0,0 when the query string is countdown.pl?2002,9,7,0,0,0. So
that makes the code:
my @query_string = split(/,/, length param("date") > 0 ? param("date") :
param("keywords"));
@from_date = @query_string if(@query_string == 6);
|
|
From: Jonathan S. <gel...@ge...> - 2001-11-14 09:10:23
|
On Tue, 13 Nov 2001, Dave Cross wrote: > > I'll see if I can find out which version of CGI and CGI::Carp shipped with > Perl 5.004_04. > According to the Changes5.004 in the Perl distribution the version of CGI.pm was 2.32 and it was added in 5.003_96, the set_message(CODEREF) feature was added in version 1.09 of CGI::Carp and the current version is 1.20 which appears not have been changed since 1998 - empirically I would say we are safe but someone might want to check it on a machine with 5.00404. /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X