nms-cgi-devel — Developers discussion for NMS CGI programs

[Nms-cgi-devel] [ nms-cgi-Support Requests-1053199 ] formmail - time

[SourceForge.net <no...@so...>]

Support Requests item #1053199, was opened at 2004-10-24 09:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1053199&group_id=39625

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jac (jcolley)
Assigned to: Nobody/Anonymous (nobody)
Summary: formmail - time

Initial Comment:
is ther a way to offset the time 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1053199&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Support Requests-1053198 ] formmail- save entries on error

[SourceForge.net <no...@so...>]

Support Requests item #1053198, was opened at 2004-10-24 09:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1053198&group_id=39625

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jac (jcolley)
Assigned to: Nobody/Anonymous (nobody)
Summary: formmail- save entries on error

Initial Comment:
If I get an error for not filling in a required field
and go BACK to the form all the fields are reset.  Is
there a way to keep them so the client will not have to
fill them in again?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1053198&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Support Requests-1053195 ] validating email address

[SourceForge.net <no...@so...>]

Support Requests item #1053195, was opened at 2004-10-24 09:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1053195&group_id=39625

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jac (jcolley)
Assigned to: Nobody/Anonymous (nobody)
Summary: validating email address

Initial Comment:
is there a way to validate the email address the cient
enters in formmail ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1053195&group_id=39625

[Nms-cgi-devel] Re: [Bulk] Re: [Nms-cgi-support] NMS WWWBoard Spam problems.

[Jonathan S. <jn...@ge...>]

On Fri, 2004-10-15 at 15:16, GMO wrote:

> I also added:
> 
> Attempt to submit invalid data. (Banned word(s) or character(s)) Your message 
> will not be added until it is corrected. Please use your browsers back button to 
> return to your posting.
> 
> to the error message so the user will know it's a word that's banned. 

I'm not so sure about this.  If the aim is to deter spammers then we
don't want them to know how to get around the problem easily really.

Of course you can add anything you like to the code that you are using
yourself.

I would really rather see wwwboard go away eventually (or rather become
no longer recommended for new users) and be replaced by something based
on the TFmail core, allowing templating and so forth.  Of course this
requires developer time to implement and writing this stuff doesn't pay
the bills.

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Re: [Nms-cgi-support] NMS WWWBoard Spam problems.

[Jonathan S. <jn...@ge...>]

On Wed, 2004-10-13 at 09:48, Mark Young wrote:
> These are the IP's that posted spam last night.
>  
> 216.83.96.37
> 212.165.158.100
> 12.215.220.247

Okay,
We will have made a new release of wwwboard on friday morning.  This
will include some new anti-abuse measures that you may find useful:

	*  Use a banned words list defined in an external file

	*  Use a banned IP (or network) list defined in an external file

	*  Use DNS Block List to block known proxies and 'cracked' computers

These new features are relatively easy to configure and are described in
the README - we would hope that the documentation is clear but
appreciate any feedback that you may be able to offer in this regard. 
If you have any further questions please do not hesitate to contact us.

/J\
>  
> Regards
>  
> Mark.
> 
> Jonathan Stowe <jn...@ge...> wrote:
>         On Mon, 2004-10-11 at 15:44, Mark Young wrote:
>         > I've recently changed my WWWBoard from a MSA version to a
>         NMS version
>         > to stop spam. Unfortunately I am just starting to get spam
>         again.
>         > 
>         > Does anyone have any suggestions. I want to keep WWWBoard,
>         but dont
>         > want the problems.
>         
>         Unfortunately the 'spam' posts to your WWWBoard are
>         indistinguishable
>         from the legitimate ones to the program as it stands. The NMS
>         WWWBoard
>         is definitely more secure than the MSA one in asmuch as it
>         fills a
>         number of holes whereby a cracker could deface the site and/or
>         DoS the
>         server fairly simply with a small custom web client.
>         
>         The current development versions of NMS WWWBoard have a number
>         of
>         experimental features to block 'Spam' but they are quite a
>         long way from
>         release as it stands - you can always get the latest
>         development version
>         from:
>         
>         http://cvs.sourceforge.net/viewcvs.py/*checkout*/nms-cgi/wwwboard/wwwboard.pl
>         
>         If you have $show_poster_ip set to 1 it might be useful for
>         you to
>         record the IP addresses of the abusive posters - it is likely
>         that they
>         are otherwise blacklisted open proxies that are being
>         exploited by the
>         spammers: we have some code in the NMS TFmail that consults a
>         DNS based
>         block list to defeat these kinds of attacks - if you supply us
>         with some
>         of the IPs we can check if this will work for you.
>         
>         In the short-term you might want to simply change the name of
>         your
>         wwwboard.cgi as this will defeat the automated messages for a
>         while.
>         
>         In the longer term I think that we may create some
>         WWWBoard-like
>         functionality into TFMail (which despite its name already has
>         guestbook
>         like features ) which is our longer term development platform.
>         
>         /J\
>         -- 
>         
>         This e-mail is sponsored by http://www.integration-house.com/
>         
> 
> ______________________________________________________________________
> ALL-NEW Yahoo! Messenger - all new features - even more fun!
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] [ nms-cgi-Feature Requests-878378 ] support UTF-8

[SourceForge.net <no...@so...>]

Feature Requests item #878378, was opened at 2004-01-16 17:01
Message generated for change (Settings changed) made by gellyfish
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=878378&group_id=39625

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: peter gervai (grin)
Assigned to: Nobody/Anonymous (nobody)
Summary: support UTF-8

