[26178] in Perl-Users-Digest
Perl-Users Digest, Issue: 8367 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 29 11:05:34 2005
Date: Mon, 29 Aug 2005 08:05:03 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 29 Aug 2005 Volume: 10 Number: 8367
Today's topics:
Dealing with signup bots with a Perl CGI script <ihaveno@email.add>
Re: Dealing with signup bots with a Perl CGI script <no@email.com>
Re: desc $table in DBI Oracle <harrism@ascc.lucent.com>
Re: MJD HOP influence (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Aug 2005 07:30:29 GMT
From: Joe <ihaveno@email.add>
Subject: Dealing with signup bots with a Perl CGI script
Message-Id: <pQyQe.145116$dP1.501273@newsc.telia.net>
Hello,
These days, there seems to be more and more sites relying on showing the
user weird images of characters which they then have to type in a text box
to submit a form.
I'm in the process of developing a GPL'ed website system. The system itself
works fine, so I'm looking at ways to reduce the ability for
scripts/bots/whatnot to sign up on the site or use anything that's
accessible to anonymous users (which, granted, isn't much at the moment).
But "show 'em an image" seems to be the only solution I run into.
I'm not sure if I consider that a solution, because... well, what if it's a
blind or visually impaired person trying to sign up? I want the system to
be accessible to everyone, not just people with good eyesight. (And even
with my perfect vision, I have trouble reading some of the more "unique"
graphic texts used on some sites.)
Is anyone aware of an alternative solution? The system already requires
e-mail verification, but I've seen bots that automatically read and verify
the e-mail (particularly for phpBB verification ... a bot signs up on a
phpBB board, verifies the e-mail, then proceeds to make a post on the
forum!).
So basically, I'm looking for ideas on ways to avoid issues like this,
before anyone uses my code (besides myself).
As it is, I've got a "hidden security code" system that reduces that can
reduce some such nastiness, and even auto-ban/report to admin if there's
something funny going on. But I already know it's flawed and easily
bypassable.
The limitations:
1) It's a Perl system, so anything that can be done backend-wise in Perl is
good.
2) It needs to be accessible. (Even to the blind.)
3) It cannot involve changes to the actual web server itself. (The code
needs to be useable on web hotels and such where Perl is allowed, but
there's no control over the server itself. If a Perl Module is needed but
the host doesn't have it installed, the system has a way to deal with
that.)
Has anyone seen any unique or "working" ways of handling such an issue, or
at least severely reducing the potential for it, that could be implemented
in Perl scripts?
Thanks,
Joe
------------------------------
Date: Mon, 29 Aug 2005 10:21:27 +0100
From: Brian Wakem <no@email.com>
Subject: Re: Dealing with signup bots with a Perl CGI script
Message-Id: <3ng2cmF19te9U1@individual.net>
Joe wrote:
> Hello,
>
> These days, there seems to be more and more sites relying on showing the
> user weird images of characters which they then have to type in a text box
> to submit a form.
>
> I'm in the process of developing a GPL'ed website system. The system
> itself works fine, so I'm looking at ways to reduce the ability for
> scripts/bots/whatnot to sign up on the site or use anything that's
> accessible to anonymous users (which, granted, isn't much at the moment).
>
> But "show 'em an image" seems to be the only solution I run into.
>
> I'm not sure if I consider that a solution, because... well, what if it's
> a blind or visually impaired person trying to sign up? I want the system
> to be accessible to everyone, not just people with good eyesight. (And
> even with my perfect vision, I have trouble reading some of the more
> "unique" graphic texts used on some sites.)
>
> Is anyone aware of an alternative solution? The system already requires
> e-mail verification, but I've seen bots that automatically read and verify
> the e-mail (particularly for phpBB verification ... a bot signs up on a
> phpBB board, verifies the e-mail, then proceeds to make a post on the
> forum!).
>
> So basically, I'm looking for ideas on ways to avoid issues like this,
> before anyone uses my code (besides myself).
>
> As it is, I've got a "hidden security code" system that reduces that can
> reduce some such nastiness, and even auto-ban/report to admin if there's
> something funny going on. But I already know it's flawed and easily
> bypassable.
>
> The limitations:
> 1) It's a Perl system, so anything that can be done backend-wise in Perl
> is good.
> 2) It needs to be accessible. (Even to the blind.)
> 3) It cannot involve changes to the actual web server itself. (The code
> needs to be useable on web hotels and such where Perl is allowed, but
> there's no control over the server itself. If a Perl Module is needed but
> the host doesn't have it installed, the system has a way to deal with
> that.)
>
>
> Has anyone seen any unique or "working" ways of handling such an issue, or
> at least severely reducing the potential for it, that could be implemented
> in Perl scripts?
>
>
> Thanks,
> Joe
You could ask a question that a bot could not answer. If John has 4 apples
and eats 2 of them, how many apples does he have left? Make up a load of
questions like this with different sentence structure and with different
themes. Unless someone was hell-bent on writing an auto-registering-bot I
think that would suffice.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
------------------------------
Date: Mon, 29 Aug 2005 02:28:47 -0400
From: Marcus Eric Harris <harrism@ascc.lucent.com>
To: ngoc <ngoc@yahoo.com>
Subject: Re: desc $table in DBI Oracle
Message-Id: <Pine.GSO.4.61.0508290220390.5802@nahovf>
Hello,
I was wondering if you ever got an answer to your question?
If not, I may have a solution for you. I was trying to
resolve the very same issue a couple of years ago and
wrote this quick script as a test to see if it could
be done using the 'table_info()' method provided by
the DBI module.
Here is the script:
<Start>
#! /usr/bin/perl
use DBI;
#
# Create the database handle. Be sure to replace everything
# between the '<>' (not including them) with the values which
# are specific to your system.
#
$DBHandle = DBI->connect(
"dbi:Oracle:host=<HostName>;sid=<DBName>",
"<UserID>",
"<Password>"
);
#
# Fill-in all or part of your table schema name here.
# If you use the entire name, you may remove the wildcard (%).
#
%Attributes = (
TABLE_SCHEM => "<SchemaID>%",
);
#
# Define the statement handle to get the table metadata.
#
$SQLStatement = $DBHandle->table_info(\%Attributes);
#
# This part is not really necessary. It just allows
# for an orderly display of the output in tabular
# format.
#
open(HEADER);
$~ = "HEADER";
write();
select(STDOUT);
close(HEADER);
open(TABLE_INFO);
$~ = "TABLE_INFO";
while (($Catalog, $Owner, $TableName, $Type, $Remarks) = $SQLStatement->fetchrow_array())
{
foreach ($Catalog, $Owner, $TableName, $Type, $Remarks)
{
$_ = "N/A" unless defined($_);
}
write();
}
select(STDOUT);
close(TABLE_INFO);
#
# Define the header and body formats for the output.
#
format HEADER =
Catalog Owner Table Name Type
---------- ----------- ---------------------------- --------------------
.
format TABLE_INFO =
@<<<<<<<<< @<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<
$Catalog, $Owner, $TableName, $Type
.
</End>
There are other values availble to you via 'table_info()', only
a few of which are displayed in the table above.
Once I got this issue answered, I was able to quickly
code something more specific to the work I was doing
at the time.
If you have other questions, let me know.
Marcus E. Harris
Aug 1, ngoc said:
n| Hi
n| I use "my $header_sql = qq { desc $table };". It does not work.
n| But "select column_name from all_tab_columns where table_name = \'$table\'"
n| work.
n| My problem is "desc $table" matching which "select * from $table"
n| than
n| select column_name ...........
n| (I mean data and column name order matching).
n| Thanks
n|
--
.:::::::::::::::::::::::::::: Signature :::::::::::::::::::::::::::::::::.
. .
. Marcus E. Harris [Engineer] | Work Phone: 919.463.3162 .
. Lucent Technologies | FAX: 919.463.4479 .
. 200 Lucent Lane | E-Mail: harrism@lucent.com .
. Room #SE405G | Conf. Bridge: 800.450.3848, x322703 .
. Cary, North Carolina 27511 | Lucent IM: harrism@im.lucent.com .
. .
. .
. "If you can't be a good example, then you'll just have to be a .
. horrible warning..." -- Catherine Aird .
. .
.:::::::::::::::::::::::::::: Signature :::::::::::::::::::::::::::::::::.
------------------------------
Date: 29 Aug 2005 09:54:05 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: MJD HOP influence
Message-Id: <deulvt$loj$1@mamenchi.zrz.TU-Berlin.DE>
Matija Papec <perl@my-header.org> wrote in comp.lang.perl.misc:
>
> It seems that functional approach is better suited for smaller "classes"
> compared to classical OOP.
With "functional approach", do you mean a class whose objects are
coderefs? What is the "classical" approach and what are the advantages
you see?
> Thinking in such way is challenging and pretty
> new to me so I would be interested to hear suggestions; eg. is there some
> flaw which can show in threading environment or how to optimize this very
> basic OO example below.
There is no OO in your example. The hallmark of Perl OO is that objects
are blessed into their class. This never happens here. Neither are the
calls
$obj->(addcond => [id => 7]);
etc. method calls, this is just the syntax to call a coderef. So whatever
you have built, it isn't an alternative to a classical OO approach.
Otherwise, classes whose objects are coderefs offer better protection
(and harder access to) the the object variables, assuming that the
object variables are implemented as private lexicals. They are usually
harder to deal with than more conventional implementations. The size
of the class (in terms of number and complexity of methods) has little
to do with the advantages and drawbacks of this approach.
Anno
> ===========================
> use strict;
> use warnings;
>
> my $obj = Child(foo => 1, bar =>2);
> $obj->(addcond => [id => 7]);
> $obj->(addcond => [name => "lucas"]);
>
> print $obj->(dumper => 1) if $obj->(can => "dumper");
>
>
> sub Child {
> #
> # child class
> #
> our ($AUTOLOAD, $SUPER);
> # child object data
> my @foobar;
>
> my $m = {
> AUTOLOAD => sub {
> my $self = shift;
> print "There is no $AUTOLOAD!\n";
> return;
> },
> dumper => sub {
> my $self = shift;
> $SUPER->(dumper => @_);
> },
> addcond => sub {
> my $self = shift;
> # get $SUPER via $self
> # $AUTOLOAD contains current method name
> $self->("SUPER")->($AUTOLOAD => @_);
> },
> };
> return newclosure(usebase => \&Parent, $m, @_);
> }
>
> sub Parent {
> #
> # parent class
> #
> use Data::Dumper;
> # object data
> my %arg = @_;
> my @cmdcond;
>
> my $m = {
> dumper => sub {
> my $self = shift;
> Dumper \@cmdcond, \%arg;
> },
> addcond => sub {
> my $self = shift;
> push @cmdcond, shift;
> },
> };
> return newclosure($m, @_);
> }
>
>
> #########################################
> sub newclosure {
> #
> our ($AUTOLOAD, $SUPER);
> my $m = shift;
>
> my $usebase;
> my $super;
> # inheritance?
> if ($m eq "usebase") {
> $usebase = shift;
> $m = shift;
> $super = &$usebase;
> }
>
> # core methods
> $m->{SUPER} = sub { $super };
> $m->{can} = sub {
> my $self = shift;
> my $sub = shift;
> $m->{$sub} || $super->(can => $sub) || $m->{AUTOLOAD};
> };
>
> my $self;
> return $self = sub {
> my $sub = shift;
> local $AUTOLOAD = $sub;
> local $SUPER = $super;
>
> # who you gonna call?
> return
> $m->{$sub} ? $m->{$sub}->($self, @_) :
> $super->(can => $sub) ? $super->($sub, @_) :
> $m->{AUTOLOAD}->($self, @_);
> };
> }
>
>
> --
> Matija
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8367
***************************************
