Re: handling eval in ePerl
> Umm I didnt mean to offend anyone in my previous posting - I did say I
> probably hadnt presented my situation properly.
No problem, I just meant "don't give up so quickly."
> Ofcourse you noticed I wrote ePerl/EmbPerl/Mason ?? I clubbed them
> together since I assume among other things you can embed perl code in
> HTML using either of them.
You can, but they don't share any code with ePerl.
> My problem is that die works fine as such but it conks out if done
> inside a eval.
Okay, I missed the part about eval() before. Take a look at this code
from Parse::ePerl::Evaluate() :
local $SIG{'__DIE__'} = sub { $error .= $_[0]; };
That's going to kill your exception handling code. You need to change
that if you want to be able to use eval() in your code. Matt has an
explanation of this in the exceptions part of the mod_perl Guide.
> It feels like being told to
> change gcc's code if my C code is not working :) - yah both of them
are
> written in C .
Apache::ePerl is written in perl. It calls Parse::ePerl to do the dirty
work, and some of that is written in C, but not the part that's causing
you problems.
- Perrin
Re: handling eval in ePerl
On Mon, 21 Jan 2002, Mithun Bhattacharya wrote:
> Perrin Harkins wrote:
>
>
> Umm I didnt mean to offend anyone in my previous posting - I did say I
> probably hadnt presented my situation properly.
I don't think anyone was offended. Perrin was just trying to help you see
why people might not have replied. That's what I got from the tone anyway.
> > The Apache::ePerl code is very simple, and I suggest you read it at some
> > point. It attempts to eval() your code, and does the behavior you saw
> > if it fails (which is what happens when your script does a die()). I
> > don't think you can change that without changing the code, but that's
> > pretty easy to do.
>
> My problem is that die works fine as such but it conks out if done
> inside a eval.
>
> --
> <%
> die "blah blah blah";
> %>
> --
>
> redirects me to the default error page.
>
> --
> <%
> eval {die "blah blah blah";};
> %>
> --
>
> on the other hand says the following.
>
> --
> Apache::ePerl
> Version 2.0214
>
> ERROR:
> Error on evaluating script from P-code
>
> Contents of STDERR channel:
>
> blah blah blah at //test.html line 2.
> --
It looks to me like the generated code that ePerl is trying to eval is
bad. That seems like it's most likely this is an actual ePerl problem, and
so the only thing I can suggest is you hack the ePerl code to actually
display $@ when the evaluation of the "script from P-code" occurs (why on
earth aren't they doing that already??). Also I suggest while you're in
there, have it print the script to STDERR before doing the eval, so you
can check the error log and see what ePerl thinks your parsed script looks
like.
> I am not sure why that might be considered acceptable response but it
> really makes my code a lot more messier trying to circumvent that.
>
> If I could have fixed Apache::ePerl I wouldnt be asking the question
> here - I usually dont go around asking questions to show people how much
> I know about anything. I am not asking to be spoonfed or something but
> if there is something which can be done without changing the
> Apache::ePerl code I would opt for that. It feels like being told to
> change gcc's code if my C code is not working :) - yah both of them are
> written in C .
The difference being that gcc is maintained, so you might stand a cat in
hell's chance of some help from the authors or getting a bug fix.
Unfortunately ePerl isn't maintained, so you have to open the bonnet (hood
to USians) and fix things yourself.
--
<:->Get a smart net
handling eval in ePerl
Perrin Harkins wrote:
Umm I didnt mean to offend anyone in my previous posting - I did say I
probably hadnt presented my situation properly.
> First, ePerl has nothing to do with Embperl or Mason. It is a totally
Ofcourse you noticed I wrote ePerl/EmbPerl/Mason ?? I clubbed them
together since I assume among other things you can embed perl code in
HTML using either of them.
> The Apache::ePerl code is very simple, and I suggest you read it at some
> point. It attempts to eval() your code, and does the behavior you saw
> if it fails (which is what happens when your script does a die()). I
> don't think you can change that without changing the code, but that's
> pretty easy to do.
My problem is that die works fine as such but it conks out if done
inside a eval.
--
<%
die "blah blah blah";
%>
--
redirects me to the default error page.
--
<%
eval {die "blah blah blah";};
%>
--
on the other hand says the following.
--
Apache::ePerl
Version 2.0214
ERROR:
Error on evaluating script from P-code
Contents of STDERR channel:
blah blah blah at //test.html line 2.
--
I am not sure why that might be considered acceptable response but it
really makes my code a lot more messier trying to circumvent that.
If I could have fixed Apache::ePerl I wouldnt be asking the question
here - I usually dont go around asking questions to show people how much
I know about anything. I am not asking to be spoonfed or something but
if there is something which can be done without changing the
Apache::ePerl code I would opt for that. It feels like being told to
change gcc's code if my C code is not working :) - yah both of them are
written in C .
Mithun
Re: How to handle die
> Umm it didnt really answer my original query but I guess since no one > has answered it - either I didnt present it correctly or no one has a > answer to it. Or you posted it late on Saturday night on a weekend when most US workers have Monday off and may be travelling. Not everyone is on the same schedule as you, so give it a little time. > I probably wont jump into the "I want a newbie mailing list" fray for > this though ;). I don't think it would make a difference. It would be pretty much the same people on either list. There are a couple of people on this list who use ePerl. You might want to repost with "ePerl" in your subject. However, most of us no longer use it. ePerl is getting old at this point and has a pretty small feature set compared to the more actively maintained alternatives. Here's an attempt to answer your questions: > 1. Is die supposed to be handled by ePerl/EmbPerl/Mason > ... or did ePerl end up over ridding something. In that > case I would rather have it restored to the default. First, ePerl has nothing to do with Embperl or Mason. It is a totally separate program. The Apache::ePerl code is very simple, and I suggest you read it at some point. It attempts to eval() your code, and does the behavior you saw if it fails (which is what happens when your script does a die()). I don't think you can change that without changing the code, but that's pretty easy to do. > 2. How do I implement a solution throughout the site without > having to do goofy stuff in every HTML page or module. Solution to what? To having die() trapped? Changing the Apache::ePerl code will be a site-wide change, so I'd suggest you do it there. > 3. Why would anyone do that in the first place ? Why catch exceptions? Usually to allow the program to try something else, clean up resources, or print a useful error message. - Perrin
Re: How to handle die
___cliff rayman___ wrote: > [EMAIL PROTECTED] > > To subscribe to this Majordomo-controlled mailing list, just send an E-mail Umm it didnt really answer my original query but I guess since no one has answered it - either I didnt present it correctly or no one has a answer to it. I probably wont jump into the "I want a newbie mailing list" fray for this though ;). Mithun
Re: slow regex [BENCHMARK]
> under mod_perl this takes 23 seconds. running the perl "by hand" (via > extracting this piece into a seperate perl script) on the same data takes > less than 1 second. Are you sure that the string you're regex'ing is the same in both cases? Why are you using the /o operator? CG isn't a variable, is it? - Perrin
Re: slow regex [BENCHMARK]
Paul Mineiro wrote:
> hi. i'm running mod_perl 1.26 + apache 1.3.14 + perl 5.6.1
>
> i have a loop in a mod_perl handler like so:
>
> my $stime = time ();
>
> while ($seq =~ /CG/og)
> {
> push @cg, pos ($seq);
> }
>
> my $etime = time ();
>
> warn "time was: ", scalar localtime ($stime), " ",
> scalar localtime ($etime), " ", $etime - $stime;
>
>
> under mod_perl this takes 23 seconds. running the perl "by hand" (via
> extracting this piece into a seperate perl script) on the same data takes
> less than 1 second.
>
> has anyone seen this kind of extreme slowdown before?
Paul,
Your benchmark is wrong. You cannot benchmark code using wallclocks
unless you run on DOS-like system. On multi-processes systems many
processes compete over CPU, so each process gets a little bit of CPU
time every so often, so if you count wallclocks you don't count the
execution time of your program but of all programs that happen to run at
the same time.
To count CPU clocks use Benchmark.pm, it has a fine documentation and
examples so I won't repeat them here. Please fix your benchmark and run
it again.
Also you may want to check certain sections in
http://perl.apache.org/guide/performance.html
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
slow regex [BENCHMARK]
hi. i'm running mod_perl 1.26 + apache 1.3.14 + perl 5.6.1
i have a loop in a mod_perl handler like so:
my $stime = time ();
while ($seq =~ /CG/og)
{
push @cg, pos ($seq);
}
my $etime = time ();
warn "time was: ", scalar localtime ($stime), " ",
scalar localtime ($etime), " ", $etime - $stime;
under mod_perl this takes 23 seconds. running the perl "by hand" (via
extracting this piece into a seperate perl script) on the same data takes
less than 1 second.
has anyone seen this kind of extreme slowdown before?
-- p
info:
apache build options:
CFLAGS="-g -g -O3 -funroll-loops" \
LDFLAGS="-L/home/aerives/lib -L/home/aerives/lib/mysql" \
LIBS="-L/home/aerives/genegrokker-interface/lib
-L/home/aerives/genegrokker-interface/ext/lib -L/home/aerives/lib
-L/home/aerives/lib/mysql" \
./configure \
"--prefix=/home/aerives/genegrokker-interface/ext" \
"--enable-rule=EAPI" \
"--enable-module=most" \
"--enable-shared=max" \
"--with-layout=GNU" \
"--disable-rule=EXPAT" \
"$@"
mod_perl build options:
configure_options="PERL_USELARGEFILES=0 USE_APXS=1
WITH_APXS=$PLAYPEN_ROOT/ext/sbin/apxs EVERYTHING=1
INC=$PLAYPEN_ROOT/ext/include -DEAPI"
perl -V:
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.13, archname=i386-linux
uname='linux duende 2.4.13 #1 wed oct 31 19:18:07 est 2001 i686 unknown '
config_args='-Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux
-Dprefix=/usr -Dprivlib=/usr/share/perl/5.6.1 -Darchlib=/usr/lib/perl/5.6.1
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5
-Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.6.1
-Dsitearch=/usr/local/lib/perl/5.6.1 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Duseshrplib
-Dlibperl=libperl.so.5.6.1 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-DDEBIAN -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-DDEBIAN -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.4 (Debian prerelease)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -ldb -ldl -lm -lc -lcrypt
perllibs=-ldl -lm -lc -lcrypt
libc=/lib/libc-2.2.4.so, so=so, useshrplib=true, libperl=libperl.so.5.6.1
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 11 2002 04:09:18
%ENV:
PERL5LIB="/home/aerives/genegrokker-interface/lib/perl5:/home/aerives/genegrokker-interface/ext/lib/perl5:/home/aerives/lib/perl5"
@INC:
/home/aerives/genegrokker-interface/lib/perl5
/home/aerives/genegrokker-interface/ext/lib/perl5
/home/aerives/lib/perl5
/usr/local/lib/perl/5.6.1
/usr/local/share/perl/5.6.1
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.6.1
/usr/share/perl/5.6.1
/usr/local/lib/site_perl
Re: Single login/sign-on for different web apps?
On Thu, 17 Jan 2002, Gunther Birznieks wrote: > >Of course, the best authentication system for banking I've seen is > >from UBS. They send you a scratchlist of around 100 numbers. Every > >time you login you use one of the numbers and cross it off. Very > >slick. > > Does that really work in practice? That sounds really annoying. Is this for > business banking or for retail? How do they get the next 100 numbers to the > user? Do they mail it out when they've used 90? > > It sounds like it would be less annoying to use certificates and some > plug-in token there is going to be that much extra work to deal with a > password sheet. Alternately, for a high-tech approach, RSA makes a nice product called a SecurID token (Well, one of mine says Security Dynamics on the back, but the new ones definitely say RSA). Actually, they make two, one nice, one not nice. The nice one has a keypad where you enter in a pin, press a button, and it generates a temporary id based on its serial number, your pin, and the current time interval; the time interval changes every minute or two. The not nice one has no keypad; it works like the other would if you didn't enter a pin. I know of several companies that use these; they tend to work fairly well. (I had one break on me, but I gave it a lot of abuse first; it lasted almost half of its battery span in spite of not being taken care of.) Ed
Re: Single login/sign-on for different web apps?
On Wed, 16 Jan 2002, Medi Montaseri wrote: > I think Netegrity single sing-on system modifies the HTTP server > (possible with mod_perl) to overload or override its native > authoentication and instead contact a Host, Database or LDAP to get > the yes or no along with expiration data it then sends its finding > to the CGI by sending additonal HTTP Header info. A CGI program can > then go from there... Something like this. Basically, it has modules, plugins, or access instructions, as appropriate, for various web servers, to configure them to use it. I know it gives an LDAP interface, and I'm assuming it gives an LDAPS interface; I'm not sure what others it may present. > I might not have this 100%, but perhaps we can learn from those > commercial products. > > Someone suggested using LDAP and RDBMS, my question is why both, why > not just RDBMS. Why not just LDAP? As someone working on rolling out a single sign-on solution with LDAPS, I really want to know... (We're planning on getting Netegrity for its distributed administration stuff; at that time, we'll start using its web server configuration stuff for any new web servers. Until that time, we're rolling out LDAPS, and we're not currently planning on converting systems we roll out in the interm to Netegrity.) Incidentally, we're being a bunch of lazy bums, compared to the rest of y'all. We're considering single sign-on to mean they only need to keep track of one userid and password (unless they need to access classified or otherwise restricted stuff.) If they go to different sites and have to log on again, we don't currently care. (Basically, we have too many sites created by too many groups. We'll share the same login between servers run by the same group, but beyond that, security concerns outweigh user convinience.) Ed > Aaron Johnson wrote: > >> We are working on/with a similar system right now. >> >> We have an application that is written in Perl, but the people >> visiting will most likely be signing on at a different point then our >> applications sign in page. Our system was built to use its own >> internal database for authentication and their app/login uses a >> different method. The design requirements were that each side would >> have to do as little possible to modify there application to work in >> our single sign on solution. >> >> We have the luxury of not being overly concerned with the security >> aspect so please keep that in mind. >> >> We setup a nightly sync program that verifies the data in the current >> database vs. their login user information database. >> >> Here is a less then detailed summary of how the system operates. >> >> 1) The user logs into the application through their application and >> they are sent a cookie that contains the user name. >> >> 2) All links to our application are sent to a single page on their >> end with the full url of the page they want as part of the query >> string. >> >> 3) They verify that the user is valid using whatever method they >> want. >> >> 4) The user is then redirected to a special page in our application >> that expects the query string to contain two items, the user name and >> the final URL to go to. >> >> 5) Our application verifies the HTTP_REFFERER and the query string >> contains valid values. >> >> 6) Our application checks the database for a user matching the name >> sent in. Then if the user already has a session if they do then they >> are redirected to the correct page, otherwise it does a lookup in our >> system to create a session for the user based on the incoming user >> name and then redirects to the final URL. >> >> Now a user can go between the two applications without concern since >> they have a cookie for each domain. >> >> If the user comes to our site the reverse of the above occurs. >> >> This allowed us to plug into existing applications without a lot of >> rework. It is also fairly language/platform independent. >> >> As stated above I know there are some large security issues with this >> approach. >> >> Aaron Johnson >> >> Vsevolod Ilyushchenko wrote: >> >>> Hi, >>> >>> Have you ever ran into the problem of putting up many separate web >>> apps on several machines in your company/university/whatever that >>> are written from scratch or downloaded frow the Web and each of >>> which has its own user database? What would you think is a good way >>> to make the system seem more cohesive for the users? >>> >>> It occurs to me that 1) for the single login they all should use the >>> same user database (obviously :), and 2) for the single sign-on >>> there must be a way of storing the session information. That is, >>> once I login in the morning to the first app, I get a cookie, a >>> ticket or something similar, and then, as I go from app to app, I >>> will not have to re-enter my credentials because they are supplied >>> by a cookie. Apache::Session sounds like the right tool for the job. >>> (Did I hear "Kerberos"? :) >>> >>> Has anyone
Re: Single login/sign-on for different web apps?
No. There are very important reasons why Apache by default puts an ACL restricting .ht* from being viewable. (Basically, the password encryption used in said file is moderately easily cracked via brute force.) One could use a file distributed using rsync(1) or some such (preferably with RSYNC_RSH=ssh). However, that's still a bit on the unsecure side, unless you really do trust everyone who is running one of these web servers. Ed On Wed, 16 Jan 2002, Medi Montaseri wrote: > I wonder if one could change the HTTP Server's behavior to process a > distributed version of "AuthUserFile" and "AuthGroupFile". > > That instead of > > AuthUserFile "/some/secure/directory/.htpasswd > > One would say > > AuthUserFile "http://xyz.com/some/directory/htpasswd"; > > Then write a GUI (web) inteface to this password and group file and > you have distributed authentication system. > > Ed Grimm wrote: > > > On Wed, 16 Jan 2002, Medi Montaseri wrote: > > > > > I think Netegrity single sing-on system modifies the HTTP server > > > (possible with mod_perl) to overload or override its native > > > authoentication and instead contact a Host, Database or LDAP to get > > > the yes or no along with expiration data it then sends its finding > > > to the CGI by sending additonal HTTP Header info. A CGI program can > > > then go from there... > > > > Something like this. Basically, it has modules, plugins, or access > > instructions, as appropriate, for various web servers, to configure them > > to use it. I know it gives an LDAP interface, and I'm assuming it gives > > an LDAPS interface; I'm not sure what others it may present. > > > > > I might not have this 100%, but perhaps we can learn from those > > > commercial products. > > > > > > Someone suggested using LDAP and RDBMS, my question is why both, why > > > not just RDBMS. > > > > Why not just LDAP? As someone working on rolling out a single sign-on > > solution with LDAPS, I really want to know... (We're planning on > > getting Netegrity for its distributed administration stuff; at that > > time, we'll start using its web server configuration stuff for any new > > web servers. Until that time, we're rolling out LDAPS, and we're not > > currently planning on converting systems we roll out in the interm to > > Netegrity.) > > > > Incidentally, we're being a bunch of lazy bums, compared to the rest of > > y'all. We're considering single sign-on to mean they only need to keep > > track of one userid and password (unless they need to access classified > > or otherwise restricted stuff.) If they go to different sites and have > > to log on again, we don't currently care. (Basically, we have too many > > sites created by too many groups. We'll share the same login between > > servers run by the same group, but beyond that, security concerns > > outweigh user convinience.) > > > > Ed > > > > > Aaron Johnson wrote: > > > > > >> We are working on/with a similar system right now. > > >> > > >> We have an application that is written in Perl, but the people > > >> visiting will most likely be signing on at a different point then our > > >> applications sign in page. Our system was built to use its own > > >> internal database for authentication and their app/login uses a > > >> different method. The design requirements were that each side would > > >> have to do as little possible to modify there application to work in > > >> our single sign on solution. > > >> > > >> We have the luxury of not being overly concerned with the security > > >> aspect so please keep that in mind. > > >> > > >> We setup a nightly sync program that verifies the data in the current > > >> database vs. their login user information database. > > >> > > >> Here is a less then detailed summary of how the system operates. > > >> > > >> 1) The user logs into the application through their application and > > >> they are sent a cookie that contains the user name. > > >> > > >> 2) All links to our application are sent to a single page on their > > >> end with the full url of the page they want as part of the query > > >> string. > > >> > > >> 3) They verify that the user is valid using whatever method they > > >> want. > > >> > > >> 4) The user is then redirected to a special page in our application > > >> that expects the query string to contain two items, the user name and > > >> the final URL to go to. > > >> > > >> 5) Our application verifies the HTTP_REFFERER and the query string > > >> contains valid values. > > >> > > >> 6) Our application checks the database for a user matching the name > > >> sent in. Then if the user already has a session if they do then they > > >> are redirected to the correct page, otherwise it does a lookup in our > > >> system to create a session for the user based on the incoming user > > >> name and then redirects to the final URL. > > >> > > >> Now a user can go between the two applications without concern since > > >> they have a cookie for each domain. > > >>
RE: mod_perl beginners list
On Tue, 15 Jan 2002, Robert Landrum wrote: > At 10:22 PM + 1/15/02, Matt Sergeant wrote: >>On Tue, 15 Jan 2002, Robert Landrum wrote: >> >>> I've seen nothing on this list that suggests that new users shouldn't >>> ask questions. If they don't ask questions because they're "afraid" >>> of the response they might get, then maybe they should stay home and >>> leave the programming to those people who have mettle to ask. >> >>I know where the sentiment comes from, but I really hope people don't read >>that and stay away in fear. Really folks, we're friendly here, so long as >>you play by the rules: quote cleanly, don't post HTML, and ask politely. > > Absolutly. My response was addressing Joe's statment that users are > too intimidated to post. I disagree. True programmers know no fear. True programmers know no fear of computers. However, any programmer who knows fear of RTFM would likely not post to any perl mailing list that didn't have beginner or newbie in the name, due to having experience with such lists before ever hearing about mod_perl. Count me as someone who would be interested in being on the list, though not necessarily very active. Ed
Re: Single login/sign-on for different web apps?
On Wed, 16 Jan 2002, Paul Lindner wrote: > On Wed, Jan 16, 2002 at 06:56:37PM -0500, Vsevolod Ilyushchenko wrote: >>> >>> 3) Perl-based applications can just use the module and the common key >>> to decrypt the contents of the cookie to find the authenticated >>> username. If the cookie is not present redirect to the central >>> authentication page, passing in the URL to return to after >>> authentication. >> >> Hmmm... Can I do it securely without using Kerberos? I think so. Looks like >> if I use https instead of http, people won't be able to steal my (encoded) >> session information as it is transmitted. And I can also add the IP address >> to the cookie information. >> >> But the cookies file might be readable by other people! If they can steal >> that file and change the IP address of another machine to yours, they can >> pretend they are you! >> I wonder if there is a way out of this... > > Yes, you use the timestamp. Just reauthenticate the user when they > try to do 'sensitive' activities. No, use session cookies - they're not stored on disk. If you need the system to retain knowledge through a browser shutdown, you can use a timestamped cookie to retain the user ID, but don't have it allow them to do anything other than not have to type their user ID in again (password screen has user ID filled out for them.) One can also mark the cookies such that they'll only be transmitted over https. $cookie = CGI::Cookie->new(-name => 'login', -value => tgape::setcookiepassword($uid, $pass), -domain => '.tgape.org', -path => '/', -secure => 1, ); If you feel the need to timestamp your session cookies, make the cookie include an encrypted timestamp. > For example you might allow someone to view their bank balance if they > typed their password within the last 2 hours. Transferring money > might require a valid password within the last 10 minutes.. Ah, but many systems will refresh a cookie on activity. So they view their balance, get a new cookie, and then transfer money. > Of course, the best authentication system for banking I've seen is > from UBS. They send you a scratchlist of around 100 numbers. Every > time you login you use one of the numbers and cross it off. Very > slick. All I need to do is find where you left the list. Written passwords are not anywhere near as secure as memorized passwords, unless the person carrying them around is really conscious about security concerns. Ed
Perl based Authentication on Apache
Dear addressed, pls, provide. i want to use the Perl-based Authentication Module Apache::authDBI written by Edmund Mergl. This is tested with Apache 1.3.6 Mod_perl 1.21 However i want to use it with Apache 2.0.30 Mod_perl 2.0 This is configured on the System with: httpd.conf: LoadModule perl_module modules/libmodperl.so Perlhandler Apache::AuthDBI ScriptAlias /ro-euma/ "/home/admin/ro-euma/" AllowOverride All SetHandler Apache::AuthDBI::authen Options ExecCGI Includes Order allow,deny Allow from all And in the corresponding .htaccess-File: == AuthName "RO-EUMA CSF" AuthType Basic PerlHandler Apache::AuthDBI::authen PerlSetVar Auth_DBI_data_source dbi:Pg:dbname=roeuma PerlSetVar Auth_DBI_username admin PerlSetVar Auth_DBI_password sita_fra # DBI->connect($data_source, $username, $password) PerlSetVar Auth_DBI_pwd_table login PerlSetVar Auth_DBI_uid_field username PerlSetVar Auth_DBI_pwd_field passwd #SELECT pwd_field FROM pwd_table WHERE uid_field=$user require user twaelde = Trying this i got the error-message inside the error log from Apache: configuration error: couldn't check user. No user file?: /ro-euma/index.pl i guess Apache does not access this AuthenticationHandler and requires something like a htpaaswd. Pls, what must i do to correct this ? Thks for every help in advance n Bgrds Thomas
QUESTION: how to debug segfault apache1.3.22/mod_perl1.26/HTML::Mason
I've recently built apache 1.3.22/mod_perl 1.26, statically with perl
5.6.1 on linux RH 7.0.
Am now getting SIGSEGV at various points in a HTML::Mason web
application. These happen usually, but not always, when making
DBD::Pg fetches (happens both with and without Apache::DBI).
This application was working perfectly under perl5.005,
apache1.3.20/mod_perl 1.24!
Is there any clear way to approach solving this? I've tried tracing
with strace (output attached below), and rebuilding everything again.
Any suggestions gratefully received, as it's getting a bit desperate here!
- Chris
strace output for _one_ of the crashing pages:
22372 brk(0x8957000)= 0x8957000
22372 read(7, "", 4096) = 0
22372 read(7, "", 4096) = 0
22372 close(7) = 0
22372 munmap(0x40019000, 4096) = 0
22372 stat("/tmp/dms_cache/obj/mc/metaform_submit.mc",
{st_mode=S_IFREG|0644, st_size=8385, ...}) = 0
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 send(4, "Q SELECT Name FROM Species WHERE SpeciesID=2 \0", 46,
0) = 46
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 select(5, [4], [], [4], NULL) = 1 (in [4])
22372 recv(4, "Pblank\0T\0\1name\0\0\0\4\23\377\377\0\0\0$D\200\0\0\0
\17E. GlobulusCSELECT\0Z", 16384, 0) = 51
22372 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
22372 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
22372 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 send(4, "Q\n\t\t\t\tSELECT
fieldname,label,valuesource,validsource,controltype,displayorder\n\t\t
\t\tFROM MetaForms,Meta
FormFields\n\t\t\t\tWHERE formname=\'add\' AND
tablename=\'locationrefs\' \n\t\t\t\tAND
metaforms.formid=metaformfields.formid
\n\t\t\t\tORDER BY displayorder ASC \0", 245, 0) = 245
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 select(5, [4], [], [4], NULL) = 1 (in [4])
22372 recv(4, "Pblank\0T\0\6fieldname\0\0\0\4\23\377\377\0\0\0hlabel\0
\0\0\4\23\377\377\0\0\0hvaluesource\0\0\0\0\31\377\377\3
77\377\377\377validsource\0\0\0\0\31\377\377\377\377\377
\377controltype\0\0\0\4\23\377\377\0\0\0\30displayorder\0\0\0\0\27\0\4
\377\377\377\377D\374\0\0\0\vbatchid\0\0\0\5.\0\0\0007
$value=Trials::getTrialEditBatch($dbi,$parent_key);\0\0\0\4\0\0\0
\10auto
\0\0\0\0050D\374\0\0\0\20lastmodified\0\0\0\0050\0\0\0\4\0\0\0\4\0\0\0
\fauto_now\0\0\0\0050D\374\0\0\0\22lastmodifiedby\0\0\0\
0050\0\0\0\22$value=$G_UID;\0\0\0\4\0\0\0\10auto\0\0\0\0050D\374\0\0\0
\vtrialid\0\0\0\0050\0\0\0\4\0\0\0\4\0\0\0\17auto_parent
\0\0\0\0050D\374\0\0\0\10name\0\0\0\10Name\0\0\0\4\0\0\0\4\0\0\0
\21text_required\0\0\0\0051D\374\0\0\0\17description\0\0\0\17D
escription\0\0\0\4\0\0\0\f$valid=1\0\0\0\ftextarea\0\0\0\0052D\374\0\0
\0\17mg"..., 16384, 0) = 805
22372 --- SIGSEGV (Segmentation fault) ---
22372 +++ killed by SIGSEGV +++
Summary of my perl5 (revision 5.0 version 6 subversion 1)
configuration:
Platform:
osname=linux, osvers=2.2.16-22, archname=i586-linux
uname='linux laptop 2.2.16-22 #1 tue aug 22 16:16:55 edt 2000
i586 unknown '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.0)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.1.92.so, so=so, useshrplib=false,
libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-
rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