Initial Comment:
Please support UTF-8. 
8859-1 is history. It's bad. It's evil. It's codepage 437! Burn. 
Burn.

And perl supports unicode anyway.


----------------------------------------------------------------------

Comment By: peter gervai (grin)
Date: 2004-01-17 11:19

Message:
Logged In: YES 
user_id=9622

That was an asnwer without thinking, I am really sorry to point out.

The right answer would require to consider things.

You are very right that old perl does not support unicode, I accept that.
However I am talking about supporting UTF-8 *webpages* (input), 
which does not have to rely on Unicode support in perl. In fact it 
probably would not even use it (you can handle it just fine without 
unicode regexp, etc). All you have to do is to 

1) use utf-8 encodings on pages and generated pages

2) handle utf-8 input (at validation, it is not that complex if you check 
man perluni and see valid ranges, there are 4 or like!)

I think that's all. In fact I tried to do that but somewhere the code 
screws up the input and I cannot figure out where, and I did not have 
the time to rewrite the whole beast. :-(

So if you still believe that the request is not worthy of consoderation 
(since the program is completely useless in its current form outside 
latin1 regions) go on and close it.

Thanks for your time and efforts.


----------------------------------------------------------------------

Comment By: Dave Cross (davorg)
Date: 2004-01-16 17:54

Message:
Logged In: YES 
user_id=34146

Not all versions of Perl support UTF-* successfully. We
expect out programs to work on versions of Perl back to
5.004_04, so we are unlikely to rely on UTF-8 support in the
near future.

Dave...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=878378&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Feature Requests-760837 ] Add fields for user verification

[SourceForge.net <no...@so...>]

Feature Requests item #760837, was opened at 2003-06-25 23:00
Message generated for change (Comment added) made by gellyfish
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=760837&group_id=39625

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Scott Jordan (msjordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add fields for user verification

Initial Comment:
Add some extra fields in sub configuration_form_fields.
Give users the option to check the field values to
verify that the submission came from their html form.

This would give the user the ability to set fields to
predeterminied values in the html form, then check the
values in the script.

For example, in older versions one could add additional
fields such as one named 'session':
                 <--snip-->
                  print_blank_fields
                  missing_fields_redirect
                  session   (user field)
                 );

Field session would be set to a value in the user's
html form.

The script would abort if the user field value was not
set to the proper value. In this case, the script
expects field 'session' to have a value of 7720 set in
the html.

        if ($Config{session} ne "7720") {
                exit;
        }

This would provide another level of protection from
formmail script spammers who repeatedly submit bogus
requests to formmail scripts. We've seen some of them
forging the 'referer' fields so the @referers check
won't always stop the bogus requests. The user can set
the expected user field value whenever they wish.



----------------------------------------------------------------------

>Comment By: Jonathan Stowe (gellyfish)
Date: 2004-10-12 10:27

Message:
Logged In: YES 
user_id=313586

Have added the session capability to TFMail - if you have
any further questions please refer to
nms...@li...

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-10-06 13:06

Message:
Logged In: NO 

That  wouldn't stop bogus requests (which aren't processed
anyway).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=760837&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Patches-594722 ] 2 enhancements to rand_image

[SourceForge.net <no...@so...>]

Patches item #594722, was opened at 2002-08-13 18:33
Message generated for change (Settings changed) made by gellyfish
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425771&aid=594722&group_id=39625

Category: None
Group: None
>Status: Closed
Resolution: Postponed
Priority: 5
Submitted By: Dave Skolnick (dave-man)
Assigned to: Jonathan Stowe (gellyfish)
Summary: 2 enhancements to rand_image

Initial Comment:
The attached patch file improves the randomness of
rand_image and adds the capability to select a random
image from a directory without configuring every file
in the directory.

For the first change, the line:

my $pic = $files[rand @files];

is changed to:

my $pic = $files[int(rand @files) + 1];

This improves the randomness in my testing.

Secondly I added:

# If this ($use_allfiles) is set to 1 then the program
will randomly display all the 
# files in the directory specified in $basedir. If set
to 0, the program will only 
# rotate among the files identified in the "my @files =
qw (" section below.
# WARNING -- this version assumes that every single
file in the directory is an
# image file and should be displayed. There is no
checking at ALL to confirm this 
# assumption beyond ignoring any files that start with
a '.'.

my $use_allfiles = 1;

to the configuration section (really only adding a
single variable), and the following code immediately
before the random file selection:

if ( $use_allfiles ) {
  undef @files;
  opendir( DIR, $basedir )
    or die "Can't opendir $basedir: $! \n";
  while ( defined( my $file = readdir( DIR ) ) ) {
    push @files, $file unless ( $file =~ /^\./ );
  }
}

Hope these are useful to you

----------------------------------------------------------------------

Comment By: Dave Skolnick (dave-man)
Date: 2002-08-14 13:41

Message:
Logged In: YES 
user_id=57537

my $pic = $files[rand @files];

my $pic = $files[int(rand @files) + 1]; 

There are days when I have flashes of stupidity. davorg's 
point regarding the index is correct.

On receiving his note, I built a test script using the two 
approaches (after removing the inappropriate +1). The 
array contained 10 elements. Running 100,000 
iterations, both approaches have a mean of 10,000 as 
one would hope and a standard deviation of around 89. 
The differences are not significant.

In production, we have found that my $pic = $files[rand 
@files]; does not give an even distribution of results, 
but that my $pic = $files[int(rand @files)]; does. 

My next step is to set up a test case on the production 
platform. I will let you know.

I'll definately do a separate patch file for my proposed 
enhancement.

----------------------------------------------------------------------

Comment By: Dave Cross (davorg)
Date: 2002-08-14 11:04

Message:
Logged In: YES 
user_id=34146

my $pic = $files[rand @files];

my $pic = $files[int(rand @files) + 1]; 

As far as I can see, see only difference that this patch
would make would be be to break the program.

The addition of the int call has no effect as an array index
is automatically converted to an integer anyway.

The "+ 1" has the effect of pushing the reuqested index off
the end of the array - thereby giving an "uninitialised
value" error under "use warnings".

A longer explaination follows:

@files in a scalar context gives the number of elements in
the array @files. Let's assume this is 10.

rand 10 gives a number between 0 and just less than 10. It
will never return 10.

int(rand 10) will therefore give an integer between 0 and 9.

Adding one to this gives an integer between 1 and 10.

In a 10 element Perl array, the valid indexes are 0 to 9.
Your expression therefore a) will never return the first
element (index 0) and b) will try to return an element with
index 10 which doesn't exist.

