Menu
▾
▴
nms-cgi-devel
|
From: Nick C. <ni...@cl...> - 2002-01-27 15:24:37
|
On Sun, Jan 27, 2002 at 06:45:11AM -0800, Nick Cleaton wrote: > > > Modified Files: > FormMail.pl README > Log Message: > * re-wrote README done formmail, starting on guestbook. > * added @allow_mail_to config option I've added an alternative way to configure allowed email addresses - a list of email address and hosts. @recipients still works (so there's no compatibility issue) but I've documented it as depreciated and made it empty in the default config in the script. -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-02-02 23:26:48
|
On Sat, 2 Feb 2002, Nick Cleaton wrote: > > uid=68644(nickjc) gid=100(users) groups=100(users),40625(nms-cgi) > search search.pl,1.15,1.16 > Sat Feb 2 05:57:54 PST 2002 > Update of /cvsroot/nms-cgi/search > In directory usw-pr-cvs1:/tmp/cvs-serv10923 > > Modified Files: > search.pl > Log Message: > match the empty string as a valid directory name > But it's not a valid directory name is it ? Or rather I can't work out how to make one ...The worrying directories are things like '. ' and so forth however ;-} /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Joseph F. R. <rya...@os...> - 2002-02-06 09:16:09
|
I added some stuff to search.pl, all of it guarded by an $emulate_matts_code. First off, I added sorted results, sorted by hits. Next, I added a config variable that could let the user filter out 1 hit searches (the number is set by the user, the default limit is 1). Finally, I moved the html output functions to the end as they are the most likely candidates that a user will want to mess with. At 08:24 PM 2/4/2002 -0800, you wrote: >uid=68187(jfryan) gid=100(users) groups=100(users),40625(nms-cgi) >search search.pl,1.19,1.20 >Mon Feb 4 20:24:38 PST 2002 >Update of /cvsroot/nms-cgi/search >In directory usw-pr-cvs1:/tmp/cvs-serv23763 >Modified Files: >search.pl >Log Message: >Added $hit_threshhold config var and also moved output functions to end _______________________________________________ Nms-cgi-commits mailing list Nms...@li... https://lists.sourceforge.net/lists/listinfo/nms-cgi-commits |
|
From: Nick C. <ni...@cl...> - 2002-02-14 00:08:31
|
On Wed, Feb 13, 2002 at 03:36:46PM -0800, Nick Cleaton wrote: > > uid=68644(nickjc) gid=100(users) groups=100(users),40625(nms-cgi) > formmail FormMail.pl,1.35,1.36 > Wed Feb 13 15:36:46 PST 2002 > Update of /cvsroot/nms-cgi/formmail > In directory usw-pr-cvs1:/tmp/cvs-serv11480 > > Modified Files: > FormMail.pl > Log Message: > (This is the log message for the previous checkin) > * reworked check_email With so many different people (including me) adding clauses to the 'if' statement, it was getting too tangled. I've re-written check_email() from scratch, everyone please look and find the errors. Did you recently add to check_email ? If so, please check that what you blocked is still blocked. It no-longer allows SPAM relaying if $emulate_matts_code is set. It does allow pretty much anything that's at all like a real email address, so hopefully it will still be a drop-in replacement for 99% of users. > * made it produce debugging output when rejecting recipients Detailed reporting on rejected recipients if $DEBUGGING. That should help the remaining 1% track down any issues. > * sort order: doc correction Someone pointed this out on the list a few weeks ago, and I though it had been fixed, but it hadn't. > * doc typo > * added a way to keep the email address out of the form (user request) > * POST_MAX and DISABLE_UPLOADS stuff > * restricted the body attribute inputs to sane values > * squished a couple of warnings > * allowed relative URLs in check_url_valid -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-02-25 21:55:42
|
On Mon, 25 Feb 2002, Nick Cleaton wrote: > > uid=68644(nickjc) gid=100(users) groups=100(users),40625(nms-cgi) > tests - Imported sources > Mon Feb 25 13:21:08 PST 2002 > Update of /cvsroot/nms-cgi/tests > In directory usw-pr-cvs1:/tmp/cvs-serv3252 > > Log Message: > Importing automated test set > Nick++ - let's test baby ;-} /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Olivier D. <dr...@sh...> - 2002-03-02 20:56:55
|
While you're at it, would you mind adding $CGI::DISABLE_UPLOADS=1 $CGI::POST_MAX=1024*20 # 20k (enough?) max posts ? Thanks! -Olivier On Sat, Mar 02, 2002 at 12:48:00PM -0800, Jonathan Stowe wrote: > > uid=68026(gellyfish) gid=100(users) groups=100(users),7054(xmlxslt),40625(nms-cgi) > wwwboard README,1.6,1.7 wwwboard.pl,1.18,1.19 > Sat Mar 2 12:48:00 PST 2002 > Update of /cvsroot/nms-cgi/wwwboard > In directory usw-pr-cvs1:/tmp/cvs-serv16887 > > Modified Files: > README wwwboard.pl > Log Message: > * Added $max_followups configuration to prevent message bomb attack > > > _______________________________________________ > Nms-cgi-commits mailing list > Nms...@li... > https://lists.sourceforge.net/lists/listinfo/nms-cgi-commits -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Jonathan S. <gel...@ge...> - 2002-03-02 21:05:10
|
On Sat, 2 Mar 2002, Olivier Dragon wrote: > While you're at it, would you mind adding > > $CGI::DISABLE_UPLOADS=1 > $CGI::POST_MAX=1024*20 # 20k (enough?) max posts > D'oh! I had actually meant to do that but got distracted. Thinking about it should be calculated by the sum of values %max_len + some universal constant ... I'll have a look ... thanks. /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Nick C. <ni...@cl...> - 2002-03-26 21:52:29
|
On Tue, Mar 26, 2002 at 01:45:09PM -0800, Nick Cleaton wrote: > > > Modified Files: > FormMail.pl > Log Message: > Copied $allow_empty_ref docs from README to POD > This is going to be a problem so long as we have the docs duplicated in the README and in FormMail.pl. It's nice having them in POD, and having them in FormMail.pl allows the use of a CVS revision tag, also nice. How about deleting the README from CVS and generating a README at release time with something like: pod2text -qnone -w72 FormMail.pl >README The pod2text that comes with perl 5.6.1 does a pretty good job IMO. We could even have readme.html as a bonus :) Dave, would that be easy ? -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-03-26 22:11:10
|
On Tue, 26 Mar 2002, Nick Cleaton wrote: > On Tue, Mar 26, 2002 at 01:45:09PM -0800, Nick Cleaton wrote: > > > > > > Modified Files: > > FormMail.pl > > Log Message: > > Copied $allow_empty_ref docs from README to POD > > > > This is going to be a problem so long as we have the docs > duplicated in the README and in FormMail.pl. > Ah yes, can we have a decision about this - I would rather have it in POD myself .... /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Sam S. <sa...@us...> - 2002-03-26 22:13:46
|
On Tue, 26 Mar 2002, Jonathan Stowe wrote:
> On Tue, 26 Mar 2002, Nick Cleaton wrote:
> > On Tue, Mar 26, 2002 at 01:45:09PM -0800, Nick Cleaton wrote:
> > >
> > >
> > > Modified Files:
> > > FormMail.pl
> > > Log Message:
> > > Copied $allow_empty_ref docs from README to POD
> > >
> >
> > This is going to be a problem so long as we have the docs
> > duplicated in the README and in FormMail.pl.
> >
>
> Ah yes, can we have a decision about this - I would rather have it in POD
> myself ....
pod2text ?
If there is stuff which should not be in the POD, then it should be
in a separate file.
Sam
--
Misfortune: While Good Fortune often Eludes You,
This Kind Never Misses
|
|
From: Jonathan S. <gel...@ge...> - 2002-03-26 22:24:45
|
On Tue, 26 Mar 2002, Sam Smith wrote: > On Tue, 26 Mar 2002, Jonathan Stowe wrote: > > On Tue, 26 Mar 2002, Nick Cleaton wrote: > > > On Tue, Mar 26, 2002 at 01:45:09PM -0800, Nick Cleaton wrote: > > > > > > > > > > > > Modified Files: > > > > FormMail.pl > > > > Log Message: > > > > Copied $allow_empty_ref docs from README to POD > > > > > > > > > > This is going to be a problem so long as we have the docs > > > duplicated in the README and in FormMail.pl. > > > > > > > Ah yes, can we have a decision about this - I would rather have it in POD > > myself .... > > pod2text ? > > > If there is stuff which should not be in the POD, then it should be > in a separate file. > Then MAKE THE ARRANGEMENTS AND DOCUMENT IT - This stuff should really be consistent over the whole suite of programs ... /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Jonathan S. <gel...@ge...> - 2002-03-27 09:03:57
|
On Tue, 26 Mar 2002, Jonathan Stowe wrote: > > Then MAKE THE ARRANGEMENTS AND DOCUMENT IT - This stuff should really be > consistent over the whole suite of programs ... > Sorry, that came across a bit more abrubt than I had intended - result of too many cans of beer on a horribly delayed train. Anyhow if we go with Dave's XML plan then we won't have to worry about it. /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Dave C. <da...@da...> - 2002-03-26 22:21:50
|
On Tue, Mar 26, 2002 at 09:51:38PM +0000, Nick Cleaton (ni...@cl...) wrote: > > This is going to be a problem so long as we have the docs > duplicated in the README and in FormMail.pl. > > It's nice having them in POD, and having them in FormMail.pl > allows the use of a CVS revision tag, also nice. > > How about deleting the README from CVS and generating > a README at release time with something like: > > pod2text -qnone -w72 FormMail.pl >README > > The pod2text that comes with perl 5.6.1 does a pretty > good job IMO. > > We could even have readme.html as a bonus :) > > Dave, would that be easy ? I was thinking about similar things earlier today. I was wondering what the advantages are of having the POD inside the Perl script. It seems to me that this is only an advantage with modules as perldoc will search @INC for POD to display. That doesn't work for scripts does it? I also tend to the opinion that raw POD is potentially too confusing for our target audience and we shouldn't be showing it to them. My plan (and I was planning on starting on this real soon now) was to convert all of the READMEs to XML and to generate text and HTML versions with XSLT. This seemed, to me, to have the advantage that the individual files would only contain the stuff that differs from script to script and the common stuff (like copyright and support information) would be stored externally so there's less chance of it getting out of step. I am, of course, open to other opinions on any of this. Dave... -- .sig missing... |
|
From: Jonathan S. <gel...@ge...> - 2002-03-27 09:03:56
|
On Tue, 26 Mar 2002, Dave Cross wrote:
> On Tue, Mar 26, 2002 at 09:51:38PM +0000, Nick Cleaton (ni...@cl...) wrote:
> >
> > This is going to be a problem so long as we have the docs
> > duplicated in the README and in FormMail.pl.
> >
> > It's nice having them in POD, and having them in FormMail.pl
> > allows the use of a CVS revision tag, also nice.
> >
> > How about deleting the README from CVS and generating
> > a README at release time with something like:
> >
> > pod2text -qnone -w72 FormMail.pl >README
> >
> > The pod2text that comes with perl 5.6.1 does a pretty
> > good job IMO.
> >
> > We could even have readme.html as a bonus :)
> >
> > Dave, would that be easy ?
>
> I was thinking about similar things earlier today. I was wondering what the
> advantages are of having the POD inside the Perl script. It seems to me that
> this is only an advantage with modules as perldoc will search @INC for POD
> to display. That doesn't work for scripts does it?
>
> I also tend to the opinion that raw POD is potentially too confusing for
> our target audience and we shouldn't be showing it to them.
>
I think the only advantage to it is that if the program file gets
separated from its README then the documentation is still there, but yeah
I think basically you are right.
> My plan (and I was planning on starting on this real soon now) was to convert
> all of the READMEs to XML and to generate text and HTML versions with XSLT.
> This seemed, to me, to have the advantage that the individual files would only
> contain the stuff that differs from script to script and the common stuff
> (like copyright and support information) would be stored externally so
> there's less chance of it getting out of step.
>
Yeah, I'd concur with that. I thought that I had started on a DTD for
that very purpose but I'm buggered if I can find any sign of it. I
wouldn't think that it need be very complicated - not much more than:
<!ELEMENT nms_readme (summary,files,configuration, installation) >
<!ATTLIST nms_readme prog_file CDATA #REQUIRED
full_name CDATA #REQUIRED>
<!ELEMENT paragraph (#PCDATA)>
<!ELEMENT summary (paragraph*)>
<!ELEMENT files (file*)>
<!ELEMENT file (filename, filedesc)>
<!ELEMENT filename (#PCDATA)>
<!ELEMENT filedesc (#PCDATA)>
<!ELEMENT configuration (introduction, variables*)>
<!ELEMENT introduction (paragraph*)>
<!ELEMENT variables (variable*)>
<!ELEMENT variable (var_name, description)>
<!ELEMENT var_name (#PCDATA)>
<!ELEMENT description (paragraph*)>
<!ELEMENT installation (paragraph*)>
The rest is just boilerplate that can either be defined as entities in the
DTD or hard coded in the XSLT.
You could even generate the MANIFEST from it and probably drive the
creation of the distribution files.
It would be a piece of piss to knock together a little program.
Its a shame that XML::XSLT doesn't do the text part very well :)
Unless someone else is dead keen on getting on with this I will do the
conversion at the weekend.
Other things that will be required for this effort are:
* XSLT stylesheet to generate text and HTML versions of the README
* Build program for distribution to generate README and MANIFEST
* Loads of other stuff I haven't thought about yet
While I think about it it might also be worth thinking about going down
this route with the Changelogs as well - I have made a small amendment to
cvs2cl that works nicely with the local style of putting '*' bullet points
in the cvs log - this then generates XML that is further transformed to
text for the distribution and HTML for the web site.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Nick C. <ni...@cl...> - 2002-03-27 09:05:26
|
On Tue, Mar 26, 2002 at 10:19:50PM +0000, Dave Cross wrote: > > I was thinking about similar things earlier today. I was wondering what the > advantages are of having the POD inside the Perl script. It seems to me that > this is only an advantage with modules as perldoc will search @INC for POD > to display. That doesn't work for scripts does it? The only thing I would say against that is that the CVS $Revision$ thing only works for docs that are right there in FormMail.pl. > I also tend to the opinion that raw POD is potentially too confusing for > our target audience and we shouldn't be showing it to them. Well, it is at the end :) > My plan (and I was planning on starting on this real soon now) was to convert > all of the READMEs to XML and to generate text and HTML versions with XSLT. And POD ? > This seemed, to me, to have the advantage that the individual files would only > contain the stuff that differs from script to script and the common stuff > (like copyright and support information) would be stored externally so > there's less chance of it getting out of step. Sounds good, so long as you do sufficient XSLT magic at release time to make sure all the revision information is correct in all files. Especially good if this means we can cut down on code duplicated between scripts. And of course the XSLT scripts to do all that stuff will need to be in the CVS tree and runnable on everyone's platforms so that we can all test our changes before checking them in. Another point: at the moment people can just grab the latest script straight of of CVS via the web to try out prerelease things. I wouldn't like to see that get a lot harder, so some sort of automatic pre-release thing that tracks CVS exactly is probably in order. -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-03-27 21:51:56
|
On Wed, 27 Mar 2002, Nick Cleaton wrote: > On Tue, Mar 26, 2002 at 10:19:50PM +0000, Dave Cross wrote: > > My plan (and I was planning on starting on this real soon now) was to convert > > all of the READMEs to XML and to generate text and HTML versions with XSLT. > > And POD ? > Oh yeah, I think there is even an XML->POD SAX driver crawling around in Matt Sergeants brain ... /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Nick C. <ni...@cl...> - 2002-03-28 14:30:54
|
On Thu, Mar 28, 2002 at 06:14:03AM -0800, Nick Cleaton wrote:
>
> FormMail.pl
> Log Message:
> * POD typo
> * sort=order:... handling bug fix
It was respecting the 'sort' setting being "order:..."
in the email but not on the HTML page. Matt't script
seems to do the same, but I *haven't* protected the
change with $emulate_matts_code.
My reasons:
It's definitely a bug in Matt's script. There is code
in place to respect the order in the output HTML, but
it doesn't work because the code to respect the order
in the email stomps on $Config{'sort'}. In this sense,
I'm treating $emulate_matts_code as 'do what Matt meant
to do'.
Much simpler code without emulating the bug. The
change is +16 lines -40 lines.
If order excludes an input, it gets left out. It's bad
for the person sending the form to be told that some
information has gone through whereas in fact it hasn't.
An example: a user adds a 'tick this box not to get spam'
field to their form but forgets to add it to the sort
order hidden input. When a visitor submits the form,
they see a page telling them that the no spam input was
part of what they submitted but it doesn't get into the
email. The visitor gets spam, and much wailing and
gnashing of teeth follows.
Is anyone desperately keen to put this bug emulation in
if $emulate_matts_code ?
--
Nick
|
|
From: Nick C. <ni...@cl...> - 2002-03-31 23:18:36
|
On Sun, Mar 31, 2002 at 03:09:33PM -0800, Nick Cleaton wrote: > > Added Files: > nms_sendmail > Log Message: > * added a script to act as 'sendmail -t', for systems that lack a > suitable sendmail binary. This is in response to a windows user wanting to get FormMail to use blat.exe, and my total failure to find a way to get blat.exe to act like 'sendmail -t'. Pointing $mailprog at this script works for me (under UNIX), when I set $mailprog to: '/usr/local/perl-5.00404/bin/perl -wT /home/nick/nms/w/formmail/nms_sendmail -oi -t'; ...but it really needs to be tested under windows. Can someone with access to a win32 web server give it a go please ? -- Nick |
|
From: Nick C. <ni...@cl...> - 2002-04-03 11:34:54
|
On Mon, Apr 01, 2002 at 12:17:38AM +0100, Nick Cleaton wrote: > > Pointing $mailprog at this script works for me (under UNIX), > when I set $mailprog to: > > '/usr/local/perl-5.00404/bin/perl -wT /home/nick/nms/w/formmail/nms_sendmail -oi -t'; > > ...but it really needs to be tested under windows. Can someone > with access to a win32 web server give it a go please ? Having remembered that I have access to a test account on an IIS server at work (doh !) I've tested this myself, and it works. The question now is: Should the nms_sendmail script be added to the formmail package, or should it go in a separate package, allowing it to be used with other scripts that send mail as well ? I'm thinking a separate package, and mention it in the $mailprog part of the formmail README. If nobody objects, I'll create a top-level 'sendmail' directory in CVS, move this script there, and pester Dave to do a release of this and add a 'supporting utilities' bit to the web page. -- Nick |
|
From: Olivier D. <dr...@sh...> - 2002-03-31 23:24:02
|
On Sun, Mar 31, 2002 at 03:09:33PM -0800, Nick Cleaton wrote: > Added Files: > nms_sendmail > Log Message: > * added a script to act as 'sendmail -t', for systems that lack a > suitable sendmail binary. Isn't this a bad thing? if I'm not mistaken this breaks compatibility with MWS... unless I don't quite understand the purpose of nms_sendmail. If you're going to use a seperate sendmail program why not use Email::Sendmail? -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Nick C. <ni...@cl...> - 2002-03-31 23:30:30
|
On Sun, Mar 31, 2002 at 06:28:33PM -0500, Olivier Dragon wrote: > > Isn't this a bad thing? if I'm not mistaken this breaks compatibility > with MWS... unless I don't quite understand the purpose of nms_sendmail. Matt's formmail requires sendmail, so I'm not introducing any compatibility issues by making a sendmail substitute available, since anyone who already has a working Matt's formmail must have a working sendmail and therefore won't need to install nms_sendmail. > If you're going to use a separate sendmail program why not use > Email::Sendmail? For the same reason that I didn't use Net::SMTP, we're not allowed anything that doesn't come with a default install of perl-5.00404. -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2002-04-01 10:27:53
|
On Sun, 31 Mar 2002, Olivier Dragon wrote: > On Sun, Mar 31, 2002 at 03:09:33PM -0800, Nick Cleaton wrote: > > Added Files: > > nms_sendmail > > Log Message: > > * added a script to act as 'sendmail -t', for systems that lack a > > suitable sendmail binary. > > Isn't this a bad thing? if I'm not mistaken this breaks compatibility > with MWS... unless I don't quite understand the purpose of nms_sendmail. > > If you're going to use a seperate sendmail program why not use > Email::Sendmail? > The program itself is entirely within the design goals of NMS and it provides a solution to the problem where people on platforms where there is no sendmail compatible MTA injector ... Whereas Mail::Sendmail is not. /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Nick C. <ni...@cl...> - 2002-04-05 22:39:17
|
On Fri, Apr 05, 2002 at 02:30:53PM -0800, Nick Cleaton wrote: > > Modified Files: > guestbook.html guestbook.pl guestlog.html > Log Message: > * fixed some tag nesting errors > * <html> becomes <html xmlns="http://www.w3.org/1999/xhtml"> > * eliminated a warning Now it nearly passes its first test, but not quite. The guestlog isn't valid XHTML because the entries are appended after the </html>, so we'll need to do the whole tmp-file-and-rename-into-place for that as well as the guestbook :( -- Nick |
|
From: Nick C. <ni...@cl...> - 2002-04-06 22:27:10
|
On Fri, Apr 05, 2002 at 10:38:14PM +0100, Nick Cleaton wrote: > > Now it nearly passes its first test, but not quite. > The guestlog isn't valid XHTML because the entries are > appended after the </html>, so we'll need to do the whole > tmp-file-and-rename-into-place for that as well as the > guestbook :( > The way I see it, we have 3 options: Rewrite the whole log file each time. Inefficient for a large log file, but the cost of rewriting the guestbook should dominate unless the guestbook gets cleaned out more frequently than the log file. At each write, truncate the "</body>\n</html>\n" off the end of the log file, write the new entry, then put the footer back. Just append as we do now, but make it OK by distributing a guestlog.txt file rather than a guestlog.html file. Thoughts ? -- Nick |
|
From: Nick C. <ni...@cl...> - 2002-04-08 22:24:15
|
On Sat, Apr 06, 2002 at 10:26:03PM +0100, Nick Cleaton wrote: > On Fri, Apr 05, 2002 at 10:38:14PM +0100, Nick Cleaton wrote: > > > > Now it nearly passes its first test, but not quite. > > The guestlog isn't valid XHTML because the entries are > > appended after the </html>, so we'll need to do the whole > > tmp-file-and-rename-into-place for that as well as the > > guestbook :( > > > > The way I see it, we have 3 options: > > Rewrite the whole log file each time. Inefficient for a > large log file, but the cost of rewriting the guestbook > should dominate unless the guestbook gets cleaned out more > frequently than the log file. > > At each write, truncate the "</body>\n</html>\n" off the > end of the log file, write the new entry, then put the > footer back. > > Just append as we do now, but make it OK by distributing > a guestlog.txt file rather than a guestlog.html file. > > Thoughts ? Does anyone have any preference, or shall I just pick one and do it ? -- Nick |
×
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