Re: taint question
Reactor wrote:
I am fairly new to perl, so this is probably looks like a silly question:
I am trying to write text to a file as specified by the query string
environment variable. Since the file names are all numbers, I'm using a
regex to strip anything other than a digit from the variable, and assign the
new value to a variable. I've R-ed a few different FM's for the way to do
this, and it says to use the regex memory value, which isn't tainted. When
I try this using my current regex it leaves the $1 variable undefined. Code
snipet:
@temp = split(/=/, $ENV{'QUERY_STRING'});
$temp[0] =~ s/([^0-9])//g;
$filename = $1;
I made a sort of mini-debug function that prints out each variable. It
prints the unprocessed query string after spliting and the value of $temp[0]
after processing (which is all numbers) correctly, but the variable
$filename doesn't have a value... Not sure where I went wrong with this...
Unless the $1 is null because the matched pattern is deleted... or does the $1 hold the return value?
I'm not going to answer your question the way you asked because well, I
don't claim to be a Perl guru and in many cases my style of coding will
assure I probably never become one. ;)
What do I mean by this?
I guess I am a bigger fan of clear code. I think that Perl is an
exquisite language with neat side effects and ways to do several things
with one statement.
But in the end, I have to say, that personally, I much prefer if someone
doesn't code using "double meaning" and instead breaks it into more
lines so that it is more readable like a book.
How does this relate to your question?
Well, I guess it relates because I think I wouldn't write the code the
same way. Let's look at it ...
> @temp = split(/=/, $ENV{'QUERY_STRING'});
> $temp[0] =~ s/([^0-9])//g;
> $filename = $1;
Line 2 says that you are not only trying to get $1, but you are also
performing this substitution operation for some reason (perhaps there is
something else about this variable that you want to keep left over?)
I would rewrite the above to be closer to the following (style wise)
@http_form_input = split(/=/, $ENV{'QUERY_STRING'});
# explicitly check for the first complete string of digits in the
# http form input
if ($http_form_input[0] =~ /([0-9]+)/) {
$filename = $1;
} else {
die("Filename consisting of numbers expected but not found");
}
# strip away anything that is not a digit just as before
$http_form_input[0] =~ s/[^0-9]//g;
Here there are a couple things to note:
1. Variable names like @temp is not that descriptive in saying what you
are actually trying to extract or do.
Note: It is possible one bug in your code (and hence also in mine) is
that you are performing the search/replace on the 0th element. But what
is the 0th element? If your form submission was filename=343242
Then the 0th element will equal the string "filename" not the string
"343242" so you are doing the operation on the wrong element. Maybe you
should be doing it on $http_form_input[1]??
This is why it tends to be nicer to use libraries like CGI.pm to do your
query string processing for you. It's hard to make a mistake like this
(if indeed this was a mistake) than when you manually deconstruct the
query string.
Also, CGI.pm can transparently hide the difference between whether the
variable was POSTed, GETed, or is interpreted via Mod_perl. So your
script can automatically work in many more environments.
2. I separate the operation of untainting from the operation of search
and replace.
In fact, this may also be a place where you have a bug. Your search and
replace is removing all non digits. But what you actually want $1 to
contain only digits.
So the regex that returns only digits is very different from the regex
that destroys digits via search/replace.
Because you were attempting to do two things, one of the operations
worked, but you got confused about why the 2nd one didn't work
(untainting). The reason they don't work is that they aren't the same
operation, so attempting to combine them as one actually did not work
for you...
By separating your operations, things can be made cleaner and easier to
interpret when you go back to look at your own code or it comes down to
debugging.
Anyway, go ahead and do whatever you want... It's not my place to
"preach", but hopefully I have answered your question about why the
original code wasn't doing what you wanted, even if I answered it in a
roundabout way.
Good Luck...
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: portability question...IIS Vs. Apache
IIS thinks the CWD is the root directory of the script alias. Just set
up a script alias that points to the directory where the cgi actually is
and you'll be fine.
Peter Kappus wrote:
Hey all,
Anyone move scripts between IIS and Apache or need to write scripts that
work on both? The problem I'm facing is that IIS reports the current
working directory (CWD) as the root dir of the "application" as defined in
the IIS control panel while apache reports the CWD as the actual directory
of the script file itself.
This is a problem when including other files/modules...
For example, to include "/myApp/func.pl" from "/myApp/index.pl":
require "func.pl";#works fine in Apache but not IIS
require "/myApp/func.pl"; #works for IIS
ditto for modules:
require "myMods::myModule.pm";#works in Apache
require "myApp::myMods::myModule.pm"; #works in IIS
aarrggh. I'd rather not add a big block like:
if(-e "func.pl"){
require "func.pl";
}else{
require "/myApp/func.pl";
}
at the top of every file and I don't even know if that would work...
Anybody got a more elegant solution? (other than "dump IIS" ;-)
Thanks!
-Peter
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PHP vs Perl
Octavian, In some respects I believe you are correct. Here are my 2cents... 1) It is really not good to enable mod_perl by default. Doing so would dramatically increase the size of the Apache binary. Enabling all scripts to run through Apache::Registry would break half the scripts that exist out there... Even the more backwards compatible form of Apache::Registry is going to require tweaking for probably some scripts and in the meantime would create a support burden for the ISP for sure as well as increasing the ISP memory requirements. Also, mod_perl is a tool with access to Apache internals which can be security problem also (so that part would have to be turned off). mod_perl is more designed for power users. I do think that a beginner can be proficient without too many weeks of work but not the same learning curve (like 1 day) as plain CGI/Perl. 2) PHP has some very rich on-line resources available that also furthers the helping of people. mod_perl has tried to do the same but only since maybe last year or so? My dates may be wrong, but I saw this PHP vs mod_perl discussion on the mod_perl mailing list.I think most people looked at perl.apache.org THEN, and PHP's various websites and the difference in tutorial and sample code quality was overwhelmingly in favor of PHP back then. Since then, perl.apache.org has been revamped, but it takes a long time to change people's perceptions. Sadly, (or perhaps justifiably so), documentation can make all the difference in the success or failure of an open source project. Not the code quality or architecture of the project. 3) In any case, to get close to the speed of PHP, you need mod_perl (which is arguably faster than PHP), but to get close to the user-friendliness/learning curve of PHP, you have to stay in the world of CGI. Although this is my opinion, I believe this, at least, to be arguably true. 4) It's not just that something has a big corporation behind it that can make it a success. It's also your "partners" and how big they are. ISPs, for example, would be the "best friend" for any technology to have. Unfortunately for Perl, I would not be surprised if the ISPs have had a hand in pushing PHP's success. Given that PHP will consume less resources than launching CGI shells but allow any beginner to do so (as opposed to mod_perl), what ISP wouldn't want to encourage their users to use PHP instead of Perl/CGI? If they can handle 20 users on a box using Perl/CGI but 100 users on the same box if those users switched to PHP, it obviously helps the ISPs bottomline to have people use PHP. See my comment in #1... sadly, there is no way to easily enable mod_perl by default. The list of ISPs supporting mod_perl has been growing, but it is still quite sparse.. 5) I have done some PHP coding and found it extraordinarily easy to pick up. I wouldn't move to it however because I find that for my purposes CPAN is actually a big bonus. eg I am recently programming in bioinformatics field again after a hiatus in the financial world for 5 years...how many tools exist to integrate with bioinformatics tools in PHP? Maybe a few, but certainly compared to Java and PHP, Perl has libraries for that domain beat hands down. Even if the modules are not in CPAN, many websites have various bits of Perl libraries for accessing their bioinformatics tools. And so just continuing to use Perl makes a lot of sense. For me. :) I think a lot of other people who advocate Perl in "one word: CPAN" probably feel the same as me though. And that is heartening. :) Thanks, Gunther Octavian Rasnita wrote: Of course I will remain subscribed and I am not gonna start learning PHP immediately. I am thinking to learn it because in my country there are only 2 books for learning perl in my native language and even though I don't need them, there are very few perl programmers and almost no jobs for perl developers. There are even some programmers that just heard about perl but they don't even know too well what it is, and they are good programmers in their languages. My problem is that I am used to work under Windows where no compiler is installed by default and where some CPAN modules don't even compile under this OS, and I cannot just jump and use Linux because Linux is not an operating system too accessible for the blind, and I am totally blind. Unfortunately I cannot try to solve this problem and start creating an accessible version of Linux then creating perl programs under this OS. Perl is great because OF CPAN also, but there are very many modules that require Linux, some of them don't even tell this but the modules don't even want to compile under this OS. I am not trying to convince somebody that PHP or Java is better than perl, but I am just trying to see what makes those programming languages so... "en vogue". For example a programmer in Java can create not only java servlets or java server pages, but they can also create java applets and des
Re: Is it a security risk to use identical names for database fields and html forms?
At 01:55 PM 8/31/2001 -0700, Curtis Poe wrote:
>--- "Michael R. Fahey" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was looking at a perl script where the developer used different names
> > for the incoming parameters and the database field names. He told me
> > that this was done for security reasons-- to ensure that malicious users
> > would not be able to discover the field names in the database being
> > updated or queried. How dangerous is this? I think it would be easier to
> > work with a hash of parameters from the input form.
> >
> > I'm using cg.pm, DBI, and postgresql.
> >
> > Thanks.
> >
> > Michael Fahey
>
>Hi Michael,
>
>Great question! This raises some security issues that many people just
>don't consider.
This is true. Kudos to any beginner asking about security at all!
>Wether or not this is a security risk depends upon exactly how you use the
>incoming data. Let's
>look at a short script that does this horribly, horribly wrong:
>
> #!/usr/bin/perl -w
> use warnings;
> use strict;
> use CGI qw/:standard/;
> use DBI;
>
> my $dbh = DBI->connect( 'dbi:ODBC:stuff', 'name', 'password',
> { RaiseError => 1} ) or die DBI->errstr;
>
> my %data = map { $_, param( $_ ) } param();
>
> my ( @fields, @values, $name, $value );
>
> while ( ($name, $value) = each %data ) {
> push @fields, $name;
> push @values, $dbh->quote( $value );
> }
>
> my $sql = "INSERT INTO theTable (" .
> join ( ",",@fields) .
> ") VALUES (" .
> join ( ",",@values ) .
> ")";
>
> print header,
> start_html,
> p( $sql ),
> end_html;
>
>So far, everything might look okay. The developer was even security
>conscious and quoted the
>values. Imagine what happens if this script is called with the following URL:
>
> http://www.somehost.com/cgi-bin/db.cgi?name=Ovid&color=red
>
>You get back a nice Web page with the following SQL:
>
> INSERT into theTable ( name,color) VALUES (Ovid,red)
>
>That's all well and good. Now, let's alter the URL slightly:
>
>
>http://www.somehost.com/cgi-bin/db.cgi?name%29%20VALUES%20%28%20%27Ovid%27%20%29%3BDROP%20TABLE%20theTable%3BINSERT%20INTO%20theTable%20%28name=Ovid
>
>Hmm, that's a bit more complicated. I wonder what the SQL is?
>
> INSERT INTO theTable (name) VALUES ( 'Ovid' );DROP TABLE
> theTable;INSERT INTO theTable (name)
>VALUES ('Ovid')
>
>Oops. We might lose that table. Now, by crafting a good query string, we
>can attempt to execute
>arbitrary SQL against the database (there are many, many variations of
>this attack). These
>attacks are kind of tricky because you usually need to craft the URL in
>such a way as to ensure
>that *all* of the SQL is valid at the time it's evaluated, but it's still
>a possible exploit.
>
>There are ways to make this secure and still use the field names, but I
>wouldn't suggest it. While
>I am not an advocate of Security by Obscurity, I do advocate not revealing
>information that you
>don't need to reveal.
An important additional point is that simply renaming your form parameters
to be different from the database, you would still usually have a 1 to 1
mapping from the form to the database field name somewhere in your code.
So the above code that was given as an example could possible screw things
over for you even if you renamed the variables. And conceivably, you could
play tricks if you knew more about the database to issue alternative
queries in-line if a section of the CGI script is issuing queries itself.
While it is conceivable that security through obscurity has SOME value, I
am not sure that in what might be a large program that such a mapping helps
your programmer's thinking process in terms of writing and maintaining the
code later.
If the form vars are renamed with an obvious prefix like fname in the
database becomes form_fname then it should be obvious to a cracker that
form_ is a standard prefix. So the best way to rename the variables is
fairly randomly. But this will suck for your maintenance of the code. I
suppose you could have a filter function that takes CGI.pm and remaps the
form values inside of it, but it's still harsh on the forms developer for
debugging and always remembering the mapping. What a yucky thing to have to
work on then!
I would tend, therefore, to shy away from security through obscurity in
this case and focus more on how to make the SQL secure itself. As has been
pointed out in the last post well, validation of input is very important.
For an introduction of the basic issues, any documentation having to do
with taintmode is quite reasonable to read. eg
http://www.gunther.web66.com/FAQS/taintmode.html
Also, if you are writing SQL code, you should definitely consider the
following three issues:
1) The quoting issue was discussed by the previous poster.
But there was no solution
Re: Win32 Apache and Perl
At 03:59 PM 9/1/2001 -0400, Brett W. McCoy wrote: >On Fri, 31 Aug 2001, Shannon Murdoch wrote: > > > Is there any way (I'm sure there is) to make my perl scripts run with the > > standard unix shebang instead? > >Yes, use Unix. :-) So helpful for the Operating System "challenged". :) >If you are usig ActiveState, you have to use the Windows way of using >pathnames. If you are using CygWin (which is a POSIX emulation layer for >Win32), you can use the Unix-style shebang line with CygWin's version of >Perl. Brett, are you sure that this is the end of the story? The parsing of the shebang line is not purely a function of the Operating System layer (as you suggest using CygWin) but is also a function of Apache (specificially on Win32). I have tried and was successful with the following technique 3 years ago, but I do not know whether such a technique will still work. The premise is that Apache (on Win32 -- this is a special feature of Win32 Apache) already understands #!c:\perl\bin\perl.exe. It's actually a *really nice* feature because it allows you to enable warnings and taintmode without mucking about with the the file association registry stuff -- I could go off on a soapbox now about this but I won't. But, when I experimented with different things I found that Apache could interpret and understand by itself, the following things in Win32: a) #!c:\perl\bin\perl Taking of .exe works b) #!c:/perl/bin/perl switching the backslashes representation works. c) and a final experiment #!/perl/bin/perl Shows that Apache understood that it was also installed on the C: drive and therefore did not need the pointer to let it know to find Perl there. So this would lead us to figuring that #!/perl/bin/perl could be made to look like /usr/bin/perl. How? Easy enough I think. I basically installed Perl into c:\usr instead of c:\perl so that bin was under c:\usr\bin. And that worked for me. I can't say if this still works but if Apache is doing the interpretation I don't see why not. Note that this is an Apache feature -- this won't help you with brain dead web servers like IIS that make it really hard to set up CGI/Perl. But since the question was specifically about Win32 Apache, I've obliged to talk about it. One other note is that rather than going through another ActiveState Perl install into \usr, I think that you can simply make a copy of perl.exe in c:\usr\bin\ and keep your perl distro where it is as the registry or some other setting in windows actually knows that the Perl distro for that binary is in c:\perl and so this technique can be tried out in an even *easier* fashion than my first suggestion. Shannon, if you would be so kind, I would be interested to know this technique still works if you end up trying it. Good Luck, Gunther -- 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?
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 this person to have asked about on this list, and shows a smart attitude towards security. Especially this person questioning why his colleague suggested doing this. Implementing "old wive's tales" of security (eg knock on wood, don't walk under ladders, untaint all your form input) without understanding the why behind it is sometimes just as bad as not having implemented the solution at all. For example, as I pointed out yesterday, if you obfuscate your form, you'll make creation and subsequent maintenance of the program much harder because it will be yucky to constantly convert from obfuscated form variable to real database field. Unclear code leads to bugs, and by probability some bugs are security bugs. Anyway, I apologize if I misunderstood the intent of your reply to the thread, but I personally had found it sufficiently vague that I wasn't sure what you were really advocating or thinking was the risk here. Later, Gunther >-Original Message- >From: Michael R. Fahey [mailto:[EMAIL PROTECTED]] >Sent: 31 August 2001 13:33 >To: [EMAIL PROTECTED] >Subject: Is it a security risk to use identical names for database fields >and html forms? > > >Hi, > >I was looking at a perl script where the developer used different names >for the incoming parameters and the database field names. He told me >that this was done for security reasons-- to ensure that malicious users >would not be able to discover the field names in the database being >updated or queried. How dangerous is this? I think it would be easier to >work with a hash of parameters from the input form. > >I'm using cg.pm, DBI, and postgresql. > >Thanks. > >Michael Fahey > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >_ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.co
RE: active perl on IIS
Joel, I could be wrong but based on the way Lynn describes the problem, it does not sound like she has a problem with Perl being installed as the PerlScript examples do work as she stated. Also, she should not have to create a cgi-bin. IIS has a pre-created cgi-bin typically. While I am a fan of OReilly, I am also not sure that Win32 Perl book from OReilly will help Lynn so much because it's about Perl first and foremost, CGI secondarily (not that much coverage), and I don't think it goes into server configs but I could be wrong. Anyway, I think what Lynn is describing sounds more like a file extension problem. ActiveState Perl does set up Perl for IIS if I remember correctly but it does it based on FILE EXTENSION. So an important factor here is that Lynn should figure out if her file extensions would run if she clicked on the script in Explorer. I would be interested to know what file extension she is using for her scripts. If her colleagues are on UNIX and writing web apps, it's highly likely that they might use .cgi as an extension? But ActiveState never sets up .cgi. It will set up .pl for Perl for example. I have a more detailed article on this topic located here: http://webcompare.internet.com/isapiperl/index.html With a page specific to providing hints for installing ActiveState Perl for IIS here. http://webcompare.internet.com/isapiperl/isapiperl_3.html Good Luck, Gunther At 08:23 PM 8/29/2001 +0100, yahoo wrote: >Lynn, >I've installed ActiveStates Perl a couple of times on Win 2K & NT and each >time, as part of the install, it allowed/prompted for the configuration of >the ISAPI part which basically meant you can run perl as an active x >scripting engine.
Re: Win32 Apache and Perl
At 11:16 PM 9/1/2001 -0400, Brett W. McCoy wrote: >On Sun, 2 Sep 2001, Gunther Birznieks wrote: > > > I can't say if this still works but if Apache is doing the interpretation I > > don't see why not. Note that this is an Apache feature -- this won't help > > you with brain dead web servers like IIS that make it really hard to set up > > CGI/Perl. But since the question was specifically about Win32 Apache, I've > > obliged to talk about it. > >I stand corrected then! Does Apache interpret the shebang line before >running the script? I've had problems with Apache *requiring* the correct >drive and pathname for other things in its configuration under Win32. I believe it does. But I am not sure what you mean by "other things in its configuration". Are you talking about other things in httpd.conf or other things in your Perl script? If the httpd.conf, I can say that one thing that Win32Apache hates is spaces in directories. Or at least it did 3 years ago. I really haven't used Win32Apache recently. I tend to use Netscape under Windows because it is nicer than IIS and I can test both Velocigen and PerlEx for accelerated Perl. I used Linux and Solaris to test mod_perl and Speedy::CGI stuff. If you are talking about problems with the perl script running under Apache, then I would require more detail about what you meant by a problem before venturing a guess as to what might have been wrong. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
At 02:59 PM 9/2/2001 -0700, Lynn Glessner wrote: >I haven't had a chance to work on it recently, but I think it will turn out >to be the .cgi extension (I'll have to go back and see who suggested that). >I have my scripts in a directory which was created automatically called >"scripts" a subdirecctory of c:\inetpub - IIS has it configured for >executables. However, all my perl scripts in this directory have the Yeah, Joel was correct in his previous mail. There is no cgi-bin directory created in IIS. My poor memory was really referring to this directory, which should have worked. >extension .cgi. Double-clicking one of the example files installed by >ActivePerl (those files have a .pl extension) executes fine, but my .cgi >files have a generic icon - can't believe I didn't think to check that. Yes, this would have been a clue, but don't feel bad. This is deceptive because IIS actually pays little attention to the file manager associations. So .cgi could have been associated in IIS but the Windows Explorer still gives no icon if they were set up differently. I am not sure about Microsoft's motivation of separating Explorer from IIS file ending associations. It possible this was done for security reasons so that not all files become executables in IIS unless configured for IIS. >I have the O'Reilly CGI book, with the rat/mouse on the cover, it is very >helpful for CGI and Perl. I have the working version at work, it's just the >implementation at home on IIS that I'm struggling with after doing my >development at work. :( Well if this is just a home machine, I think someone else had also suggested using Win32/Apache. This might also be easier unless you are familiar with using IIS for everything else you are experimenting with. If you do get the simple .cgi works in the scripts directory, then also note that if you dump your .cgi inside of c:\inetpub\scripts (if thats your directory) then the program will work when you use relative paths. But your relative paths won't work if you put it in a subdirectory of c:\inetpub\scripts because IIS always does the equivalent of chdir back to the root of the c:\inetpub\scripts directory itself. So you need to make all paths relative to c:\inetpub\scripts rather than, say, c:\inetpub\scripts\myScriptArea if you put myscript.cgi in there. Although you haven't run into this problem yet, I mention it in advance because it's the next most common complaint I see next to the file association one with regards to how to make an application work. >Thanks very much for the suggestions, I hope to be able to tackle this >tonight (after my 2 year old goes to bed - she doesn't have much patience >for programming yet!). :) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
At 09:07 AM 9/3/2001 -0700, Lynn Glessner wrote: >That did it - thanks :) I am slowly but surely getting this changed over. > >I changed >to >http://198.162.0.1/scripts/sl3.pl"; > >(Obviously if I decided to make this public I would need a different IP or >hopefully a DNS name.) > >I can't believe this is taking me so long, when the script WORKS on a >different OS and web server, but hopefully once I have gone through this >once I'll be able to do this again in the future (or just develop on the >same platform, that would be nice!) As an aside, you should consider that your action does not even have to be an absolute URL. Even if the form is in the HTML tree instead of the CGI tree, you can at least get away with just ACTION="/scripts/myscript.cgi" isntead of the whole HTTP://etc.. If the form was generated by another scripts in the scripts directory, then you can get away with ACTION="myscript.cgi". And finally, if the script that generated the form is the same that is being posted to, you can leave off ACTION= entirely because the default action is to submit the data to the same exact script. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: active perl on IIS
At 08:36 AM 9/3/2001 -0700, Mark Bergeron wrote: >Let me also add, unlike *nix, you may run scripts from virtualy any folder >you see fit on Win (within wwwroot for the web of course). Everything is >really governed by the permissions and etc... you set on the folder >itself. In some cases it makes sense to name the cgi folder something less >obvious like, wordfiles, oldapps or the like. Be creative. This way should >the casual hacker break in you stand a chance of he/ she skipping the >directory. At the very least, someone is sniffing your tranfers might not >suspect your moving them into an executable dir. Just a thought. > >MB' I don't fully understand this advice. If the casual hacker has "broken in", then it seems that they already have more or equal power than they would be able to gain through hacking a scripts directory. As for sniffing file transfers. I suppose that is a valid issue, although it seems to me that someone sniffing an FTP session would sooner be able to get your plaintext password and be able to search around themselves. Even if the directory in this case was renamed, the script itself is not. So something like formmail.pl would still be formmail.pl even if it is in an oddly named directory. I am not saying there is no case for it at all. But it doesn't seem that strong for the annoyance of dealing with an obfuscation in your own setup. I think a human reading the directories would be able to figure out where things are. However, I also think that script kiddies are certainly something to watch out for if you are afraid you might miss a Microsoft security patch one day. One thing to consider then is that renaming the scripts directory may prevent an automated hacking script from putting something in the defeault c:\inetpub\scripts directory. So perhaps if this directory were renamed to something that is not obfuscated to make it hard to manage, but still different (eg maybe call it scriptstuff) then the automated scriptkiddle script will be thwarted. This is similar in concept to the idea of renaming root (which seemed to be advocated at SANS even several years back, don't know if it still is) just to prevent some scripted attacks from being able to log on as root. But they didn't precisely advocate renaming root to something that is obfuscated -- just renamed enough to fool the scripts of that day. Anyway, I'd like to hear more evidence of how strong renaming the scripts directory really is against attacks as I could be wrong in my assumptions. Thanks, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: securing sensitive information in CGI scripts
At 10:34 AM 9/4/2001 +, Mel Matsuoka wrote: >At 07:20 PM 09/04/2001 +0100, yahoo wrote: > >Hi all, > >I'd like to find out peoples opinion on the following. > > > >If you have a perl cgi script which accesses a database, are there any > >security issues with having the DBI connection details in the perl script > >(rather than, say, an external file not in the document root - is this > >better?)? > >My general policy regarding things like this is, the more paranoid you are >, the better :) > >Having password information embedded in a publicly accessible document such >as a CGI script is playing with fire, as far as I'm concerned. There may be >a time when you least expect it when someone (or you) screws up the >webserver config, and accidentally allows cgi-scripts to be sent out as >plaintext documents. Ouch. > >That's why for all of my Perl and PHP scripts, I "include" the database >server connection details using an include file which is saved outside of >the webserver root. Of course, this isn't 100% secure, since anyone who has >local filesystem access to the server can still get at the information, but >then again, if someone has achieved that level of access, you have bigger >problems than worrying about your DBI include files and CGI scripts ;) You can even go one step further, in banking practices, you typically never access the database directly anyway from a CGI. Instead you have a multi-DMZ (well DMZ isn't the exact right term) but multi-partitioned architecture so that if someone does break into the web server they still do not have direct access to the database. Something like Internet -> Firewall -> WebServer -> Firewall -> App Server -> FW -> DB Server Each major server essentially being controlled by dual homed hosts on separate subnets with the network interface on the firewall only controlling a single direction of traffic to the server in question. Of course, most normal people can't afford this and make do with chrooting and running on a dedicated host with a linux IP Tables firewall on one single machine even if they go dedicated. As an aside, eXtropia has an open source toolkit which allows this higher level of indirection without any application logic programming. The abstraction is called Extropia::DataSource (written in Perl) and for this abstraction we have DataSource::File (For flat file) and DataSource::DBI (for DBI). But if you require stronger security (like the above approach), you can use our DataSource::SOAP which talks to a Java Servlet container (as the app server eg Jakarta-Tomcat) running code from the Apache SOAP Project as the infrastructure and then on top of it, our com.eXtropia.datasource.soap.SoapDataSource package wrapped around our com.eXtropia.datasource.SecureDataSource API. The SecureDataSource API allows you to restrict permissions in a way very similar to how permissions are restricted using grant statements on SQL and in addition the password to the database is stored in the middleware server (breaking into the webserver does not grant access). The other cool thing about this is that most servlet containers also handle JDBC connection pooling for you (an additional performance boost which makes the performance lag introducing a middleware server more reasonable). Of course, you can go even farther than this. Obviously the best middleware server will contain the equivalent of stored procedures which tightly restrict in a typed concept, what sort of data may pass into it and out of it (as opposed to essentially arbitrary queries). Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: postie (command line mailer for windows)
Lynn,
If you are interested in an alternative tool to send mail than postie, you
may want to look at Mail::Sender which is what we tend to recommend to
user's of our NT Scripts. Although if anyone has more up to date
information on the best Mailer to use for NT, I'd be glad to hear it and
update our documents. :)
One thing you should also be careful about is that programs that require
command-line input to pass parameters are really quite dangerous
potentially so we tend to shy away from them. I don't know if Postie is
like that, but Blat definitely is. Of course, you can use the array context
system() call as well as taintmode but it is still risky.
In addition, launching an extra process on windows (especially) is quite
expensive and slow. So your feeling on using SMTP is good.
If you are interested in a fairly generic API to send mail from CGI
scripts, all our newer scripts come with Extropia::Core::Mail API which
supports drivers for blat, Mail::Sender,
NTSendmail and Sendmail natively with the exact same calling API.
We did this because the state of mail packages out there on CPAN seem a
somewhat disjointed (especially with poor support for NT). But eventually
should they become better we'd end up replacing our API with theirs (the hope).
The modules for doing this come with our current WebCal and WebDB
distributions. We try quite hard to make sure they work under NT, so most
of the stuff should be NT compatible.
The usage is quite simple
use Extropia::Core::Mail;
my $mailer = Extropia::Core::Mail->create(
-TYPE => 'MailSender',
-SMTP_ADDRESS => 'something'
);
$mailer->send(-FROM => $from, -TO => $to, -SUBJECT => $subj, -BODY => $body);
And that's pretty much it. I am pretty sure this will work well on NT for you.
You can download Mail::Sender using PPM on your NT Server. So type
ppm
And then
install Mail-Sender
Note that the PPM package for Mail-Sender is not available for older Perl's
I think. But it definitely downloads fine for me on ActiveState Perl 5.6.1.
Anyway, I think Mail::Sender will be much easier for you (even if you
decide to use it natively) than Net::SMTP.
Later,
Gunther
At 01:15 PM 9/4/2001 -0700, Lynn Glessner wrote:
>Here is an interesting tidbit for anyone thinking of using the command line
>mail tool "postie" on Windows from their cgi script.
>
>I decided to send email through a system call to postie, just because postie
>is how I have always sent mail from the command line in Windows :) I
>couldn't figure out why I was getting a display error from IIS - it worked
>fine in a test script but not in my real script. Turns out postie was
>wanting to display a complaint about CGI, and I finally found this tidbit
>from the author of the utility:
>
>"To run Postie from a CGI program and get it to process command-line
>arguments properly you must first un-set the environment variable
>'GATEWAY_INTERFACE' or run the program without inheriting the parent CGI
>program's environment"
>
>In other words, use undef(ENV{GATEWAY_INTERFACE}); before executing your
>system command calling postie, and then all is well.
>
>Thought I would pass this on so no one else wastes time on the same thing, I
>only found one mention of it in my google web search and and none in my deja
>news search (or whateve it is called now) so it most not be a very popular
>way to go - or else people give up and do it another way.
>
>BTW, I looked at the NET:SMTP included with activeperl and didn't see how I
>could make the contents of a text file be the body of my message. If someone
>can tell me how that is possible, I would prefer to use that method in the
>future. (I'm avoiding installing any more modules than what were included.)
>
>
>--
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__
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: Extened - Re: securing sensitive information in CGI scripts
This is a very different security question. Basically I think there are two major classes of solution. One is based on randomness and the other is based on a harder core ACL check in the CGI itself and requires the CGI control access to the file more tightly. In Detail: One way which isn't the most secure is to generate random directories to place these files in and then put the file in these random directory names for download. Unless a hacker guesses correctly (eg use an MD5 hash is pretty strong) which is unlikely, they won't be able to get a file of someone else's without knowing the session key. This is subject to brute force checking and is potentially breakable through other means. The more secure way is to store the file outside the document tree and check a database to see if the authorized user can access that particular uploaded file. If so, then the CGI program itself should open the file and present it back to the user. Otherwise, no dice. At 10:32 AM 9/5/2001 +0800, Rajeev Rumale wrote: >Greetings to all, > >This is really a good thread we have. > >How ever as the title is not restricting to database security. I would like >to add my concern to it. > >I need to store some uploaded files from the "visitors" into some >directories which are inside website root. > >Since the files submited are confidential info We need to protect it from >people directly accessing the files depending upon the ownership rights (the >actual owner, site admin, site operator, other authorised user). > >Any suggestions for same . > >Thanking in advance. > >Rajeev Rumale > > > > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ 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: 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 qu
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
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: options for the checkbox...?
No, the fact that unchecked boxes aren't sent is a browser issue. It's the
same reason why submit buttons that are not clicked are undefined as well
on a multi-submit form.
What you can do, however, is use other form fields in combination with
logic. For example, let's say the name of your check box is
"view_all_records" and you want it to explicitly be set on or off.
Well, then you can always create a hidden variable called the same thing
and set it to off by default...
So
And then in CGI.pm, expect $q->param('view_all_records') to return an array
if the check box is on, and return an array with a single value if the
check box is off (the single value will be the hidden field).
The technique would be slightly different if you had many check boxes with
the same name but different value. eg In a WebDB, you might allow selection
of the id of a record by allowing the user to click next to database rows.
The extrapolation of the above technique to the second I describe with
multi-checks is left as an exercise to the reader (since it wasn't the
situation you described anyway).
At 06:08 PM 9/8/2001 -0700, Simon K. Chan wrote:
>Hi Everyone,
>
>Let's say I have this snippet of code for a checkbox:
>
>
>
>$name = param('bill');
>
>If the box is checked, $name will have a value of "on"
>If the box is NOT checked, $name will be undefined (have no value).
>
>My Question:
>Is there a way to make $name have a value of "off" when the box is UNCHECKED?
>
>Many thanks for your time, Everyone.
>
>
>
>=
>#
>Warmest Regards,
>Simon K. Chan - [EMAIL PROTECTED]
>
>"Great spirits have always encountered violent opposition from mediocre
>minds."
>
>-Albert Einstein
>
>__
>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]
__
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: A Framework for Building An WML/HTML Application Using Perl???
At 09:30 AM 9/10/2001 -0500, David Simcik wrote: >Hey all, > I'm trying to modify an existing script that searches a test file > for what >one could qualify as normal phonebook style entries; name, phone #, email >addy, etc. We've got an internal presentation coming up in two weeks, and my >boss would like to WAP-ify this directory for it. That almost certainly >means moving the app to produce an XML doc of some kind. Ideally, I would >like to use XSLT to convert the raw XML doc into WML and HTML; to seperate >data from presentation of course. The Perl script would handle the actual >search mechanism, any logic required to detect different browsers, and the >handling of the XSL transformations. The most comprehensive XSL Transform API for Perl is Matt Sergeant's AxKit. http://www.axkit.org/. It works with mod_perl and is quite heavily optimized. >Can anybody provide a few pointers on the best approach to take with this? >More specifically, any recommended modules that could be used to facilitate >this? How can I detect different WAP browsers??? You can detect different WAP browsers with an Agent string, but really there are some guidelines to programming WAP in a fairly cross-browser way. I've programmed for about 12 different WAP phones and found many of them to be quite similar with the original Nokia 7110 and Motorola PDA phone being the biggest offenders and pain in my neck programming. Caveat: my experiences may not be the same as you may find because I wrote my apps for use in a GSM market phones in Asia. But if you are in the USA, your WAP phones may have different quirks than the entire rest of the world. As a shameless plug, I would direct you to the book Applied Perl edited by Peter Williams where I've written a chapter on programming WAP applications using Perl based on my experiences writing WAP and SMS enabled Web-applications in that market. Anyway, since all you really want is a demo, I would just download one of the WAP emulators and just simply code for that emulator and your life will be much easier than coding some weird XSLT transform. I am of the opinion that WML is really so completely different and changes your forms so drastically and what you would want to display and bring back as data, that a simple XSLT transform is not enough -- you really require logic changes to the application. People talk all the time about separation of UI from application code, but to some degree, the UI medium does have a big effect on the workflow of the application. For example, in an HTML app, you can often get away with long parameters passed back and forth but in WML where you might have a single HTML form split into many WML forms, you have to more readily maintain the state of the previous forms in your WML application which requires more session logic. These things can't really be emulated in a "simple" transform. Good Luck, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming a File
At 08:42 PM 9/10/2001 -0600, Justin Simoni wrote: > > Well, what was your $! when the rename failed? If it was "cross-device > link", > > then you attempted something that you really can't do. > >I don't think it was anything like that, as with many :) real world >problems, it's a bit more complicated than that. The file in question on my >failure was an email subscription list, so an email had to be searched for >in one file, a new version of this file had to be created that had the >file's content sans found email and then this list had to be written back >into where it used to be, so it was something like (reduced to Algorythmic >fluff for clarity): > > >-- > >open OLDFILE, $oldfile; >open TEMPFILE, $tempfile; > >while TEMPFILE > next if $email eq '$_'; > print TEMPFILE $_; >end while > >close OLDFILE; >close TEMPFILE; > >delete($oldfile); ># ahem >rename($tempfile, $oldfile); > >-- >a BIG problem with this was that the live file with the subscription list >was hit several times a second for large lists which also makes the file >kinda hefty. so, yeah, this was just asking for trouble. Although I suspect you did it right, I am still curious about the exact algorithm because it seems ambiguous to me what you did and where your problem lay. So by the above, you mean because you'd lock the entire operation? Or are you saying there is a race condition? I am assuming you have locked and unlocked the resource (only one updater at a time lock) at the beginning and end of the routine up above... But in the above scenario it at least seems as if your reads should always work but you just need to lock on a 2nd resource (exclusive lock so no one can read either) around the delete and rename operation. >My solution was to first make my Highlander, 'There shall be only one' temp >file lock and with that protection, make my temp file with the changes, >close both the temp and live file, open the live file for overwritting, and >the temp file for reading, and then just delete the temp file. At first glance, this sounds dangerous to me. How can you assure that another process isn't reading the file at the same time if you are opening the live file for overwriting. Or is a new inode really created at that point? Even so, is it possible that even if a new file is created, before you finish writing, for example, the 2nd half of the addresses file, another process could have tried reading it as the entire distro list and so fail to do whatever operation it had to do on the 2nd half of the list. >I'm pretty happy with the performance, as the site that was really having >problems.. hasn't since we changed this routine and their list is somewhere >around 70,000 - 100,00, this site is http://redjellyfish.com the software is >(*cough* shameless plug) http://mojo.skazat.com >-- > >justin simoni > >personal musings ~ http://skazat.com >_ > force a change > > > > > >On 9/10/01 8:04 PM, "Randal L. Schwartz" <[EMAIL PROTECTED]> wrote: > > >>>>>> "Justin" == Justin Simoni <[EMAIL PROTECTED]> writes: > > > >>> Yes, and surprisingly enough, it's called "rename". :) > > > > Justin> I've had bad luck using rename, I've had to copy the file to > > Justin> the new name and deep six the old, check out File::Copy, I > > Justin> think it ironically, has a function called copy(), or even > > Justin> cp(), my memory eludes me. > > > > Well, what was your $! when the rename failed? If it was "cross-device > link", > > then you attempted something that you really can't do. > > > > But to say in general that "rename" is perhaps broken is a bit too > > much for me to let stand with no comment. > > > > My advice to the original poster: use rename, but be aware that it can > > only rename within a disk, not across disks. > > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ 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: String to Date conversion
At 08:42 PM 9/10/2001 -0400, [EMAIL PROTECTED] wrote: >Hello, >Can some one please suggest me a pointer to do easy date manipulations in >perl. >I have dates as strigs I need to compare 2 dates and may >be sort an array of dates(Strings). > >Thanks >s- Look at the Date modules on CPAN. I quite like one of the recent ones called Class::Date but you'll find that it isn't in ActiveState's PPM repository yet and requires a C compiler to compile if you are using Windows NT. Otherwise consider looking at Date::Manip and Date::Calc. Also, questions like this beg for you to buy the Perl Cookbook from O'Reilly. It has all sorts of quick recipes for Perl for doing operations like this. In addition, you might find some operations are quite trivial. eg if you have a string and you know how to parse it into date parts, you could put the date parts together again in a way that will compare easily in a sort. eg mmdd will sort fairly accurately in scalar context. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: file write problem
In addition to Randal's lucid explanation of your specific problem. I would
encourage you to also use taintmode flag and filter both subject and
filename as they are being used to create the file. The commented out
attempt to do this with $name shows that you basically may be aware of
this, but I figure that I would just raise it quickly since it's important
topic.
Another minor thing is that I thought ">>" was the operator for opening
with appending not "<<". But I haven't done appending in a long time so I
could be wrong.
At 09:51 PM 9/11/2001 +0100, Francesco Scaglioni wrote:
>Hi,
>
>I have a script which collects a comment than should write it to a
>file. Initialy several scripts did individual jobs but I am combining
>them. the opening gets the details like this:
>
>
> my $email = param( 'email') || '';
> my $text= param( 'text' ) || '';
> my $name= param( 'name' ) || '';
>
># ( my $name )= ( param('name') =~ /^(\w+)$/ );
> my $filename= param( 'filename' ) || '';
> my $subject = param( 'subject' ) || '';
> my $action = param( 'action' ) || '';
> my $heading = param( 'heading' ) || '';
> my $title = param( 'title') || '';
>
>and then like this:
>
>
> if( $action eq 'start' ) { start(); }
> elsif ( $action eq 'list') { list( $subject ) ; }
> elsif ( $action eq 'display' ) { display( $subject , $filename ); }
> elsif ( $action eq 'get_comment' ) { get_comment( $heading , $subject ,
> $filename ); }
> elsif ( $action eq 'write_comment'){ &write_comment( $name , $email ,
> $text , $subject , $filename ); }
> else { start() }
>
>
>Then the write bit is:
>
>sub write_comment {
>
> $name = $_[0];
> $email= $_[1];
> $text = $_[2];
> $subject = $_[3];
> $filename = $_[4];
>
># $COMMENT_DIR = ("../data/$subject/.comments");
> $COMMENT_FILE = ("../data/$subject/.comments/$filename") ;
>
>if ( ! $name ) {
>
>die "No value for name";
>}
>
>else {
>
>
>local *WRITE_COMMENT;
>
> open ( WRITE_COMMENT, "<<$COMMENT_FILE" ) || die "$COMMENT_FILE : $!";
> flock WRITE_COMMENT, LOCK_EX || die "cannot lock comment file: $!";
> print ($text, $name, $email ) || die "cannot print hello : $!";
> close WRITE_COMMENT || die "Cannot write to comment file ; $!";
>}
>}
>
>
>
>What is throwing me is that none of it errors or dies but the file
>remains blank. What am I missing?
>
>TIA
>
>Francesco
>
>--
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__
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: editing script
At 08:44 AM 9/13/2001 -0300, Wagner wrote: >Hello, > >I'm editing a script that produces a .png image, i want it to turn it into a >.html doc. > >My first doubt is that i can't put the image in the html doc. The image is >stored in $im and i don't know how to put it in the doc. > >ex: >print "Content-type text/html\n\n"; >print "; Not unless $im is a URL and even then you may want to consider quoting it. You can't just dump binary data inside an HTML document. So $im must be a URL not the binary data of an image. >I'm also trying to put this image in a file this way: > >$file = 'c:\image.png'; >open (INFO, ">$file"); >print INFO "$im->png"; >close (INFO); > >But it doesn't work... It's possible that you want to turn binmode on INFO... binmode(INFO) before printing a binary image to it. >The second doubt is how can i put the content of a variable in the doc. For >example, if i have a valiable: > >$file = 'c:\dir\asdf.asd', > >Then i try to put in the doc this way: > >print "$file"; > >But when i run it apears $file in the .html doc and i wanted to see >c:\dir\asdf.asd $file should interpolate fine if you truly did use double-quotes in your print statement, but I think it is possible that you should cut and paste exactly what you used because you seem a bit confused, and I am afraid that it's possible that you're information is not relayed exactly as you say you typed your tests out. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Complete beginner can't get Sendmail to work
Please do a search on the archives of this list from the past couple weeks having to do with mail and you'll see many good, verbose suggestions on some good alternatives At 04:49 PM 9/13/2001 +0100, Andrew Cocks wrote: >my sendmail.pm file (stored in the SYS\Perl\lib\Mail directory) has the >following line: > >$default_smtp_server = '192.9.200.222'; > >my formmail.pl file refers to the sendmail file with the following line: > >$mailprog = '/perl/lib/Mail'; > >Can anyone see anything wrong with these lines of code? > >Is it possible to test sendmail.pm without using another script? > > > > > > > >** >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. If you have received this email in error please notify >the system manager. > >This footnote also confirms that this email message has been swept by >MIMEsweeper for the presence of computer viruses. > >[EMAIL PROTECTED] >** > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ 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: Security Suggestions Please!
At 12:22 PM 9/18/2001 +0200, Grierson, Garry (UK07) wrote: >I have to secure a newly developed web search service that deals with >sensitive fiscal information, this originally consisted of Perl scripts that >called html pages or other scripts. The default page ran a rudimentary login >script that launched a variety of html pages or further scripts, the html >pages in turn also ran scripts, one page also runs an IDC search. > >To disallow direct access to the html I have 'moved' this inside the >appropriate Perl scripts so a valid password displays the html page and an >invalid password returns you to the login script. The password is passed >between the scripts using the post method so it won't show up on the URL >bar. > >I have two questions. > >1) What benefits if any are there from checking the entered passwords >against a file or database table as opposed to having a valid password or >list of passwords held within the initial validation script? > The password will be changed regularly and the server is unlikely to be >changed to displaying the script text be mistake is unlikely. This depends on your security model and whether you believe in security through obscurity. >2) What if any dangers are inherent in passing the password between the >scripts to verify the users access? > This is an Intranet site so the only sniffers should be people with >colds! Do you trust your employees? I might if I have 5, but a company of 3000 would likely and probably should not. Corporate espionage and sabotage is definitely a real threat in corporations world-wide and should not be ruled out even if it seems improbable. That doesn't necessarily mean you need SSL client certificates. But it does mean that you should match your security needs with your risks. You really have not laid out the risks of what your company loses if these areas of your web site are exposed. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setuid question: "insecure dependency"?
The problem isn't setuid Perl it's that suid forces taintmode on. Read all available docs on taintmode. In particular start with Lincoln Stein's Web security FAQ at the www.w3c.org website... and re-read perldoc perlsec as you've stated you've done, but this time pay attention to the taintmode stuff. Lincoln Stein also has a good article on calling setuid stuff like changing passwords from a Web App in one of the past Perl Journal issues, but I can't recall which one at the moment. It was quite a good article though as it went through the pros and cons of several different ways of doing it. Later, Gunther At 05:14 PM 9/19/2001 -0400, Andria Thomas wrote: >Hi all -- > >I'm trying to write a setuid script to change passwords on a machine via >the web. I am not trying to change the local passwords (i.e. *not* >modifying /etc/password), but I do need the script to be run as root so >it can call another password-changing utility which is doing the actual >work. > >When run from the command line as root, the script works fine. However, >when run as myself (after setting the script to be setuid root) I get >the following error generated from the script's system call: > >"Insecure dependency in system while running setuid at ./chpass_web.pl >line 159." > >Perl is installed on this system to use suid emulation, so it's calling >the 'suidperl' binary. The problem originates from the following line >of code: > >system "/bin/echo $new_password1 | /usr/local/sbin/saslpasswd -p >$in_username"; > >The documentation I've seen implies that variables can't be passed >directly into the shell, as they are above, but I couldn't reword the >system call in any way that still enabled it to work. > >Can anyone help with this? Or lead me to any pointers on suidperl? >I've already read the perlsec manpage, and searched through the mailing >list archives... > >Thanks! >Andria > >-- >-- >Andria Thomas [EMAIL PROTECTED] >System Administrator -- Tovaris, Inc. >(434) 245-5309 x 105 > > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ 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: mod_perl
At 12:47 AM 10/30/2001, Bob Showalter wrote: > > -Original Message- > > From: John Griessen [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 29, 2001 11:39 AM > > To: David Kirol > > Cc: [EMAIL PROTECTED] > > Subject: Re: mod_perl > > > > > > Would one of you give me a little overview and point to best > > docs to read > > for mod_perl and CGI perl. > >If you didn't remove the manual that Apache installs, you should have on >your >system: http://myserver/manual/howto/cgi.html > >For mod_perl, see http://perl.apache.org > > > > > For starters, I tried to put a script at my local apache web > > server root > > directory, and the server just displays the contents as > > text...sounds like a > > web server setting is wrong like an alias... > >Well, you can't just throw things out there and hope they work. You have >to set the server up to handle CGI scripts. See the link above. > > > > > I read a little about apache alias for mod_perl and am > > confused. Can you use > > a normal server where perl scripts run and there is no alias > > of perl to > > mod_perl? What should be the first line of the script to > > point to mod_perl > > without an alias? > >mod_perl is an extension to Apache that bundles the Perl interpreter into >the >Apache server itself. Once this is properly installed and configured, Apache >can run your scripts via this "built-in" Perl. > >Your scripts cannot "call" or "use" mod_perl; it must be installed and >configured into the Apache server. All discussed in great detail at the >site given above. I would agree. However, it's not always obvious from the way perl.apache.org is organized where the choice documentation lies. The best and most verbose documentation tends to be located at http://perl.apache.org/guide/ which is the official mod_perl guide itself and tends to be the most up-to-date combination FAQ/Performance Tuning/Beginners guide for mod_perl. However, setting up CGI on apache is MUCH easier than mod_perl. I would recommend you begin slow first and then go faster later with mod_perl. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl and nntp.perl.org
At 11:58 AM 10/31/2001, Scott R. Godin wrote: >In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Ask Bjoern Hansen) wrote: > > > [EMAIL PROTECTED] (Scott R. Godin) writes: > > > > > aside from the mailing lists @apache.org I haven't seen much else, and > > > having a fair preference for a usenet-style discussion as opposed to a > > > mailing list format, it might be useful to bring such onboard here at > > > nntp.perl.org... > > > > I don't think we to make an extra mod_perl list. Maybe I'll get > > around to adding some of the apache.org lists to the perl.org news > > server some day, but don't hold your breath - my list of projects is > > (too) long. :-) > >I just thought it would be nice to centralize the mod_perl discussion >here, along with the rest of the perl-related stuff.. seeing as the >stiff competition from the PHP fanatics and with the help of the Zend >Optimizer, PHP appears to far outstrip mod_perl in both memory usage and >speed. the more people that can get involved with improving mod_perl the >better, and again, bringing discussion to one centralized location for >these things isn't a bad idea. He's not saying that there should not be a mod_perl list. It's that there is already a mod_perl list on apache.org. Go to http://perl.apache.org and subscribe to the mod_perl list there. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LWP and SSL
It's pretty much the exact same thing. Except that you need to compile LWP to work with SSL. You may wish to talk to your ISP about your needs if you don't control your own web server. At 06:01 AM 10/9/2001, Greg Puleo wrote: >Anyone have any examples of using LWP to post information to https sites? > > > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] ______ 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: security in perl
> >I can't wait for that day for two reasons: > >1. It will force people to be more conscientuous lest they face the >consequences. >2. My rates will go up. > >Until such time that this legislation passes (mark my words, it will, >sooner or later), it's still >unethical to knowingly fail to provide the best security that meets the >client's needs (note the >qualifier on that sentence -- no need to provide Fort Knox to protect a >simple bulletin board >script). > >Now, let's imagine that you're not worried about people with sniffers >grabbing your user names and >passwords because you're *positive* that no long-term damage could >occur. Here's the rub: people >reuse usernames and passwords all the time. Even if this information >doesn't allow someone to >cause you problems, they still might be able to access other accounts that >your users have because >*you* didn't protect their sensitive data. > >Again, sorry for the rather serious tone, but it's a rather serious subject. > >Cheers, >Curtis "Ovid" Poe > >= >Senior Programmer >Onsite! Technology (http://www.onsitetech.com/) >"Ovid" on http://www.perlmonks.org/ > >__ >Do You Yahoo!? >Make a great connection at Yahoo! Personals. >http://personals.yahoo.com > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ 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: configuring apache to run cgi -perl on win32 system
You'll need to change your shebang line to #!c:/perl/bin/perl.exe instead of #!/usr/local/bin/perl or something like that. Search the past archives on this list (assuming there are any) as this question has definitely come up in the last 3 months before. At 01:06 AM 10/17/01, rabs wrote: >Subject: configuring apache to run cgi -perl on win32 system > > > > Hello, thank you for taking the time to read this, I hope you can help, I > > have downloaded the release of Apache/1.3.20 to run on windows 98. I >wish > > to run perl cgi so I have made the following changes to the httpd.config > > file > > > > > > > > changed #ServerAdmin to ServerAdmin [EMAIL PROTECTED] > > > > > > changed #ServerName to ServerName 127.0.0.1 > > > > > > removed the #precedding"AddHandler cgi-script .cgi > > > > > > > > I then placed the following program named "hello.cgi" in the directory > > c:/apache/cgi-bin/ > > > > > > ## > > > > #!/usr/local/bin/perl > > > > # hello.pl -- my first perl script! > > > > print "Content-type: text/html\n\n"; > > > > print "Hello, world!\n"; > > > > > > ### this script runs ok from the command >line## > > > > > > > > I then went to the url http://localhost/cgi-bin/hello.cgi > > > > > > I get this error message > > > > ## > > > > Fri Oct 12 20:48:47 2001] [error] [client 127.0.0.1] couldn't spawn child > > process: c:/apache/cgi-bin/hello.cgi > > > > ## > > > > > > what am I doing wrong? Activestate Perlis installed at > > C:\Perl\bin\perl.exe I think this has something to do with it. But I Ive > > been looking at this config file for the last eight hours and dont know > > anymore.. > > > > > > Anyway If you can help thanks in advance... > > > > Ric > > > > > > > > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ 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: Using Win32::ODBC
I would second what Curtis said. Avoid Win32::ODBC entirely.
Not just because of the features, but because it's also not going to be
portable anyway beyond simple CGI on WinNT. Every few months someone on the
ActiveState PerlEx (loosely known as the NT equivalent to mod_perl) mailing
list posts
"Win32::ODBC mysteriously crashes on me"...
And perennially, the response is "Don't use Win32::ODBC".
The reason is that Win32::ODBC is not thread safe. DBD::ODBC is. NT is a
multi-threaded OS so if you start using a shared interpreter model for
speed like PerlEx, you'll run into a lot of problems. And even if you don't
now, you might later and then you will run into problems.
Here is a snippet from PerlEx tech support (Murray Nesbitt) on the issue
"Win32::ODBC is notoriously unreliable when used with PerlEx, as this
extension is not thread-safe. You will likely have much better luck with
DBD::ODBC which is thread-safe, portable, and more actively maintained
than Win32::ODBC. More details and a list of known thread-safe extensions
is at:
http://www.activestate.com/ppm/threads.htm";
As an aside, these issues are also similar to what will become issues with
Apache 2.0. Although I am not the biggest fan of PerlEx (eg no formal
support for taintmode), I think ActiveState has done mod_perl 2.0 a huge
advance service by basically culling out modules that won't work with a
multi-threaded Perl interpreter pool since this is exactly how PerlEx works
today.
Later,
Gunther
PS I notice the URL from Murray's msg no longer works and I can't seem to
find a similar reference on ActiveState to a list of threadsafe modules
although it might now be embedded in the docs to Win32 Perl.
At 12:38 AM 10/10/2001, Curtis Poe wrote:
>--- [EMAIL PROTECTED] wrote:
> > I'm successfully connecting to a Pervasive 7 database with my PERL program
> > when running from the command line.
> >
> > I try to run the program in my webbrowser and I get the following error.
> >
> > Error connecting to MO Error: [802] [] "[Pervasive Software][ODBC
> > Interface][Pervasive Software SQL Engine]General error."
> >
> > (MO is the name of my system DSN)
> >
> > any ideas how to fix this so it runs on the web server properly
>
>While this is not the answer you seek, have you considered switching to
>DBI with the DBD::ODBC
>driver? This would give you several advantages:
>
>1. It's portable.
>
>2. Placeholders are supported. That, combined with DBD::OBDC's separate
>prepare and execute
>statements could let you do this:
>
> my $sql = 'SELECT firstName, lastName FROM table WHERE uid=?';
> my $sth = $dbh->prepare( $sql );
> foreach my $uid ( @uid ) {
> push @names, $sth->fetchrow_arrayref( $uid );
> }
>
>Since the statement is already prepared, this is much faster than Win32::ODBC.
>
>3. Notice I didn't use any error handling in step 2? (ignoring for the
>moment that I could have
>had an invalid $uid) DBI allows me to set RaiseError automatically, thus
>catching errors for me.
>For large applications, this is critical.
>
>4. Win32::OBDC has no bind parameters. As a result, you can't specify a
>BLOB, for example.
>Forget about using binary data.
>
>5. More programmers know DBI and thus can offer you better support.
>
>6. DBI has the DBI->trace method, which is a godsend for debugging.
>
>Cheers,
>Curtis "Ovid" Poe
>
>=
>Senior Programmer
>Onsite! Technology (http://www.onsitetech.com/)
>"Ovid" on http://www.perlmonks.org/
>
>__________
>Do You Yahoo!?
>NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
>http://geocities.yahoo.com/ps/info1
>
>--
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__
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: Is this secure
$file ) || return "Could not find file $file";
> my @lines = ;
> close FILE || return "Could not close filehandle";
> logit("Closed file $file",2);
> for (@lines) {
> $rv .= $_;
> }
> return $rv;
>}
>
>sub logit {
> my $warning = shift;
> my $level = shift || 1;
> my $caller = (caller(1))[3];
> if ($debug >= $level) {
> warn "$caller:\t$warning";
> }
>}
>
>1;
>
>
>
>--
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__
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: CGI Calendar Script
At 08:55 AM 7/10/2002, David T-G wrote: >Roger -- > >...and then Roger Spears said... >% >% Hello, > >Hi! > > >% >% Well for my next project I'm trying to build an interactive calendar >% system using Perl/CGI. > >Neat. I'd be quite interested in the finished product. I've been >searching (fruitlessly) for a calendar that will print multi-day events >in a lined-up bar across the days instead of jumbling events together. >Will yours work for me? Our calendar does something like this within our day view. We call it a "chunking algorithm" to allow events to span different hours and overlap with other events within the same day while looking nice. Our month and week views do not do this same chunking (the events are just repeated) but the general chunking algorithm could probably be reused in our month and week views if this was something you were keen on. It's part of the downloads on http://www.extropia.com/ Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How fatalsToBrowser works ?
You might find this link useful...
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl
Basically, fatalsToBrowser is "OK" to use, but it can be fraught with
underlying issues that Matt outlines pretty well in the above URL. Has
also given a talk on the subject at the last couple of O'Reilly conferences.
As an aside, at eXtropia, therer was a period of a couple years where we
used fatalsToBrowser quite a bit. And everytime some incompatibility
happened with mod_perl or some other advanced environment, we'd submit
the bug (and sometimes a sample patch) to Lincoln Stein who has been
very helpful.
However, Perl 5.6.0 in particular ruined all of that for us by changing
the behavior of how fatalsToBrowser worked making eval {} tests
impossible to use in your code. 5.6.1 fixed the problem, but there are
MANY ISPs still running 5.6.0 and our support email volume skyrocketted.
So now when we give out scripts we provide a "debug" version of the CGI
which calls the original CGI behind the scenes wrapped in an eval system
that can do the same thing as fatals To Browser. When you are done
"debugging", the intention is that you disable it by changing $DEBUG = 0
instead of $DEBUG = 1 or you delete the debug script off your directory.
Generally, you shouldn't enable fatalsToBrowser in production as a
general security practice.
The nice thing about making the debug into a separate script that calls
the original CGI is that if you want to re-enable debugging output in
production, your production users pointing to the main CGI script will
not get any additional information. But you can still troubleshoot with
the "debug" version of the URL which your production users won't have
(unless they've been hacking around).
This is similar in concept to the fact that CGIWRAP has a debug and
nondebug version I think. Or at least that's the inspiration for me to
have written this. If you want this "debug" wrapper program, you can get
it by downloading just about any app off our website such as "address
book". If you download "address book", you will see "address_book.cgi
and address_book_debug.cgi". The debug one can be easily modified to
work with your CGI script and as far as I know has no weird Perl version
problems like fatalsToBrowser.
Later,
Gunther
Connie Chan wrote:
>Thanks everybody, I've made it =))
>
>
>package Die4CGI;
>use strict;
>
>$main::SIG{__DIE__} = \&Die4CGI::die;
>
>sub die
>{ my $dieMesg = shift; $dieMesg =~ s/ at .+$//;
> my ($package, $file, $line) = caller;
> $file =~ s/^C:\\Server\\Staff\\Connie\\Project\\onTry\\/\\/;
> $file =~ s/\\/\//g;
> print "Content-type: text/html\n\n";
> print <<"HTML";
># A lot of html #
> Garfield said: $dieMesg happens at: $file line $line.
># A lot of html #
>HTML
>; exit(0);
>}
>
>1;
>
>
>So I can call it like the normal :
>
>use strict;
>use Die4CGI;
>
>my $file = 'somewhere/somewhere';
>open FH, $file or die "$!"; # prints what I want
>
>Another fatalsToBrowser, simple and lovely!! ;)
>
>*BUT!! I still not understand, how can this overided
>the orgional "die" ? Why shouldn't I write as :
>open FH, $file or Die4CGI::die($!) ;
>
>Would anybody tell me more ?
>
>Rgds,
>Connie
>
>
>
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