Can you perhaps give some more explaination of the way you
designed and tested this patch?

Dave...


----------------------------------------------------------------------

Comment By: Dave Skolnick (dave-man)
Date: 2002-08-14 11:03

Message:
Logged In: YES 
user_id=57537

Certainly can update my patch to your CVS version. I'd like 
to page through your new code (since the patch didn't apply) 
first, and I should probably split the patch into two for the fix 
(for increased randomness) and the enhancement (for the 
display of directory contents). I will try to get to it in the next 
couple of days, otherwise after I get back from holiday at the 
end of August.

----------------------------------------------------------------------

Comment By: Jonathan Stowe (gellyfish)
Date: 2002-08-14 10:46

Message:
Logged In: YES 
user_id=313586

Thanks for this.

Could you redo your changes against the 1.10 version from
the CVS as this patch fails to apply.  If for some reason
you can't do that I have no objection to doing it manually
but I am a little busy at the moment so it might not go in
quite as soon.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425771&aid=594722&group_id=39625

[Nms-cgi-devel] Re: [Bulk] Re: [Nms-cgi-support] recipient_alias & allow_mail_to notfunctioning as expected

[Jonathan S. <jn...@ge...>]

On Mon, 2004-10-11 at 17:05, GMO wrote:
> Near the turn of the century, On 11 Oct 2004 at 11:05, Jonathan Stowe spake thusly:
> 
> > On Fri, 2004-10-08 at 18:08, GMO wrote:
> > 
> > > BTW, does anyone know why when getting any perl or cgi script
> > > anywhere no one adds a .txt extension to the readme files? Would be
> > > much simpler to open them. 
> > 
> > This is really a problem with your client OS/choice of tools - I
> > certainly have no problem typing 'less README' ;-)
> > 
> > /J\
> 
> Hi Jonathan, 
> 
> Uh... wrong answer. :)
> 
> Actually, I'm an old "dos fanatic" who went into windows kicking and screaming 
> when they forced it down our throats. Of course that was so long ago I doubt I 
> could even write a batch file anymore. My browser of choice was Mosaic... or was 
> it Cello? Hell, I don't remember what came first. But I digress.
> 
> It was certainly not a complaint! I have all the respect in the world for you guru's! 
> :) Since there are so many progs out there for us lazy folks there is little reason to 
> get into programming for it. Just not enough time in the day anymore. 
> 
> I can read the files just by highlighting them. No need to type anything. :)  And 
> with dual monitors I can have the readme open on one monitor while I configure 
> on another. But to print it I either have to add the .txt extension or go thru a few 
> clicks to have notepad open it. (Us.... lazy folks. :) And it's usually easier (at least 
> for me) to print it out and analyze it that way. 
> 
> But, the point of the question was... since no one adds the txt extension, what do 
> you folks generally run? Since they are "basically" just text files it seems odd to 
> me that no one at all (even outside NMS) would be using windows. But if using 
> windows, the default save would be a txt file. More effort to take it off then to 
> leave it on. :) Granted the scripts are written for Unix, but the vast majority of end 
> users (That would be idiots like me) will be running windows since the latest stats 
> show that 95% of the computers on the planet run windows.
> 

The use of README (and other upper case filenames without a suffix) is a
long-standing convention in open source/public domain software
distribution and I guess that no-one here has ever thought about
changing it. On Unix-like systems then it is not going to be causing any
problems because on the whole most people will just type:

   $foo README

where $foo is their editor/viewer/printing program of choice - even the
Nautilus file manager that I use with the Gnome desktop (for example)
knows that it is a plain text file and will either open it in a text
viewer or offer a choice of editors.  The suffix of a file is purely
informational in these cases - after all these things (the editors and
so forth) are software and have much better ways of determining what
kind of thing a file is - e.g:

        [jonathan@orpheus contracts]$ cp ContractExtJStowe.doc foo
        [jonathan@orpheus contracts]$ file foo
        foo: Microsoft Office Document
        
or

        [jonathan@orpheus ogone_docs]$ cp Ogone_Batch_Integration_20040504_EN.pdf foo
        [jonathan@orpheus ogone_docs]$ file foo
        foo: PDF document, version 1.2


I would guess that nearly all the NMS developers are using some
Unix-like operating system.

