weird cookie behavior
I'm experiencing strange behavior with cookies when my scripts are
accessed in mod_perl (using Apache::Registry). Everything works fine so
long as my browser is configured to not go through a proxy (ie, in
Netscape 4.77, directly connected to the Internet option is selected).
When I configure it to use a custom proxy (eg, Junkbuster running on my
LAN gateway), my cookies no longer work, but I can still browse the web
fine.
I should point out that everything works ok when the scripts are
accessed as CGI's rather than mod_perl. Hence I'm fairly certain the
problem is not with the Junkbuster proxy, but has something to do with
mod_perl.
These are the software versions:
Debian/Linux 3.0
Apache 1.3.26 + mod_ssl 2.8.9 (running in proxy accelerator mode)
Apache 1.3.26 + mod_perl 1.26
Perl 5.6.1
I'm using CGI.pm to create the cookie headers. Typical code looks like this:
# Setting a cookie
# (the test.pl script will retrieve the cookie and check auth_info)
$cookie = MI_BakeCookie($q, $form-{'email'}, $form-{'passwd'});
print $q-redirect(-cookie=$cookie, -url=/perl/test.pl?op=menu);
# Retrieving a cookie
$cookie = $q-cookie('auth_info');
form{'email', 'crypt'} = split (':', $cookie);
# The function that creates the cookies...
# Creates a temporary auth_info cookie which contains the user's
# email address and encrypted password (MD5 hash).
sub MI_BakeCookie {
my ($q, $email, $password) = _;
my $crypt = md5_hex($password);
my $auth_info = join (':', $email, $crypt);
my $cookie = $q-cookie(-name='auth_info',
-value=$auth_info,
# -expires='+10d',
-path='/',
-secure=0 # haven't changed this yet...
);
return ($cookie);
}
It's all pretty straightforward stuff... which is why I'm confused and
hope that someone might have an idea as to what's going on here. I'm
open to any suggestions, but alas I don't have a lot of time to spare so
can't really afford to make my own custom handler and switch to
Apache::Cookie or whatnot. But if that's the only solution, then I
gotta do what I gotta do.
Anyway, please let me know if you have any ideas. :)
Re: [Win32] ActivePerl-5.8 beta released
I asked Jan Dubois at ActiveState about this, just to verify - the relevant excerpt of his reply follows ... Luckily I'm on both lists (or at least I got a copy of Jan Dubois reply as well). Thank you for this. Perhaps related to this, was this build compiled with VC++ 6? Yes. For various reasons, we decided to continue to build ActivePerl with VC++ 6 SP3. I'm pretty sure that later service packs should be compatible too as the core Perl code doesn't use C++ anymore (the PERL_OBJECT stuff contained pointers to member functions, which changed size in VC++ 6 SP4 and later). I've also (just for testing) compiled extension DLLs for ActivePerl 633 and 802 using the free, non-optimizing VC++ 7 compiler from the .NET Framework SDK. It worked just fine, but it will use MSVCR70 instead of MSVCRT for the runtime library, resulting in 2 different C runtime libraries being loaded. This is potentially a problem with structured exception handling for C++, but should work fine for normal C extension code too. From this and other comments, I gather having two runtime libraries is a Not-So-Good-Thing (tm) I will probably breakdown and add VC++ 6 to my collection of toys. I'm far from an adaquate C programmer. Thank you for all your work supporting us red-headed step children in the Windows world. -Chris
Re: Trouble building Apache 1.3.27 with mod_perl 1.27 on Solaris 8x86
Hi there, On Fri, 8 Nov 2002, [iso-8859-1] Svavar Örn Eysteinsson wrote: I'm having a big trouble on my Solaris 8 x86. I'm trying to compile Apache v1.3.27 with mod_perl 1.2.27. As for now i'm running Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_perl/1.25. with Perl 5.6.1 and GCC 3.0.3 Did you compile Perl 5.6.1, Apache 1.3.19 and mod_perl 1.25 with gcc 3.0.3 ? I ask because gcc 3.0.3 is almost a year younger than Apache 1.3.19. I'd think it worth upgrading to 3.2 unless there are reasons not to, but I've no idea if it's going to fix your problem. OTOH if you didn't use the same compiler for *all* the compilations... Has anyone been using 3.2 with mod_perl-1.27? I'm just about to give it a whirl... 73, Ged.
make test fails
I am trying to upgrade to Apache 1.3.27 with mod_perl 1.27. I am currently running Apache 1.3.20 and mod_perl 1.26 on an HP-UX machine with hpux 10.20 with perl v5.6.1 built for PA-RISC1.1 . I ran configure on Apache to generate a config file with the additional modules I wanted, then did configure for mod_perl with the following perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Then make make test make install The make worked with no errors. make test resulted in the following error output cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.27/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...Syntax error on line 3 of /usr/src/mod_perl-1.27/t/conf /httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration done /usr/local/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 22 Perl directory has /lib/5.6.1/pod. What is creating the error? Thanks Kelton Joyner
Re: make test fails
Kelton Joyner wrote: I am trying to upgrade to Apache 1.3.27 with mod_perl 1.27. I am currently running Apache 1.3.20 and mod_perl 1.26 on an HP-UX machine with hpux 10.20 with perl v5.6.1 built for PA-RISC1.1 . I ran configure on Apache to generate a config file with the additional modules I wanted, then did configure for mod_perl with the following perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Then make make test make install The make worked with no errors. make test resulted in the following error output [...] Syntax error on line 3 of /usr/src/mod_perl-1.27/t/conf /httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration done Looks like you have messed up the installation steps when configuring apache separately. Please refer to: http://perl.apache.org/docs/1.0/guide/install.html#The_Flexible_Way __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make error compiling mod_perl on RH7.1
Witchy wrote: Hi all, Trying to compile mod_perl 2.0 for my RH7.1/Apache 2.0.39 server and it falls over with this error: apr_perlio.c: In function `apr_perlio_apr_file_to_glob': apr_perlio.c:573: `IoTYPE_WRONLY' undeclared (first use in this function) apr_perlio.c:573: (Each undeclared identifier is reported only once apr_perlio.c:573: for each function it appears in.) apr_perlio.c:577: `IoTYPE_RDONLY' undeclared (first use in this function) make[3]: *** [apr_perlio.o] Error 1 make[3]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR/PerlIO' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 When I ran 'perl Makefile.PL' etc with the correct location for my apache setup the only thing it complained about was the fact I was using Perl 5.6.0 and it recommended 5.6.1 or above. Before I trawl the dependencies tree trying to install a later version has anyone seen that problem before and do I really need to upgrade my perl installation? As somebody else has pointed out you won't have a problem if you run Perl 5.6.1 or higher. Let me check with other developers if 2.0 will eventually require 5.6.1 which is much better thatn 5.6.0. Or whether we should backport things to 5.6.0 as well. The reason is that macros IoTYPE_WRONLY and IoTYPE_RDONLY were introduced in 5.6.1. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Errors after converting /cgi-bin to PerlRun
Frank Naude (FJ) wrote: Hi, I'm trying to convert my /cgi-bin directory to PerlRun as it only contain Perl scripts. However, after doing so, I get numerous errors like this: [Wed Nov 6 11:34:21 2002] [error] Can't locate object method uri via package Apache::PerlRun at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 212. I think it happens when processing a require FILE; contruct. [...] My software versions: Embedded Perl version v5.6.0 for Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 [...] Would it be much of a trouble to upgrade to the latest mod_perl version 1.27? Most likely this problem has been fixed long time ago. [...] __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: newbie:How to get form input in mod_perl 2 since Apache::requestis not implemented yet ?
BuffaloRC Club wrote: Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. If you want to play with 2.0 it's cool, but you may find that it's not yet ready for production, as not all APIs are available yet. On the other hand 1.27 is a *very* robust version. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q-param() etc? I can get form data thru $r-read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Apache::compat is the only way to go for now (if you don't use CGI.pm). See http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_content_ Apache::Request for Apache 2.0 is in works. The C version is pretty much completed, but it's not clear how it's going to be distributed. Once this clears out the perl glue code will be written. Join the [EMAIL PROTECTED] if you want to help and be the first one to know of new developments. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
