Hi all,
With Philip's encouragement and some extra work thrown in, I've made the
following conclusion:
1. If I install Apache 2 + MP2 + libapreq2 using the existing port tree
in FBSD6.1, it's fine.
2. If I install FBSD6.1 + cvsup-without-gui + updated port tree +
Apache2 + MP2 + libapreq2, it
find out if these people are getting into the system because they're
sending a cookie/login string with the right details for the wrong
account
using one-time-use capability keys that can only be obtained by reading
the user's e-mail will prevent erroneous log-ins while reducing the
number of cr
On Oct 3, 2006, at 4:01 PM, Dondi M. Stroma wrote:
One time, two different users reported this problem at roughly the
same time. But what is interesting is that not only did they both
enter *a* wrong account, they both entered the *same* wrong account!
are you sure the login routine is wor
Jonathan Vanasco wrote:
On Oct 3, 2006, at 1:30 AM, David Emery wrote:
Just a shot in the dark, but could it be a problem with your log-in
process
rather than a caching issue? Like maybe the unique value you're basing
the
user's identity on isn't quite as unique as you think?
I'm going to a
Tyler wrote:
> Another thing I just noticed is that you ran your tests under
> Apache::PerlRun, my mod_perl installation is using as its
> PerlResponseHandler ModPerl::PerlRun. What's the difference between
> the two?
Apache::PerlRun is the mod_perl 1 module, ModPerl::PerlRun is for
mod_perl 2.
use POSIX qw(tzset);
$ENV{'TZ'} = 'US/Eastern';
POSIX::tzset();
my $eastern = localtime();
$ENV{'TZ'} = 'US/Pacific';
POSIX::tzset();
my $pacific = localtime();
print "Content-type: text/plain\n\n",
"Eastern: $eastern\n",
"Pacific: $pacific\n";
Regards,
Philip
__ NOD32 1.1788 (20061003) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
Tyler Fullerton wrote:
>
> If I have the following script: www.somewhere.com/e3/datetz.cgi (where
> e3 is using PerlRun) that does the following:
>
> $ENV{'TZ'} = 'US/Eastern';
> POSIX::tzset();
> my @time = localtime();
> my $time = time();
> $ENV{'TZ'} = 'US/Pacific';
> POSIX::tzset();
>
> # I
Sure thing,
If I have the following script: www.somewhere.com/e3/datetz.cgi
(where e3 is using PerlRun) that does the following:
$ENV{‘TZ’} = ‘US/Eastern’;
POSIX::tzset();
my @time = localtime();
my $time = time();
$ENV{‘TZ’} = ‘US/Pacific’;
POSIX::tzset();
# I would expect th
From: Tyler [mailto:[EMAIL PROTECTED] Hello,
I previously requested some help with setting $ENV{TZ} and using
it’s value to modify the output of localtime (i.e. Make it time
zone specific). The suggested solution was to use POSIX::tzset()
because my perl installation was compiled with thr
Can you post a tiny test script that reproduces your
problem?
From: Tyler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 03, 2006 2:06 PMTo:
modperl@perl.apache.org; Garrett, Philip (MAN-Corporate)Subject:
RE: Using ENV{'TZ'} in mod_perl
Hello,
I previously
requ
Hello,
I previously requested some help with
setting $ENV{TZ} and using it’s value to modify the output of localtime
(i.e. Make it time zone specific). The suggested solution was to use
POSIX::tzset() because my perl installation was compiled with thread support.
So this helped, however
On Oct 3, 2006, at 1:30 AM, David Emery wrote:
Just a shot in the dark, but could it be a problem with your log-in
process
rather than a caching issue? Like maybe the unique value you're
basing the
user's identity on isn't quite as unique as you think?
I'm going to agree with this being AT
12 matches
Mail list logo
