RE: Is it a security risk to use identical names for database fields and html forms?
At 12:53 PM 9/3/2001 +0100, yahoo wrote: >Hi Gunther, >yes, you are right - maybe my answer was a bit flippent - it was only meant >to be a conversational addition to the thread rather than a definitive >answer ;-) > >By "access to the DB" I meant a valid SQL login. > >I enjoyed reading that URL you posted. Seeing the SQL being returned to the >web user for his/her inspection is certainly a most worrying situation! Once >again it reinforces the golden rule that you should NEVER trust (or make >unfounded assumptions about) user input. > >I think that dynamically created SQL statements (such as in the norm in >MySQL) are very vulnerable to this kind of attack in contrasts to, say, >using stored procedures. > >I enjoyed reading your post :-) Thanks! I also gave a talk on these issues at this past year's ApacheCon. I've placed the slides are up here: http://www.extropia.com/presentations/cgi_security_history.html Since me and Selena Sol have been around giving out open source web apps since 8 years ago (very early on the Web), we've of course seen the gamut of security holes, including those within our own past software. So this talk was really an attempt (within a tiny 45 minute talk) of going through common problems from a long time ago and linking them up to problems that are more recent and have gotten little publicity but 2 years down the road may be as "rote" as knowing that filenames need to be filtered. There's actually quite a bit of interesting stuff out there that has really only been "discovered" and publicized at all in the last year or two. Null byte is another huge issue few Perl programmers seem to know about/understand as it affects the file open() command in a subtle way yet I think it is not described in perldoc perlsec (it seems mostly focused on tainting and general validation issues). >joel > >-Original Message- >From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] >Sent: 02 September 2001 01:15 >To: yahoo; [EMAIL PROTECTED] >Subject: RE: Is it a security risk to use identical names for database >fields and html forms? > > >At 02:29 PM 8/31/2001 +0100, yahoo wrote: > >nah! > > > >what difference does it make? > > > >I mean, if they guy gets access to your DB server then he's gonna find out > >the fieldnames anyway! > > > >If he can't get access to your DB then what has he got?, a few POSSIBLE DB > >field names (i mean, how does HE know the names are real?) for him to > >attempt to recreate fragments of the data model pah! best of luck... > > > > > >joel > >Joel, while I do think that this is a nice succinct reply to the thread, I >am not sure that it really uncovers the entire problem. It's a bit hard to >understand what you mean in your post as you don't really qualify the >phrase "access to the DB". Sure, if I have a TCP stream to mySQL, it's >possible to get anything. > >But "access to a database" through exploiting CGI is not always perfect and >therefore being able to glean extra information is helpful to any cracker >on the system. I do firmly believe that restricting the information you >give the user about your system will help security, but I also think it is >a matter of diminishing returns and would rather the user who asked the >question focus on the things I highlighted in my post yesterday (eg quoting >issues, data validation, etc). > >If the SQL is exploitable, then mucking about with the fields whose values >are obvious candidates for being sent to the database makes a difference. >But further, it does make a difference to know about the field naming when >it comes to extrapolating how to generate the rest of the query. > >Do you really think that this is inconceivable? The following URL is a >well-written account of rain forest puppy hacking into a BBS forum software >by exploiting it's error handling routines to gather some bits of >information about how the queries are being created and exploiting that >information through the CGI script. > >http://www.wiretrip.net/rfp/p/doc.asp?id=42&iface=2 > >Since I read this article and then in reviewing the security of other CGI >scripts, I have found exploitable SQL code in at least several places. I >guarantee that bad SQL coding is a problem for sure in the latest CGI >scripts. But the degree varies from application to application. > >Just as seeing one cockroach in a kitchen actually entails a million more >behind the walls, since reviewing CGI security is not a full time job for >me (just an occasional if someone asks me), the fact I have seen this much >exploitable code is an indicator to me that the problem is currently quite >huge. > >In summary, I would heartily encourage careful best practices for SQL >coding in Perl as I indicated yesterday and as RFP describes in the URL I >gave above. And I would agree that the form variable changing names is >probably not that useful to avoid attack, but I would not agree that it's >entirely useless. > >I think risk assessment is a reasonable thing for th
Re: Help me !
I'm not sure the other answers you have had address all the problem. They have all addressed the problem of (possibly multiple) whitespace (\s) at the end of a line. You have asked to remove all the newline characters in a string. I would propose $string =~ s/\n//g; The s does a substitute; the \n is a newline character; the // contains nothing, and achieves the removal; the g find all the occurrences; The end result may not be what you want, hence the advice elsewhere to get rid of carriage returns (\r). Regards - Roger - - Original Message - From: "Pirabakaran Kunaratnam" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 05, 2001 8:45 PM Subject: Help me ! > Hi People, > > I need to remove all new line character from a string. Can you please > let me know. This is to use for > a flat file. When i try to store from a textarea input to a flat file, > it has many new line character from the input. Therefor, when retrieve > them back from the flat file the data order are messed up. So please > help me with this. Thanks. > > Piraba > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it a security risk to use identical names for database fields and html forms?
--- Gunther Birznieks <[EMAIL PROTECTED]> wrote: > There's actually quite a bit of interesting stuff out there that has really > only been "discovered" and publicized at all in the last year or two. Null > byte is another huge issue few Perl programmers seem to know > about/understand as it affects the file open() command in a subtle way yet > I think it is not described in perldoc perlsec (it seems mostly focused on > tainting and general validation issues). If anyone's unfamiliar with the null byte problem, I have a brief description of it at http://www.perlmonks.org/index.pl?node_id=38548. Cheers, Curtis "Ovid" Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
File Types
Hi Guys, This is probably not a CGI question but I'm hoping someone here has run into this same problem before and can shed some light: I'm using CGIpm to do stuff with tab delimited text files that were uploaded via web page form. I have a spreadsheet with all my info on it (i test using both StarOffice and Excel), and I "save as" tab delimited text file and then upload through my web interface to my script. Now here's where the problem comes in, my script will only accept files that are "plain/text" (which I know these are) but they will come in as "application/octet-stream" occasionally and will not go back to being "plain/text" unless I reboot my Windows machine. Does this sound familiar to anyone? ::Jon -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SendMail to lists
I am trying to develop a page to allow people on a list that I am a member of to subscribe and unsubscribe by clicking a link. The link spawns a window that allows the user to type in their email address. When they do that they can submit the form. Sendmail seems to be replacing certain parts of the email header with its own info (specifically the From field). The Email server for the list will only allow emails from the person's address to unsubscribe them. Here is the code that is piped to Sendmail: my $To = '[EMAIL PROTECTED]'; #prepare message $msg = qq|To: list-serv\@domain.com Subject: #$Action = (un)Subscribe, $list = the email list, $To is the server info. $Action $List $To|; #end list-serv message #send it to the mail server open (SENDMAIL, "| /usr/lib/sendmail -t -i -f'$UserName'") || die "Can't open Sendmail: $!"; print SENDMAIL $msg; close SENDMAIL; Any ideas? Do I need to send more info? Randy Peterman -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weekly list FAQ posting
NAME beginners-faq - FAQ for the beginners-cgi mailing list 1 - Administriva 1.1 - I'm not subscribed - how do I subscribe? Send mail to <[EMAIL PROTECTED]> You can also specify your subscription email address by sending email to (assuming [EMAIL PROTECTED] is your email address): <[EMAIL PROTECTED]>. 1.2 - How do I unsubscribe? Now, why would you want to do that? Send mail to <[EMAIL PROTECTED]>, and wait for a response. Once you reply to the response, you'll be unsubscribed. If that doesn't work, find the email address which you are subscribed from and send an email like the following (let's assume your email is [EMAIL PROTECTED]): <[EMAIL PROTECTED]> 1.3 - There is too much traffic on this list. Is there a digest? Yes. To subscribe to the digest version of this list send an email to: <[EMAIL PROTECTED]> To unsubscribe from the digest, send an email to: <[EMAIL PROTECTED]> 1.4 - Is there an archive on the web? Yes, there is. It is located at: http://archive.develooper.com/beginners-cgi%40perl.org/ 1.5 - How can I get this FAQ? This document will be emailed to the list once a month, and will be available online in the archives, and at http://beginners.perl.org/ 1.6 - I don't see something in the FAQ, how can I make a suggestion? Send an email to <[EMAIL PROTECTED]> with your suggestion. 1.7 - Is there a supporting website for this list? Yes, there is. It is located at: http://beginners.perl.org/ 1.8 - Who owns this list? Who do I complain to? Casey West owns the beginners-cgi list. You can contact him at [EMAIL PROTECTED] 1.9 - Who currently maintains the FAQ? Kevin Meltzer, who can be reached at the email address (for FAQ suggestions only) in question 1.6 1.10 - Who will maintain peace and flow on the list? Casey West, Kevin Meltzer and Ask Bjoern Hansen currently carry large, yet padded, clue-sticks to maintain peace and order on the list. If you are privately emailed by one of these folks for flaming, being off-topic, etc... please listen to what they say. If you see a message sent to the list by one of these people saying that a thread is closed, do not continue to post to the list on that thread! If you do, you will not only meet face to face with a XQJ-37 nuclear powered pansexual roto-plooker, but you may also be taken off of the list. These people simply want to make sure the list stays topical, and above-all, useful to Perl/CGI beginners. 1.11 - When was this FAQ last updated? May 31, 2001 2 - Questions about the 'beginners-cgi' list. 2.1 - What is the list for? A list for beginning Perl programmers to ask questions in a friendly atmosphere. The topic of the list is, of course, CGI with Perl. 2.2 - What is this list _not_ for? * SPAM * Homework * Solicitation * Things that aren't Perl related * Non Perl/CGI questions or issues * Lemurs 2.3 - Are there any rules? Yes. As with most communities, there are rules. Not many, and ones that shouldn't need to be mentioned, but they are. * Be nice * No flaming * Have fun 2.4 - What topics are allowed on this list? Basically, if it has to do with Perl/CGI , then it is allowed. If your question has nothing at all to do with Perl/CGI, it will likely be ignored. 2.5 - I want to help, what should I do? Subscribe to the list! If you see a question which you can give an idiomatic and Good answer to, answer away! If you do not know the answer, wait for someone to answer, and learn a little. 2.6 - Is there anything I should keep in mind while answering? We don't want to see 'RTFM'. That isn't very helpful. Instead, guide the beginner to the place in the FM they should R :) 2.7 - I don't want to post a question if it is in an FAQ. Where should I look first? Look in the FAQ! Get acquainted with the 'perldoc' utility, and use it. It can save everyone time if you look in the Perl FAQs first, instead of having a list of people refer you to the Perl FAQs :) You can learn about 'perldoc' by typing: `perldoc perldoc' At your command prompt. You can also view documentation online at: http://www.perldoc.com and http://www.perl.com 3 - Other Resources 3.1 - What other websites may be useful to a beginner ? * Perl Home Page - http://www.perl.com * PerlMonks - http://www.perlmonks.org * Perldoc - http://www.perldoc.com * Perl Archives - http://www.perlarchives.com 3.2 - What resources may be harmful to a beginner? Anything having to do with the names Matt Wright, or Selena Sol. Why? You may ask yourself. Well, their scripts are old and have been known to be buggy, as well as have security issues. They were written in the days of Perl 4. This means there is no scoping, stricture, warnings, idioms,
Re: SendMail to lists
--- randy Peterman <[EMAIL PROTECTED]> wrote: > I am trying to develop a page to allow people on a list that I am a member > of to subscribe and unsubscribe by clicking a link. The link spawns a > window that allows the user to type in their email address. When they do > that they can submit the form. Sendmail seems to be replacing certain parts > of the email header with its own info (specifically the From field). The > Email server for the list will only allow emails from the person's address > to unsubscribe them. Here is the code that is piped to Sendmail: > > my $To = '[EMAIL PROTECTED]'; > #prepare message > $msg = qq|To: list-serv\@domain.com > Subject: > #$Action = (un)Subscribe, $list = the email list, $To is the server info. > $Action $List $To|; > #end list-serv message > > #send it to the mail server > open (SENDMAIL, "| /usr/lib/sendmail -t -i -f'$UserName'") || die "Can't > open Sendmail: $!"; > print SENDMAIL $msg; > close SENDMAIL; > > Any ideas? Do I need to send more info? > > Randy Peterman Randy, Rather than trying to use SENDMAIL, try one of the CPAN modules like Net::SMTP or something similar. It's easy to use and ensures greater code portability. I have to ask: where are you getting the $UserName value? What you are trying to do raises some serious security issues if done incorrectly. Cheers, Curtis "Ovid" Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMail to lists
>I have to ask: where are you getting the $UserName value? What you are trying to do raises some >serious security issues if done incorrectly. I am getting it from a form input. I am hard coding the "to" line so that I do not have to worry about spammers just using my page as a portal. Also they are registered users with cookies and passwords to authenticate things so that there should be very little chance that anything should be relayed by accident. then the list is checked to see if the person can post or not (its a private list) and then if they can post then, they get to be subscribed or unsubscribed. I'll take a look at one of the modules and try that out. Thanks for your help. Randy -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMail to lists
--- randy Peterman <[EMAIL PROTECTED]> wrote: > >I have to ask: where are you getting the $UserName value? What you are > trying to do raises some > >serious security issues if done incorrectly. > > I am getting it from a form input. Randy, The problem with that is untainting an email address (see "perldoc perlsec") is *very* difficult to do correctly. Let's say that the input box is named "UserName". If you make any mistakes validating that information, you can open up your script to a HUGE security hole by allowing user data near the shell. Consider the following URL: http://www.somehost.com/cgi-bin/mail.cgi?[EMAIL PROTECTED]'%3brm%20-fr%20*%3b Your shell command then becomes: /usr/lib/sendmail -t -i -f'[EMAIL PROTECTED]';rm -fr *; Admittedly, I'm not a Unix security expert, but I suspect that this will have undesirable effects :) Playing around with that for a while should allow the cracker to have all sorts of :fun. > I am hard coding the "to" line so that I > do not have to worry about spammers just using my page as a portal. Also > they are registered users with cookies and passwords to authenticate things > so that there should be very little chance that anything should be relayed > by accident. Cookies and passwords are very easy to sniff, social engineer, etc. You're using SSL to afford minimal protection, yes? > then the list is checked to see if the person can post or not > (its a private list) Good! Then you should already have their email address. Rather than accepting $UserName from the form input, validate the user and, if valid, grab their email from your internal data (which hopefully is secure) and use *that* email. Cheers, Curtis "Ovid" Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMail to lists
At 01:48 PM 9/6/2001 -0700, Curtis Poe wrote: >--- randy Peterman <[EMAIL PROTECTED]> wrote: > > >I have to ask: where are you getting the $UserName value? What you are > > trying to do raises some > > >serious security issues if done incorrectly. > > > > I am getting it from a form input. > >Randy, > >The problem with that is untainting an email address (see "perldoc >perlsec") is *very* difficult >to do correctly. Let's say that the input box is named "UserName". If >you make any mistakes It is not so bad to do if you just filter on the basic characters you want and leave out shell metas. I have a sample regex in my taintmode FAQ (http://www.extropia.com/tutorials/taintmode.html), but as others have pointed out, it doesn't allow the entire correct universe of email addresses to go through precisely because shell meta characters ARE valid in email addresses. However, I consider this situation quite rare. Note that a TRUE regex to filter whether an email address is valid is HUGE and takes up well over a page of text in O'Reilly's book on Regular Expressions by Jeffrey Friedl (sp?). But I would consider this overkill in most situations. >validating that information, you can open up your script to a HUGE >security hole by allowing user >data near the shell. Consider the following URL: > > >http://www.somehost.com/cgi-bin/mail.cgi?[EMAIL PROTECTED]'%3brm%20-fr%20*%3b > >Your shell command then becomes: > > /usr/lib/sendmail -t -i -f'[EMAIL PROTECTED]';rm -fr *; > >Admittedly, I'm not a Unix security expert, but I suspect that this will >have undesirable effects >:) Playing around with that for a while should allow the cracker to have >all sorts of fun. Yes it would. However, I do believe sendmail is a perfectly acceptable way of sending mail, but it should be done properly. I have rarely seen the need to send email addresses on the command-line with sendmail. Randy should be able to just do something like IPC::Open3::open3(*OUT, *IN, *ERR, "$path -t"); my $mail = qq[To: $to From: $from Replyto: $replyto Cc: $cc Bcc: $bcc Subject: $subject $body ]; print OUT $mail; close (OUT); close (IN); close (ERR); Where $path is the path to sendmail. This makes sure you send all your addresses through the STDIN stream rather than the command-line. The STDIN stream is not interpreted by the shell so there is no problem. Note that I like to use IPC::Open3 which is fairly cross platform (even on Windows Perl -- although sendmail doesn't exist there) and allows you to capture the errors and output from sendmail if you want to debug why sendmail isn't working. Otherwise just opening with a open() plus the pipe symbol only lets you send input into the program but doesn't easily allow you to read the output without resorting to nasty temp files. [Sendmail As A Valid Choice To Send Mail] To me, the disadvantage of sendmail is that it launches an extra process. But there are two pros which make command-line sendmail quite useful to a CGI programmer. 1) As a CGI developer, I can be pretty certain that 90% of the ISP servers I install my CGI script on will just magically "work", because the sendmail binary (including pseudo binaries that come with alternate servers like qmail) will automagically KNOW the right SMTP server IP address etc. without having to do ANY script configuration. This is a huge win in maintenance. 2) When you give Net::SMTP an SMTP address that is currently down what do you do? Just error out your application? Generally emails are not mission critical but are rather notifications which can be selectively delayed. If you send mail using the sendmail binary, even if the SMTP server it connects to is down, the sendmail binary can keep the message in a queue and keep retrying to send it long after your CGI script has delivered its HTML response payload back to the client. > > I am hard coding the "to" line so that I > > do not have to worry about spammers just using my page as a portal. Also > > they are registered users with cookies and passwords to authenticate things > > so that there should be very little chance that anything should be relayed > > by accident. > >Cookies and passwords are very easy to sniff, social engineer, >etc. You're using SSL to afford >minimal protection, yes? > > > then the list is checked to see if the person can post or not > > (its a private list) > >Good! Then you should already have their email address. Rather than >accepting $UserName from the >form input, validate the user and, if valid, grab their email from your >internal data (which >hopefully is secure) and use *that* email. I wholeheartedly agree with this assessment. Definitely the best solution is to hard-code the $to address inside of a configuration variable as opposed to allowing it to change based on form input. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PRO
Script compliation Sequence.
Hello EveryBody I needed some advice for all. I am working on a untilty which needs to perform server functions. I am bit confused with compliation sequency of scripts, when we use "do", "require" or "use" to include into our scripts. I have written a library file which contains all the common routines, and include this in evey other script i write. This file is very very long running around 3000 lines. But most of the scripts use around 10% of the libraray routines only. As per my understanding when ever any script is invoked it will complie both the script and the included files. This is done each time the script is invoke. I would like to know if I can group this subroutines into different files and include only the relevant routines an and when required depending upon coditions at runtime. This will keep the files size to be less and will also avoid unnecessary compilation time. with regards Rajeev Rumale That means I Since not every sub routine is required -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Urgent !!! installing Storable.pm
Hi, I need to install and use the Storable.pm in my machine. I am useing Active Perl on Win2k machine. I have not done this before. Its urgent, kindly let me know the procedure for same. rajeev
Re: Script compliation Sequence.
At 11:19 AM 9/17/2001 +0800, Rajeev Rumale wrote: >Hello EveryBody > >I needed some advice for all. > >I am working on a untilty which needs to perform server functions. > >I am bit confused with compliation sequency of scripts, when we use "do", >"require" or "use" to include into our scripts. > >I have written a library file which contains all the common routines, and >include this in evey other script i write. > >This file is very very long running around 3000 lines. But most of the >scripts use around 10% of the libraray routines only. Well, considering that CGI.pm is 6400 lines long and that includes yet other modules etc, I don't know if you should be worried about 3000 lines. However, if most scripts use only 10% of the library routines, you might consider looking into a feature called AUTOLOAD and require the second library to instantiate the routines that are called less often. >As per my understanding when ever any script is invoked it will complie both >the script and the included files. This is done each time the script is >invoke. Not necessarily. use is always loading the modules at compile time. But require is only hit at run-time so you can selectively break up your library and only require the library or module "on-demand". AUTOLOAD is something you should look into though. >I would like to know if I can group this subroutines into different files >and include only the relevant routines an and when required depending upon >coditions at runtime. > >This will keep the files size to be less and will also avoid unnecessary >compilation time. You should definitely consider refactoring a little bit to make sure that routines that are alike are grouped together. However, IMHO refactoring the library code just on how often the routines are called is not good in the long term. I appreciate that you want to improve the performance of your CGI, but 300 lines of code versus 2700 lines of code being loaded later is not going to make a big difference to the overall performance when you consider the many other libraries you are probably loading (and may not even know it!). Second, refactoring based on how often the code is used rather than based on grouping them by like-task will be guaranteed to make your life a headache as you add and subtract routines as your requirements change for what the application is supposed to do (and any good program will change over time). If performance is really your primary concern, I would sooner recommend that you split your code up by like functions, not for "loading time" and then for performance increase use mod_perl, Speedy::CGI or any other number of environments that can compile your code once but just keep it in memory for the future. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Urgent !!! installing Storable.pm
At 01:08 PM 9/17/2001 +0800, Rajeev Rumale wrote: >Hi, > >I need to install and use the Storable.pm in my machine. I am useing >Active Perl on Win2k machine. > >I have not done this before. Its urgent, kindly let me know the procedure >for same. > >rajeev Really, you should consider subscribing to the beginner-perl list for this sort of question and not the beginner-cgi list. The short answer to your "urgent" question is that you should read the ActiveState documentation on downloading modules. It's really easy, just run ppm. Perl Package Manager. C:\> ppm PPM> install Storable Blah blah blah about how it is installing storable PPM> quit And voila. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: problem with using HTML::FormValidator
> -- Forwarded Message
> From: "Maryana Osipchuk" <[EMAIL PROTECTED]>
> When I try using this one (as constraint rule - my own function)
> --
> p1 => {
> constraints => valid_equiv,
> params => [qw (p1 p2)]
> }
> valid_equiv as &main::valid_equiv
> --
> I receive an error(something like that):
> 'Undefined subroutine &HTML::FormValidator::valid_ called at
> C:/Perl/lib/HTML/FormValidator.pm line 401'
Hello Maryana,
First, if you just learning HTML::FormValidator, I suggest looking into
Data::FormValidator. It contains all the old functions plus a few new features.
In your case, I think your solution may be found an example in the
documentation which looks like this:
{
customer_infos => {
constraints => {
cc_no => { constraint => "cc_number",
params => [ qw( cc_no cc_type ) ],
},
}
}
# cc_no is the field name with the constraint
# cc_number is the custom function
-mark
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