Now whether we should rename the README and so forth with a .txt
extension when they are added to the .zip versions of the distributions
(we already are converting the line-endings appropriately for broken
versions of Notepad) is moot - I guess it just requires someone who
feels strongly about it actually adding the extra code to the
'release.pl' that creates the distribution files.

I have copied the devel list incase anyone can find the time.

/J\

-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] [ nms-cgi-Support Requests-1043959 ] guestbook error

[SourceForge.net <no...@so...>]

Support Requests item #1043959, was opened at 2004-10-10 04:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1043959&group_id=39625

Category: Install Problem (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: guestbook error

Initial Comment:
I have tried to use the guestbook in my webpage 
www.braincellcollective.com and all goes well until you 
click to submit info, and an error appears. I have played 
around, but cannot get it working. Any ideas? please 
email info@braincellcollective if you have any 
sugestions. Otherwise I shall have to look elsewhere for 
a similar script. Many thanks in advance,
Tim

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1043959&group_id=39625

[Nms-cgi-devel] [Fwd: Re: [Nms-cgi-support] Random Link Generator]

[Jonathan S. <jn...@ge...>]

Should have copied the devel list with this.  If anyone wants to chuck
some more tests in for this feel free ...

-----Forwarded Message-----
> From: Jonathan Stowe <jn...@ge...>
> To: ra...@io... <ra...@io...>
> Cc: NMS-CGI-Support <nms...@li...>
> Subject: Re: [Nms-cgi-support] Random Link Generator
> Date: Thu, 07 Oct 2004 13:38:41 +0100
> 
> On Thu, 2004-10-07 at 11:16, ra...@io... wrote:
> > Hi,
> > 
> > found your useful script nms Random Link Generator aroud the net.
> > 
> > I have a question:
> > 
> > Is it possible to call script with URL divided by categories?
> > 
> > If it is possible how can I do it? for example creating different
> > URL text-files and passing the name to the CGI as parameter?
> > 
> 
> I have just uploaded a new version of the rand_link program to:
> 
>     http://nms-cgi.sf.net/scripts.shtml
> 
> This has some new configuration that enables you to do what you want.
> 
>   $use_multi_file - if set to 1 then will ignore $linkfile if the
> 'collection' parameter is passed to rand_link.pl with a filename.
> 
>    $linkdir is a directory in which the files can be found.
> 
>    $link_ext is an extension that will be added to the filename
> specified by the 'collection' parameter.
> 
> The file specified by the 'collections' parameter should contain only
> alphanumeric characters and the underscore '_' and shouldn't include the
> extension or path (as they are defined in the config above).
> 
> /J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] [ nms-cgi-Feature Requests-760837 ] Add fields for user verification

[SourceForge.net <no...@so...>]

Feature Requests item #760837, was opened at 2003-06-25 16:00
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=760837&group_id=39625

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Scott Jordan (msjordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add fields for user verification

Initial Comment:
Add some extra fields in sub configuration_form_fields.
Give users the option to check the field values to
verify that the submission came from their html form.

This would give the user the ability to set fields to
predeterminied values in the html form, then check the
values in the script.

For example, in older versions one could add additional
fields such as one named 'session':
                 <--snip-->
                  print_blank_fields
                  missing_fields_redirect
                  session   (user field)
                 );

Field session would be set to a value in the user's
html form.

The script would abort if the user field value was not
set to the proper value. In this case, the script
expects field 'session' to have a value of 7720 set in
the html.

        if ($Config{session} ne "7720") {
                exit;
        }

This would provide another level of protection from
formmail script spammers who repeatedly submit bogus
requests to formmail scripts. We've seen some of them
forging the 'referer' fields so the @referers check
won't always stop the bogus requests. The user can set
the expected user field value whenever they wish.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-10-06 06:06

Message:
Logged In: NO 

That  wouldn't stop bogus requests (which aren't processed
anyway).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=760837&group_id=39625

[Nms-cgi-devel] Re: [Nms-cgi-support] RE: looking for a Perl script

[Jonathan S. <jn...@ge...>]

On Tue, 2004-09-28 at 21:35, Malcolm wrote:
> Hi Dave
> 
> Thanks for the rapid reply. I obtained the data from e.g.
> http://en.wikipedia.org/wiki/List_of_cities_in_Alaska
> I am not too concerned about the criteria by which the towns made it
> onto the list and hence I am not overly concerned about how complete the
> lists are.
> 
> www.flattext.com have a utility where I can generate PERL script (costs
> $60) which inserts a select box for state into a web page and upon
> selection of the state, generates a HTML list of towns which is also
> inserted into the web page. The bit I'm now missing is how to get that
> to generate a select list where the user can then choose the city.
> 

As Dave said, this is not particularly difficult stuff - you have a
table of 'states' from which you create your initial drop down and then
a separate city-states table which joins the states to the cities from
which you would select the appropriate cities and build a further
selection.

> Alternatively, it might be easier to allow the user to select the state
> and then type in the town and validate the entry against my data. Do you
> have a script that would do that instead?
> 

Er, no we don't have a program that does anything like this stuff.

The only draw back with validating afterwards would be that someone
might want to call their locale something different to what you have in
your database or spell it, capitalize it or punctuate it differently. 
The city, town, village or hamlet may not appear in your database at
all.

The approach most people take is to allow the user to put in their
postal code and then use that to look up the address and then populate a
form and let them edit it as they see appropriate (supplying house name
or number) - the only problem with this is that the data can be
expensive to obtain.

I have copied the developers list in case someone has something like
this down the back of the sofa.

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Re: [Nms-cgi-support] Radio Button with TFmail

[Jonathan S. <jn...@ge...>]

On Thu, 2004-09-23 at 01:31, Steve Wooler wrote:
> I'm using TFmail to send formatted copies of web forms. My form has
> radio buttons that I wish to reproduce on the notification email. How
> can I use the parameters to select or unselect individual radio
> buttons on the notification email form so that they exactly reproduce
> the way the user selected them on the web form? 

As it stands I can't think of a way to do this as it would require the
templating engine to be able to comparisons in the {= IF ... =}
directive, currently it is only able to tell whether a parameter has a
value or not.

I have copied this to the developers list in case anyone has a better
idea of how to do this or alternatively has the time to extend the
templating.

/J\ 

-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] [ nms-cgi-Feature Requests-974347 ] Support for GPG encryption

[SourceForge.net <no...@so...>]

Feature Requests item #974347, was opened at 2004-06-16 20:04
Message generated for change (Comment added) made by solidusys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=974347&group_id=39625

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for GPG encryption

Initial Comment:
One thing missing is support for encrypting the body of
the email. This feature is available in Matt's formmail
(http://www.mattsscripts.co.uk/mattfm.htm), but I
prefer the security and features of NMS.

----------------------------------------------------------------------

Comment By: Solidusys (solidusys)
Date: 2004-09-22 02:56

Message:
Logged In: YES 
user_id=1126247

This feature is most wanted!! -- In searching for hosting
providers, in establishing website services with other
service providers, PLUS the need for encryption of
information obtained from <FORM>s is ever more important. 
Since this need shows no sign of diminishing, I had been
looking into where in the code I could modify it for my
purposes.

The alternatives were to use pgp5mail.pl or GSecure, which
are modifications to the Matt Wright script from version 1.5
or 1.6.  (no very good options however at least the names
are different! -- wheeee!)

The challenge in altering the NMS script appears to be
altering the use of the "send_main_email_fields" which will
likely need modification along with 
send_main_email_field
build_main_email_field
wrap_field_for_email

so that the main field / body text is concatenated and
encrypted with /bin/gpg or /bin/pgp (or wherever the
encryption code installed is located).

Examples of the use of GnuPG can be found in GSecure.

I've never done any development work in the context of
SourceForge, so I'm loathe to give this a go with what I
believe to be a critical script.  Let me know you opinions
on the topic.  Thanks very much for your work and consideration!

Regards...JB

----------------------------------------------------------------------

Comment By: Jonathan Stowe (gellyfish)
Date: 2004-07-14 06:23

Message:
Logged In: YES 
user_id=313586

Thanks for this.  We have been asked about providing the
ability to encrypt the mail messages before.  The problem we
have is that the ability to use gpg/pgp relies on the user
having access to the shell on the machine their web site is
on which I would guess is a very small minority of people
with web sites. 

Ideally we would be able to implement implement some sort of
encryption that did not require any external dependencies -
but no-one has come forward to take up the challenge of
implementing it.
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=974347&group_id=39625

[Nms-cgi-devel] Re: [Nms-cgi-support] FormMail & Blat

[Jonathan S. <jn...@ge...>]

On Fri, 2004-08-27 at 14:37, namtog wrote:

> 
> The only problem I have with FormMail is the lack of authentication,
> my ISP requires it for all email. Nothing fancy, simply log on with
> username and password. Unless I am missing this
> configuration option some where in FormMail. If so please enlighten me
> and forgive my stupidity.

No you are correct the SMTP facility in FormMail does not do AUTH at
all, this is probably something we should remedy at some point - I have
copied the developers list in case this is the kind of thing that
someone might be interested in implementing, however the real
development effort is going into the NMS TFmail and we would probably
implement it there and then back-port the code authentication code into
FormMail.

As to the blat stuff - we have deliberately made the decision not to
make any effort to support blat as we don't think it is any better than
supporting SMTP directly within the FormMail itself - after all with the
exception of the authentication there is nothing that it does that we
cannot do at the moment, plus we are in the position to have finer
control over the outgoing mail envelope so we can add tracking headers
and so forth, something that some spam filter software uses to determine
that the mail has come from the NMS FormMail.

If you are thinking of amending FormMail nonetheless you will find it a
lot easier if you work on the modules version or even better the code
from the CVS as the inlining code we use to create the compat version
changes quite a lot of stuff.

/J\

[Nms-cgi-devel] Re: [Nms-cgi-commits] CVS Commit

[Jonathan S. <jn...@ge...>]

On Tue, 2004-08-24 at 10:23, Jonathan Stowe wrote:
> uid=68026(gellyfish) gid=100(users) groups=100(users),40625(nms-cgi),7054(xmlxslt)
> tfmail README,1.29,1.30 TFmail.pl,1.26,1.27
> Tue Aug 24 02:23:03 PDT 2004
> Update of /cvsroot/nms-cgi/tfmail
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26216
> 
> Modified Files:
> 	README TFmail.pl 
> Log Message:
> Added session capability to tie GET produced form to the POST

RCS file: /cvsroot/nms-cgi/tfmail/TFmail.pl,v
retrieving revision 1.26
retrieving revision 1.27
diff -r1.26 -r1.27
4c4
< # $Id: TFmail.pl,v 1.26 2004/08/20 08:00:16 gellyfish Exp $
---
> # $Id: TFmail.pl,v 1.27 2004/08/24 09:23:02 gellyfish Exp $
15a16
> use constant SESSION_DIR    => '.';
72c73
<    $VERSION = substr q$Revision: 1.26 $, 10, -1;
---
>    $VERSION = substr q$Revision: 1.27 $, 10, -1;
116a118,119
>       check_session($treq) or die "Bad or missing session
information";
>
167a171,283
> =item check_session ( TREQ )
>
> If L<use_session> would return a true value this will determine the
appropiate> method of determining the session id (either cookie or form
field) and
> retrieve the session id then check for its existence, returning true
if the
> session exists and false if it doesn't.  The session will be removed
if it
> exists.  It will always return true if sessions are not in use.
>
> =cut
>
> sub check_session
> {
>    my ( $treq ) = @_;
>
>    my $session_ok = 1;
>    if ( use_session($treq) )
>    {
>       $session_ok = 0;
>
>       my $session_id;
>       if ( $treq->config('session_cookie',0) )
>       {
>          $session_id = $treq->cgi()->cookie('SessionID');
>       }
>       else
>       {
>          $session_id =
$treq->param($treq->config('session_field','session'));>       }
>
>       if ( $session_id )
>       {
>          $session_id =~ /([a-fA-F0-9]+)/ or die "Bad Session id";
>          $session_id = $1;
>
>          my $session_file = "@{[ SESSION_DIR ]}/$session_id";
>
>          if ( -f $session_file )
>          {
>             $session_ok = 1;
>             unlink $session_file or die "Can't delete session
[$session_file]";
>          }
>       }
>
>    }
>
>    return $session_ok;
> }
>
> =item create_session ( TREQ )
>
> This creates the new session file in SESSION_DIR and returns the
number of
> the session created.  It will die if it is unable to create the
session file.
>
> =cut
>
> sub create_session
> {
>    my ( $treq ) = @_;
>
>    my $session_id = session_id();
>    my $session_file = "@{[ SESSION_DIR ]}/$session_id";
>
>    open TFILE, ">$session_file" or die "Unable to create session: $!";
>    print TFILE $ENV{REMOTE_ADDR};
>    close TFILE;
>
>    return $session_id;
> }
>
>
> =item session_id
>
> This returns a hexadecimal number that is suitable to be used as a
session ID
>
> =cut
>
> =for developers
>
> Please review the uniqueness of this - I tested with ~ 1.5m calls to
this
> code and didn't find any duplicates but different OS, levels of
concurrency
> and other factors may impact this.
>
> =cut
>
> sub session_id
> {
>    return sprintf("%x%x%x", (time() +  $$) * rand, {} * rand,[] *rand)
> }
>
> =item use_session ( TREQ )
>
> This returns a true value if either the configuration items
'session_cookie'
> or session_field are set, indicating that for a GET request the
appropriate
> session should be generated and for a POST the existence of the
session
> should be checked before any further actions are taken.
>
> =cut
>
> sub use_session
> {
>    my ( $treq ) = @_;
>
>    if ( $treq->config('session_cookie','') ||
$treq->config('session_field',''))
>    {
>       return 1;
>    }
>    else
>    {
>       return 0;
>    }
>
> }
>
210a327,328
>       my @cookie = ();
>
212c330,351
<       html_page($treq, $treq->config('get_template'));
---
>
>       if (use_session($treq) )
>       {
>          my $session_id = create_session($treq);
>
>          my $me = $treq->cgi()->script_name();
>
>          if ( $treq->config('session_cookie',0) )
>          {
>             my $cookie = $treq->cgi()->cookie('-name'  => 'SessionID',
>                                               '-value' => $session_id,
>                                               '-path'  => $me );
>             @cookie = ('-cookie' => $cookie);
>          }
>          else
>          {
>             $treq->install_directive('session_id', $session_id);
>          }
>
>       }
>
>       html_page($treq, $treq->config('get_template'),@cookie);
352a492,493
>       @fields = grep {!($treq->config('session_field',0)
>                    and ($_ eq $treq->config('session_field',''))) }
@fields;
997c1138
< =item html_page ( TREQ, TEMPLATE )
---
> =item html_page ( TREQ, TEMPLATE, EXTRA )
999c1140,1141
< Outputs an HTML page using the template TEMPLATE.
---
> Outputs an HTML page using the template TEMPLATE.  EXTRA is an array
that is
> passed directlyn to L<html_header>.
1005c1147
<    my ($treq, $template) = @_;
---
>    my ($treq, $template, @extra) = @_;
1007c1149
<    html_header();
---
>    html_header(@extra);
1063c1205
< =item html_header ()
---
> =item html_header (EXTRA)
1065c1207,1209
< Outputs the CGI header using a content-type of text/html.
---
> Outputs the CGI header using a content-type of text/html. The optional
> argument EXTRA comprise an array of key/value pairs that will be
passed
> directly to header() method of the CGI module.
1069a1214
>     my @extra = @_;
1072c1217
<         print header('-type'=>'text/html', '-charset'=>CHARSET);
---
>         print header('-type'=>'text/html', '-charset'=>CHARSET,
@extra);
1077c1222
<         print header('-type' => "text/html; charset=@{[ CHARSET ]}");
---
>         print header('-type' => "text/html; charset=@{[ CHARSET ]}",
@extra);

This adds the ability (in association with the GET handling facility
added earler) to create a session  that means that the POSTed request is
as the result of the submission of a form that was generated by a GET
request.  The ability to use either cookies or a hidden field to convey
the session id is included.

Can people check this (and the README ) out - I intend to make a release
of this (and the previously added and not released stuff) in the next
couple of days.

/J\

[Nms-cgi-devel] Re: [Nms-cgi-support] referrer problem

[Jonathan S. <jn...@ge...>]

On Mon, 2004-08-23 at 09:03, John wrote:
> We are using your script for form to email feedback and we are
> receiving results. However our web stats show that the cgi script is
> not being called - but we are receiving form results. 
> A recent example= We received 7 form results but web stats show the
> script was only visited /used twice. 
> Script is set to 1 referer and allow to 1 recipient. Allow empty
> referer is set to 1 becuase of firewalls so effectively we cant check
> referers. How can we control to only allow form results from our site.

It would probably be useful to see the http logs for the accesses to
FormMail that you don't believe originated on the site as well as
examples of the messages that you think are being sent from elsewhere.

Unfortunately the referer check is not particularly secure because it is
trivially spoofed by even the simplest custom client (such as spammers
might use), this is why TFmail doesn't even include such a check.  It is
unlikely that FormMail will ever be given any more secure method of
checking the origin of the request, however it is possible that we may
consider adding some functionality to the TFmail to ensure that the
request comes from a controlled page - this could be implemented by
having the program itself generate the form page (TFmail currently
allows the creation of a templated page to be displayed on a GET
request) and send some token (such as a cookie or hidden field value)
which can only be used once and will be sent back to the TFmail on form
submission, thus ensuring with a relatively high degree of confidence
that the submission was from your form.  Unfortunately we do not have
this functionality available currently, but I would recommend that you
consider a switch to TFmail as this is where we are putting all our
development effort.  I have copied the developers list in case anyone
has got a better idea about how to go about this and the time to
implement it.

/J\

[Nms-cgi-devel] Re: [Nms-cgi-commits] CVS Commit

[Jonathan S. <jn...@ge...>]

On Fri, 2004-08-20 at 09:00, Jonathan Stowe wrote:
> uid=68026(gellyfish) gid=100(users) groups=100(users),40625(nms-cgi),7054(xmlxslt)
> tfmail README,1.28,1.29 TFmail.pl,1.25,1.26
> Fri Aug 20 01:00:16 PDT 2004
> Update of /cvsroot/nms-cgi/tfmail
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15714
> 
> Modified Files:
> 	README TFmail.pl 
> Log Message:
> * Added recipient_input
> * Added no_content
> 

The intent of these changes is to allow TFmail to be used as a
"Recommend this Page" type of thing, this means that it needs to accept
an arbitrary address for the recipient, generally this would be a bad
thing.  What I have done is fix things so that if the recipient_input
field is defined in the .trc then all of the templating directives are
removed from the template for the main email (so attempting to use any
will give rise to an error), this will of course still allow TFmail to
be used to potentially mailbomb someone (but of course it could already
do that if the confirmation mail was being sent.) but it can't (or
shouldn't be able to) be used for sending a spammers content.

The second change is just so that it will emit a 204 status if
no_content is set to 1 so the page is not updated, I don't believe there
are any security considerations with this.

I would really like it if as many people as possible could cast their
eyes over the code and do some testing as I don't really want to do a
release unless we are fairly content that no new security holes have
been introduced.

While you are looking at the code, any refactoring would be welcome.  I
have been hacking on TFmail in the hotel bar while the battery holds out
which rather militates against elegance of design.

/J\

[Nms-cgi-devel] Re: TFmail - Customizing Missing Template

[Jonathan S. <jn...@ge...>]

On Thu, 2004-08-19 at 11:57, Lydia Yang wrote:
> Johnathan,
> 

Please direct all support requests for NMS programs to the
nms...@li... this will ensure that you get the
fastest and best response possible.

> The missing template spits out the form name on the
> html page.  Is there is way to customize it so that it
> spits out something else?
> 
> For example, I have a required field named
> "billingaddressline1".  If this is left blank, the
> missing template will say that the
> "missingaddressline1" is a required field.  How can I
> get it to say "Billing Address Line 1"?
> 
> Also, if I give the same field a hidden name, how can
> I get the missing fields page to show the hidden name
> instead of the form name?  Does it involve changing
> the {= name =} directive to something else?  If yes,
> what should it be?  Thanks.
> 

I'm afraid that there is no easy way to do this as TFmail (as any other
CGI program) has no way of knowing the form fields label name other than
by having some lookup.

I have copied this to the developers list in case anyone else has any
bright ideas.

/J\

[Nms-cgi-devel] RE: [Nms-cgi-support] TFMail features

[JW <li...@so...>]

Thanks for the feedback.

Looking forward to any guidance regarding this.


With Regards - Jaime


-----Original Message-----
From: Jonathan Stowe [mailto:jn...@ge...] 
Sent: Tuesday, 17 August 2004 7:57 PM
To: NMS-CGI-Support
Cc: Jaime; NMS Devel
Subject: Re: [Nms-cgi-support] TFMail features

On Tue, 2004-08-17 at 12:00, Dave Cross wrote:
> On Tue, Aug 17, 2004 at 11:42:34AM +0100, Jonathan Stowe wrote:
> > On Tue, 2004-08-17 at 03:52, Jaime wrote:
> > > I wanted to have a 'Recommend Sites' form for people to recommend
> > > the websites to their friends.
> > >  
> > > It will have a predefined message to be sent to the recommended
> > > friends' email.
> > >  
> > > The sender will specify the receiver's email in the form. 
> > >  
> > > Can TFMail do it? If yes, are there any examples?
> > 
> > TFmail (as well as NMS FormMail) is specifically designed NOT to be
> > able to send e-mail to arbitrary addresses specified by a web user, if
> > it were able to do this then it could be used as a gateway for spam.
> 
> Ah, but if it was a "predefined message" then that would be ok
> wouldn't it? Or am I missing something?

It would be a change to TFmail but you could have predefined messages
sent to arbitrary people by adding a recipient_field item to the
configuration, if this is present then ALL user supplied fields (except
perhaps email ) are turned off in the templates and the only form fields
that TFMail will do anything with are the defined recipient field and
the _config - this could work for a "recommend this page" type
application I guess.  For this kind of thing (as I have usually seen
them anyway) you would probably want the ability to send a 204 ('No
Content') status rather than a success page.  If I get bored later I
might take a look at this.

/J\

[Nms-cgi-devel] Re: [Nms-cgi-support] TFMail features

[Jonathan S. <jn...@ge...>]

On Tue, 2004-08-17 at 12:00, Dave Cross wrote:
> On Tue, Aug 17, 2004 at 11:42:34AM +0100, Jonathan Stowe wrote:
> > On Tue, 2004-08-17 at 03:52, Jaime wrote:
> > > I wanted to have a 'Recommend Sites' form for people to recommend
> > > the websites to their friends.
> > >  
> > > It will have a predefined message to be sent to the recommended
> > > friends' email.
> > >  
> > > The sender will specify the receiver's email in the form. 
> > >  
> > > Can TFMail do it? If yes, are there any examples?
> > 
> > TFmail (as well as NMS FormMail) is specifically designed NOT to be
> > able to send e-mail to arbitrary addresses specified by a web user, if
> > it were able to do this then it could be used as a gateway for spam.
> 
> Ah, but if it was a "predefined message" then that would be ok
> wouldn't it? Or am I missing something?

It would be a change to TFmail but you could have predefined messages
sent to arbitrary people by adding a recipient_field item to the
configuration, if this is present then ALL user supplied fields (except
perhaps email ) are turned off in the templates and the only form fields
that TFMail will do anything with are the defined recipient field and
the _config - this could work for a "recommend this page" type
application I guess.  For this kind of thing (as I have usually seen
them anyway) you would probably want the ability to send a 204 ('No
Content') status rather than a success page.  If I get bored later I
might take a look at this.

/J\

[Nms-cgi-devel] Re: [Nms-cgi-support] textarea carriage return breaks TFmail log file2

[Jonathan S. <jn...@ge...>]

On Sat, 2004-08-14 at 14:40, Mirza yousaf Baig wrote:
> Hi
> I am using textarea in my form which is processes by TFmail.pl and 
> results are logged/emailed. If user format lines in textarea by using 
> carriage return then this formatting is preserved in the email which is 
> perfectly Ok. On the other hand this formatting breaks lines in log file 
> too. I want to log results of each submission in one line. Is there any 
> way that carriage return from form data are removed when they are saved 
> in log file. I want to keep them in email or success page but want to 
> remove only from log file.

Currently there is no simple way of doing this without changing the code
of TFmail - I have copied the developers list in case anyone has a
better idea of how this might be done, or alternatively volunteer to
make a change in the program to support it properly.

YOu might consider using an alternative template for your logfile, that
uses some other character than a newline to indicate the end of a record
- for instance you could write then lines out like an HTML table.

/J\

[Nms-cgi-devel] [ nms-cgi-Support Requests-1008517 ] textarea carriage return breaks TFmail log file

[SourceForge.net <no...@so...>]

Support Requests item #1008517, was opened at 2004-08-12 22:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1008517&group_id=39625

Category: Install Problem (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: textarea carriage return breaks TFmail log file

Initial Comment:
Hi
I am using textarea in my form which is processes by
TFmail.pl and results are logged/emailed. If user
format lines in textarea by using carriage return then
this formatting is preserved in the email which is
perfectly Ok. On the other hand this formatting breaks
lines in log file too. I want to log results of each
submission in one line. Is there any way that carriage
return from form data are removed when they are saved
in log file. I want to keep them in email or success
page but want to remove only from log file.

cheers
Mirza

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1008517&group_id=39625

[Nms-cgi-devel] Re: [Nms-cgi-support] FormMail.pl - email header From line is malformed

[Jonathan S. <jn...@ge...>]

On Mon, 2004-08-09 at 13:17, Jonathan Stowe wrote:
> I've copied this to the developers list in case anyone has the time to
> make the change, document it and then do a release.
> 
> On Fri, 2004-08-06 at 20:17, Brett Johnson wrote:
> > I guess you're right about the formatting, so this will take a slight turn here.
> > 
> > Just because you CAN doesn't mean you SHOULD.
> > 
> 
> Oh, I'm with you there - on further inspection it appears that we
> inherited the format of the e-mail address from the MSA FormMail that
> ours is intended to replace.  I would have suggested that you look at
> the NMS TFmail which is really where the focus of our development is
> going as far as Form to Email programs - but I see that this has the
> same formatting as well.  I think what we would like to do would be to
> make the formatting optional, so that we could have by default the
> current style and by altering the configuration the more conventional
> "Display Name <address>" format (the option being disabled when
> $emulate_matts_code is set to true).  Of course somebody may have a
> better idea.
> 

I have just uploaded a new version of FormMail that includes the ability
to choose which style of address you want to use.  It is all fully
documented in the README.

/J\