Re: Pb with Win32 Installation
On Thu, 2 May 2002, Jean-Marc Paulin wrote: Hi there, I have downloaded the CSV Image file modperl-2.0_20020502042105.tar.gz and tried to compile it for Apache 2.0.35. The build is ok (or looks good anyway) but Apache dies during the nmake test. [ .. ] apache\cgihandlerok apache\compatok apache\compat2...ok apache\conftree..FAILED before any test output arrived As you're using the cvs mod_perl sources, it's probably a good idea to also use the Apache cvs sources, to keep in sync with changes. The above problem with apache\conftree doesn't occur for me with the current cvs apache-2.0.37-dev. best regards, randy kobes Hi I have the same problem : contree test fails and apache segfaults, even with the latest cvs. apache 2.0.37-dev modperl 1.99_02-dev win2k perl 561 see below the report log. pascal barbedor -8-- Start Bug Report 8-- 1. Problem Description: nmake is ok nmake test fails at conftree test : apache.exe segfaults note : i cannot build modperl2 debug on win2k the DEBUG options fails 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX= c:/back MP_GENERATE_XS = 1 MP_INST_APACHE2 = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 *** c:/back/bin/Apache.exe -V Server version: Apache/2.0.37-dev Server built: May 6 2002 09:39:35 Server's Module Magic Number: 20020329:1 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/winnt -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/apache -D SUEXEC_BIN=/apache/bin/suexec -D DEFAULT_ERRORLOG=logs/error.log -D SERVER_CONFIG_FILE=conf/httpd.conf *** C:\Perl\bin\perl.exe -V Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX', optimize='-O1 -MD -DNDEBUG', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='link', ldflags '-nologo -nodefaultlib -release -libpath:C:\Perl\lib\CORE -machine:x86' libpth=C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib C:\Program Files\Microsoft Visual Studio\VC98\lib C:\Perl\lib\CORE libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', ddlflags='-dll -nologo -nodefaultlib -release -libpath:C:\Perl\lib\CORE -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 631 Built under MSWin32 Compiled at Jan 2 2002 17:16:22 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: C:/Perl/lib C:/Perl/site/lib . 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/report on Mon May 6 07:58:08 2002 GMT. -8-- End Bug Report --8-- Note: Complete the rest of the details and post this bug report to dev at perl.apache.org. To subscribe to the list send an empty email to [EMAIL PROTECTED]
mod_perl cookbook review at apacheweek.com
For those who still hesitate whether to purchase this great mod_perl recipes tome, here is Min Min Tsan's review of the mod_perl cookbook: http://www.apacheweek.com/features/book-mod_perlcookbook And lucky Robin Berjon and two other folks just won free copies of this book from apacheweek giveaway :) p.s. April 2002 Netcraft's mod_perl stats: 3.6M hosts 0.4M IPs. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key file has to be set before the PerlModule directive, it is a bug in the documentation. Except it doesn't really, because it works fine for me. =) I compiled mod_perl static, I tend to avoid DSO if possible. -Fran
Re: Pb with Win32 Installation
On Mon, 6 May 2002, pascal barbedor wrote: I have the same problem : contree test fails and apache segfaults, even with the latest cvs. apache 2.0.37-dev modperl 1.99_02-dev win2k perl 561 That's wierd - I have the same set-up, except using WinXP, and this test passes ... What happens if you remove t/conf/httpd.conf (so as to regenerate it) before running the tests - are things any different? best regards, randy
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Mon, 06 May 2002 10:04:28 -0400 Fran Fabrizio [EMAIL PROTECTED] wrote: : Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key : file has to be set before the PerlModule directive, it is a bug in the : documentation. : : Except it doesn't really, because it works fine for me. =) : : I compiled mod_perl static, I tend to avoid DSO if possible. The Eagle book says (page 58): Apache processes the configuration directives on a first-come, first-serve basis, so in certain cases, the order in which directives appear is important. So Apache passes PerlModule and PerlSetVar to mod_perl as it finds it in its configuration file. If mod_perl loaded modules as they come by means of PerlModule that would explain why variables set with PerlSetVar after that directive are not seen by the very module at loading time. As that seems to be the behaviour in my static mod_perl and Jacob Davies said he had to change the documentation (and he knows more mod_perl than I for sure), I don't understand why the order does not matter in your machine. Do we have the same version of the module (v1.18)? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
I for sure), I don't understand why the order does not matter in your machine. Do we have the same version of the module (v1.18)? -- fxn Ah, no, I've got 1.10. Here is the relevant part of my config file # AuthCookieDBI config PerlModule Apache::AuthCookieDBI PerlSetVar RMSPath / PerlSetVar RMSLoginScript /rms/login PerlSetVar RMSDBI_SecretKeyFile /usr/local/apache/RMSsecretkeyfile PerlSetVar etc.. So much for backwards compatibility. ;-) -Fran
mod_perl install from tarball
i am trying to install mod_perl and apache from tarball. after untarring, i created the makepl_args.mod_perl file in my home dir with my options. by the way, i am building this on a rh7.1 machine with mod_perl already installed. i am building this to learn. anyhow, when i run perl Makefile.PL, i get this... [boex@rootabega mod_perl-1.99_01]$ perl Makefile.PL You are running Perl version 5.006 We strongly suggest to upgrade to at least 5.6.1 mod_perl/1.24_01 installation detected...not ok cannot install mod_perl/1.99_01 on top of mod_perl/1.24_01 use MP_INST_APACHE2=1 option or to force installation delete: /usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm first, i am running perl 5.6.0. as the same user, i run perl -v and get.. [boex@rootabega boex]$ perl -v This is perl, v5.6.0 built for i386-linux Copyright 1987-2000, Larry Wall second, is the version i downloaded, 1.99_01 only for apache 2.0? are these versions being split like apache 1.3 and 2.0, with and without threads? if so, should i download a different version? if not, what route should i go to install? my goal is to install from scratch so i can learn more and to install with the same directory structure, /usr/local/apache-mod_perl/ on my production and dev machines. i want to be able to run a mod_perl or non-mod_perl enabled web server. matt Matthew Boex Sendmail Group 312.822.3955
Re: mod_perl install from tarball
Boex,Matthew W. wrote: i am trying to install mod_perl and apache from tarball. after untarring, i created the makepl_args.mod_perl file in my home dir with my options. by the way, i am building this on a rh7.1 machine with mod_perl already installed. i am building this to learn. you are trying to install mod_perl 2.0-tobe, which works only with Apache 2.0, and most likely you want to download mod_perl 1.26 instead. my goal is to install from scratch so i can learn more and to install with the same directory structure, /usr/local/apache-mod_perl/ on my production and dev machines. i want to be able to run a mod_perl or non-mod_perl enabled web server. The detailed steps of how to do that are here: http://perl.apache.org/guide/install.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[DIGEST] mod_perl digest 2002/04/15
-- mod_perl digest April 15, 2002 - May 5, 2002 -- Recent happenings in the mod_perl world... The digest should be resuming its weekly appearence now that my spring semester classes are over... Features o mod_perl status o module announcements o module rfcs o mod_perlers needed o mailing list highlights o book reviews o links mod_perl status o mod_perl - stable: 1.26 (released July 11, 2001) [1] - development: 1.26_01-dev [2] o Apache - stable: 1.3.24 (released March 21, 2002) [3] - development: 1.3.25-dev [4] o mod_perl 2.0 - beta: 1.99_01 (released April 6, 2002) [5] - development: (cvs only) [6] o Apache 2.0 - stable: 2.0.35 (released April 5, 2002) [7] o Perl - stable: 5.6.1 (released April 9, 2001) [8] - development: 5.7.3 [9] module announcements o Apache::AccessCookie 0.32 - cookie-based access control module [10] o Apache::ASP 2.33 - provides Perl-based active server pages [11] o Apache::Clean 0.04 - cleans HTTP headers [12] o Apache::GuessCharset 0.02 - adds HTTP charset by guessing file's encoding [13] o AxKit 1.5.2 - XML transformation system [14] o Cache::Cache 1.0 - various caching mechanisms [15] o Module::Use 0.05_01 - track Perl module use [16] o Uttu 0.02 - web site driver [17] module rfcs o Apache::Onanox - multiple user website app framework [18] o File::Redundent - syncs files across filesystems upon modification [19] mod_perlers needed o Senior mod_perl developers for LRN, Los Angeles [20] mailing list highlights o Sharing variables across Apache children [21] o XML::RPC [22] o SOAP and web services [23] o Cheap and unique - where random and unique are discussed [24,25] book reviews o _The mod_perl Developer's Cookbook_ on perl.com [26] links o The Apache/Perl Integration Project [27] o mod_perl documentation [28] o Apache modules on CPAN [29] o mod_perl homepage [30] o mod_perl news and advocacy [31] o mod_perl list archives - modperl@ [32] [33] - dev@ [34] [35] - docs-dev@ [36] - advocacy@ [37] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_01.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/devel.tar.gz [10] http://mathforum.org/epigone/modperl/gringhunchon [11] http://mathforum.org/epigone/modperl/strancicon [12] http://mathforum.org/epigone/modperl/plerdghuderd [13] http://mathforum.org/epigone/modperl/snulzhermskai [14] http://mathforum.org/epigone/modperl/blootilblil [15] http://mathforum.org/epigone/modperl/krehleutrung [16] http://mathforum.org/epigone/modperl/chalcolmen [17] http://mathforum.org/epigone/modperl/slimskehthald [18] http://mathforum.org/epigone/modperl/khanddwoyquom [19] http://mathforum.org/epigone/modperl/slaufruldri [20] http://mathforum.org/epigone/modperl/drolkrenstreld [21] http://mathforum.org/epigone/modperl/hospaihim [22] http://mathforum.org/epigone/modperl/zhomskeherl [23] http://mathforum.org/epigone/modperl/peskoiquar [24] http://mathforum.org/epigone/modperl/spoimoxkrum [25] http://mathforum.org/epigone/modperl/jixkreistram [26] http://www.perl.com/pub/a/2002/04/25/review.html [27] http://perl.apache.org/ [28] http://perl.apache.org/#docs [29] http://www.cpan.org/modules/by-module/Apache/ [30] http://www.modperl.com/ [31] http://www.take23.org/ [32] http://mathforum.org/epigone/modperl/ [33] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2 [34] http://marc.theaimsgroup.com/?l=apache-modperl-devr=1w=2 [35] http://www.mail-archive.com/dev%40perl.apache.org/ [36] http://perl.apache.org/mail/docs-dev/ [37] http://www.mail-archive.com/advocacy@perl.apache.org/
Re: Pb with Win32 Installation
- Original Message - From: Randy Kobes [EMAIL PROTECTED] To: pascal barbedor [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 06, 2002 4:03 PM Subject: Re: Pb with Win32 Installation On Mon, 6 May 2002, pascal barbedor wrote: I have the same problem : contree test fails and apache segfaults, even with the latest cvs. apache 2.0.37-dev modperl 1.99_02-dev win2k perl 561 That's wierd - I have the same set-up, except using WinXP, and this test passes ... What happens if you remove t/conf/httpd.conf (so as to regenerate it) before running the tests - are things any different? best regards, randy alas no. things are the same. error message is memory cant be read from perl56.dll here is a complete report of first test in each directory that fails and produces segfault (with perl t/test dirtest) : dirtest=api: api/access :ok api/aplog : apache segfault dirtest=apr apr/base34 :ok apr/constants : ok apr/date apache segfault dirtest=apache apache/cgihandler : ok apache/compat: ok apache/compat2:ok apache/conftree : apache segfault dirtest=directive directive/env failed 1-3, 4 ok directive/prelmodule : ok directive/perlrequire : ok directive/setupenv : apache segfault dirtest=filter all tests succesfull dirtest=hooks hooks/access : ok hooks/authen : ok 2/4 and 3 segfault dirtest=modperl modperl/dirconfig : failed tests 6-12 failed 7/12 tests (this reminds me my previous post about dir_config not working) and apache segfaults dirtest=protocol protocol/echo ok protocol/filter ok protocol/eliza skipped dirtest=module modules/cgi ok 2/5 and apache segfaults... it would be good if there was a possibility to build modperl2 debug on win32... personnaly I would love to be able to report bugs with complete source backtrace and all that stuff required to make it funny to track bugs ! best regards pascal
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Peter: Squid complains about http://mod_perl.home.att.net which it says contains an invalid character (_), so I can't access it. Rafael Caceres At 10:58 PM 5/3/2002 -0700, you wrote: Try my Apache::AccessCookie too. It provides the same ticketing interface for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and (of course) DBI, plus a number of useful features. One can simply implement her own mechanism too. It can be downloaded at http://mod_perl.home.att.net. BTW, I tried to register the module in CPAN, but was kind of lost in the middle. Peter Bi - Original Message - From: Jim Helm [EMAIL PROTECTED] To: 'Fran Fabrizio' [EMAIL PROTECTED]; 'F.Xavier Noria' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 03, 2002 10:08 PM Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood) p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I wanted (timeout, not just expiry), which CookieDBI didn't have), and it worked as documented with zero hassle... Jim -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:38 AM To: F.Xavier Noria Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
Re: Using a 404 ErrorDocument to serve content
Ken == Ken Williams [EMAIL PROTECTED] writes: Ken I was thinking of writing yet-another-photo-album-server, and I had Ken the idea that I'd write a handler to serve resized versions of JPEGs Ken (very original, I know ;-). The idea is that I'd put a bunch of JPEGs Ken on the server at locations like foo/123.jpg , and then if a request Ken came for foo/123-medium.jpg , I'd catch that with a 404 ErrorDocument Ken and generate the resized image using Imager. If I wanted to, I could Ken also create the resized image on disk, so it wouldn't need to be Ken generated next time. As usual, Been there, Did That For A Column. 1) Visit any page on the newly redesigned www.stonehenge.com. 2) Type 404 handler into the bottom search this site with google box. 3) Check out the hits... should be the first or second one. After 160 columns, I'm starting to really wonder what there is LEFT to cover. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Pb with Win32 Installation
On Mon, 6 May 2002, pascal barbedor wrote: error message is memory cant be read from perl56.dll here is a complete report of first test in each directory that fails and produces segfault (with perl t/test dirtest) : dirtest=api: api/access :ok api/aplog : apache segfault dirtest=apr apr/base34 :ok apr/constants : ok apr/date apache segfault [ ...] For those that segfault, does running them individually: perl -Mblib t/TEST t/apache/conftree.t etc. also segfault? best regards, randy
Re: Using a 404 ErrorDocument to serve content
Ken Williams wrote: The idea is that I'd put a bunch of JPEGs on the server at locations like foo/123.jpg , and then if a request came for foo/123-medium.jpg , I'd catch that with a 404 ErrorDocument and generate the resized image using Imager. If I wanted to, I could also create the resized image on disk, so it wouldn't need to be generated next time. Incidentally, that's how Vignette StoryServer works. You could also do this kind of thing with a transhandler (or mod_rewrite) that checks for the existence of a static file and rewrites the URL if it can't find one. That might be more correct, but trapping 404 is the best possible performance, since there is no additional code in the response chain if the static file is there. - Perrin
Re: Using a 404 ErrorDocument to serve content
On Mon, 6 May 2002, Perrin Harkins wrote: Ken Williams wrote: The idea is that I'd put a bunch of JPEGs on the server at locations like foo/123.jpg , and then if a request came for foo/123-medium.jpg , I'd catch that with a 404 ErrorDocument and generate the resized image using Imager. If I wanted to, I could also create the resized image on disk, so it wouldn't need to be generated next time. Incidentally, that's how Vignette StoryServer works. You could also do this kind of thing with a transhandler (or mod_rewrite) that checks for the existence of a static file and rewrites the URL if it can't find one. That might be more correct, but trapping 404 is the best possible performance, since there is no additional code in the response chain if the static file is there. fyi, i believe that Vignette is attempting to patent that. - Perrin m@ =) matthew d. p. k. strelchun-lanier [EMAIL PROTECTED] 415-515-5421 http://www.lanier.org http://sf.pm.org
Re: Cheap and unique
Ken Williams wrote: If you have the additional requirement that the unique values shouldn't be easily *guessable*, that becomes a very hard problem, precisely because random and unique are such poor friends. Usually people just cheat by generating a large random ID such that the probability of it being already-used is low, and then they check all the previous IDs to make sure. The requirement to prevent guessing is usually aimed at security and preventing session hijacking and similar attacks (and believe me, this kind of attack is very common). Another way to do this is to use a MAC like MD5 or SHA1, as described in the Eagle book and O'Reilly's CGI book. This makes it very difficult for an attacker to generate a valid ID, even if the sequence of IDs is predictable. - Perrin
Re: Cheap and unique
I've been following this conversation and I'd like to clarify whether my idea (since I and others want to do this as well) would be use an incrementing counter for uniqueness. Then also store a bit of secret randomness, concatenate both values together and create a digest hash. That hash would be sent along with the sequence as well. This would allow uniqueness and prevent guessing since the digest would have to match as well. Depending on my paranoia I could either get fresh random bits each time (and have a good hardware source for this then) or keep it around for a bit and throw it away after a period. Does that sound right? Josh Perrin Harkins [EMAIL PROTECTED] 05/06/2002 01:15 PM To: Ken Williams [EMAIL PROTECTED] cc: OCNS Consulting [EMAIL PROTECTED], [EMAIL PROTECTED], David Jacobs [EMAIL PROTECTED] Subject:Re: Cheap and unique Ken Williams wrote: If you have the additional requirement that the unique values shouldn't be easily *guessable*, that becomes a very hard problem, precisely because random and unique are such poor friends. Usually people just cheat by generating a large random ID such that the probability of it being already-used is low, and then they check all the previous IDs to make sure. The requirement to prevent guessing is usually aimed at security and preventing session hijacking and similar attacks (and believe me, this kind of attack is very common). Another way to do this is to use a MAC like MD5 or SHA1, as described in the Eagle book and O'Reilly's CGI book. This makes it very difficult for an attacker to generate a valid ID, even if the sequence of IDs is predictable. - Perrin
Re: Cheap and unique
[EMAIL PROTECTED] wrote: I've been following this conversation and I'd like to clarify whether my idea (since I and others want to do this as well) would be use an incrementing counter for uniqueness. Then also store a bit of secret randomness, concatenate both values together and create a digest hash. That hash would be sent along with the sequence as well. This would allow uniqueness and prevent guessing since the digest would have to match as well. Depending on my paranoia I could either get fresh random bits each time (and have a good hardware source for this then) or keep it around for a bit and throw it away after a period. Does that sound right? Yes, except for the random part. There is no randomness involved here. You should use a secret key stored on your server. There's an example of this technique here: http://www.oreilly.com/catalog/cgi2/chapter/ch08.html - Perrin
Re: Cheap and unique
Does the first email mean to use the incrementing numbers as seeds and then generate cool random numbers from the partly ordered seeds, which will make them more difficult to guess ? Peter Bi - Original Message - From: James G Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 06, 2002 11:45 AM Subject: Re: Cheap and unique [EMAIL PROTECTED] wrote: I've been following this conversation and I'd like to clarify whether my idea (since I and others want to do this as well) would be use an incrementing counter for uniqueness. Then also store a bit of secret randomness, concatenate both values together and create a digest hash. That hash would be sent along with the sequence as well. This would allow uniqueness and prevent guessing since the digest would have to match as well. Depending on my paranoia I could either get fresh random bits each time (and have a good hardware source for this then) or keep it around for a bit and throw it away after a period. I think I understand you correctly, but I'm not sure. You mention the sequence being incremented for uniqueness and the digest. I think you propose to send the sequence along with the digest (the digest containing that bit of randomness along with the sequence), but you also mention keeping the random bits around for only a short time, which would indicate they aren't being used to verify the sequence, but produce the sequence via the hash. A digest is not unique, especially with the random bit of data thrown in. For example, MD5 has 128 bits, but can hash any length string. There are more than 2^128 strings that MD5 can take to 128 bits. Therefore, MD5 does not produce a unique value, though it is a reproducable value (the same input string will always produce the same output string). You can replace MD5 with MHX (my hash X) and the number of bits with some other length and the results are still the same -- in other words, no hash will give unique results. The secret string concatenated with the unique number and then hashed can be used to guarantee that the number has not been tampered with, but the secret string would need to be constant to be able to catch tampering. Otherwise, how can you tell if the hash is correct? -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Pb with Win32 Installation
For those that segfault, does running them individually: perl -Mblib t/TEST t/apache/conftree.t etc. also segfault? best regards, randy also running tests with perl t\test -start-httpd perl -Mblib t\test t/apache/conftree.t perl -Mblib t\test t/apache/compat2.t segfaults at compat2 perl t\test -start-httpd perl -Mblib t\test t/apache/conftree.t perl -Mblib t\test t/apache/compat.t segfaults at compat perl t\test -start-httpd perl -Mblib t\test t/apache/write.t perl -Mblib t\test t/apache/compat.t perl -Mblib t\test t/apache/compat2.t perl -Mblib t\test t/apache/conftree.t segfault at conftree perl t\test -start-httpd perl -Mblib t\test t/apache/compat.t perl -Mblib t\test t/apache/conftree.t perl -Mblib t\test t/apache/compat2.t segfault at compat2 perl t\test -start-httpd perl -Mblib t\test t/apache/compat2.t perl -Mblib t\test t/apache/conftree.t segfault at conftree if this is of any help... best regards pascal
err_header_out() not found in mod_perl 1.99
greetings, I'm using Apache2/mod_perl 1.99 on WinNT. Here's the error: [error] [client 127.0.0.1] Can't locate object method err_header_out via package Apache::RequestRec at C:\Apach... thanks in advance -pete
How do I determine end of request? (mod_perl 2.0)
Hello,
I'm fairly new to using mod_perl. I've been able to find lots of
resources dealing with mod_perl 1.x, but the documentation for 2.0 is
rather sparse.
I'm pretty sure what I need to do can only be handled by Apache 2.0 thus
I'm forced to use mod_perl 2.0... (well 1.99)
I'm trying to proxy ServerB through ServerA... ok that's simple enough with
mod_proxy. However, links, embedded images, etc in the proxied document end
up broken if they are non-relative links (ie. start with a slash).
Example: on ServerB is a document say: /sales/products.html
in products.html it links to /images/logo.gif
accessing /sales/products.html using ServerB everything is fine. But, if I
want to proxy ServerB via ServerA... say
ProxyPass /EXTERNAL http://ServerB
If I goto http://ServerA/EXTERNAL/sales/products.html the embedded image
/images/logo.gif is requested from ServerA.
So to handle this I wanted to write a filer for ServerA to parse all pages
served via Location /EXTERNAL and fix the links.
I wrote a handler (see below) using HTML::Parser to extract the tags that
would contain links and process them.
It works great for the most part... however, it seems like instead of
ServerA getting the entire output from ServerB, it gets it in
chunks which get processed individually. This causes my handler to fail
when a tag is split between 2 chunks.
What I think needs to be done is to build up the document in a variable
$html .= $buffer; and then call the $p-$parse($html) once the entire
document has been received by ServerA (or maybe as simple of only calling
$p-eof; at that point).
Or is there a better way to do this? One problem I've found so far is I
need to fix style sheets, but I can probably write a special handler for
them once I get this problem fixed.
Thanks!
##
package RewriteLinks;
use strict;
use Apache::Filter;
use Apache::RequestUtil;
use APR::Table;
use HTML::Parser;
my %ReplaceAttrs = ( a = 'href',
img = 'src',
link = 'href',
td= 'background',
form = 'action'
);
my $filter;
sub handler {
$filter = shift;
### Create parser object ###
my $p = HTML::Parser-new( api_version = 3 );
$p-handler(start = \do_tags, 'tagname, attr, text' );
$p-handler(default = \default, 'text');
while ($filter-read(my $buffer, 32678)) {
$p-parse($buffer);
}
$p-eof; # signal end of document
1;
}
sub do_tags {
my ($tagname, $attr, $text) = _;
## only need to modify tags with url-like attributes starting with a slash
if ($$attr{$ReplaceAttrs{$tagname}} =~ m|^/|) {
my $TAG = . uc($tagname);
foreach my $key (keys %$attr) {
$TAG .= ' ' . uc($key) . '=';
if ($key eq $ReplaceAttrs{$tagname}) {
$TAG .= '/EXTERNAL';
}
$TAG .= $$attr{$key} . '';
}
$TAG .= \n;
$filter-print($TAG);
} else {
$filter-print($text);
}
}
sub default {
my ($text) = _;
$filter-print($text);
}
1;
Re: Using a 404 ErrorDocument to serve content
At 10:59 06.05.2002 -0700, you wrote: On Mon, 6 May 2002, Perrin Harkins wrote: Incidentally, that's how Vignette StoryServer works. You could also do this kind of thing with a transhandler (or mod_rewrite) that checks for the existence of a static file and rewrites the URL if it can't find one. That might be more correct, but trapping 404 is the best possible performance, since there is no additional code in the response chain if the static file is there. fyi, i believe that Vignette is attempting to patent that. Phew, and I just thought that I did not like the design. It might have good performance now, but the idea sounds valid that in an error handler performance does not matter. So if someone changes apache in that direction ... How can they patent it if there already is an article about this? Sincerely, Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
Re: err_header_out() not found in mod_perl 1.99
Nevermind, I found that err_headers_out() provides the needed functionality. Peter Rothermel wrote: greetings, I'm using Apache2/mod_perl 1.99 on WinNT. Here's the error: [error] [client 127.0.0.1] Can't locate object method err_header_out via package Apache::RequestRec at C:\Apach... thanks in advance -pete
Fw: How do I determine end of request? (mod_perl 2.0)
- Original Message -
From: pascal barbedor [EMAIL PROTECTED]
To: Douglas Younger [EMAIL PROTECTED]
Sent: Monday, May 06, 2002 11:31 PM
Subject: Re: How do I determine end of request? (mod_perl 2.0)
hi
you could maybe set the ProxyIOBufferSize
or Proxyreceivebuffersize
in the front end server so that response from modperl server would not be
chunked but one shot
also static ressources like gif in server B documents could be retrieved
from server A only with an alias not proxied to server B
pascal
- Original Message -
From: Douglas Younger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 06, 2002 10:26 PM
Subject: How do I determine end of request? (mod_perl 2.0)
Hello,
I'm fairly new to using mod_perl. I've been able to find lots of
resources dealing with mod_perl 1.x, but the documentation for 2.0 is
rather sparse.
I'm pretty sure what I need to do can only be handled by Apache 2.0
thus
I'm forced to use mod_perl 2.0... (well 1.99)
I'm trying to proxy ServerB through ServerA... ok that's simple enough
with
mod_proxy. However, links, embedded images, etc in the proxied document
end
up broken if they are non-relative links (ie. start with a slash).
Example: on ServerB is a document say: /sales/products.html
in products.html it links to /images/logo.gif
accessing /sales/products.html using ServerB everything is fine. But, if
I
want to proxy ServerB via ServerA... say
ProxyPass /EXTERNAL http://ServerB
If I goto http://ServerA/EXTERNAL/sales/products.html the embedded image
/images/logo.gif is requested from ServerA.
So to handle this I wanted to write a filer for ServerA to parse all
pages
served via Location /EXTERNAL and fix the links.
I wrote a handler (see below) using HTML::Parser to extract the tags
that
would contain links and process them.
It works great for the most part... however, it seems like instead of
ServerA getting the entire output from ServerB, it gets it in
chunks which get processed individually. This causes my handler to
fail
when a tag is split between 2 chunks.
What I think needs to be done is to build up the document in a variable
$html .= $buffer; and then call the $p-$parse($html) once the entire
document has been received by ServerA (or maybe as simple of only
calling
$p-eof; at that point).
Or is there a better way to do this? One problem I've found so far is I
need to fix style sheets, but I can probably write a special handler for
them once I get this problem fixed.
Thanks!
##
package RewriteLinks;
use strict;
use Apache::Filter;
use Apache::RequestUtil;
use APR::Table;
use HTML::Parser;
my %ReplaceAttrs = ( a = 'href',
img = 'src',
link = 'href',
td= 'background',
form = 'action'
);
my $filter;
sub handler {
$filter = shift;
### Create parser object ###
my $p = HTML::Parser-new( api_version = 3 );
$p-handler(start = \do_tags, 'tagname, attr, text' );
$p-handler(default = \default, 'text');
while ($filter-read(my $buffer, 32678)) {
$p-parse($buffer);
}
$p-eof; # signal end of document
1;
}
sub do_tags {
my ($tagname, $attr, $text) = @_;
## only need to modify tags with url-like attributes starting with a
slash
if ($$attr{$ReplaceAttrs{$tagname}} =~ m|^/|) {
my $TAG = . uc($tagname);
foreach my $key (keys %$attr) {
$TAG .= ' ' . uc($key) . '=';
if ($key eq $ReplaceAttrs{$tagname}) {
$TAG .= '/EXTERNAL';
}
$TAG .= $$attr{$key} . '';
}
$TAG .= \n;
$filter-print($TAG);
} else {
$filter-print($text);
}
}
sub default {
my ($text) = @_;
$filter-print($text);
}
1;
[RFC] New Subject Tag for mod_perl 2.x postings
Hi! As there are more and more mod_perl 2.x related questions on the mailing list, it would be a good idea to introduce a new subject tag (as in http://perl.apache.org/email-etiquette.html#Tags ): Something like: [mod_perl 2.x] [mp2] [2x] [2.x] ?? What do you think? It would definitly keep my mailbox tidier... Stas, If we decide on something I could patch the new documentation to include this new tag, but I don't know abot the old (i.e. current) one -- D_OMM + http://domm.zsi.at -+ O_xyderkes | neu: Arbeitsplatz | M_echanen | http://domm.zsi.at/d/d162.html | M_asteuei ++
Re: Problems with Apache-AuthCookie mod_perl 1.99
Michael, I've got most of the changes done. No major changes were required but I'm still stuck on mod_perl 2's new method handlers. To get past this hurdle I've moved away from method handlers and put everything into a single package. As soon as somebody gives me a hand with method handlers ala 2.0 I'll forward the code to you. -pete Michael J Schout wrote: On Thu, 2 May 2002, Per Einar Ellefsen wrote: At 21:25 02.05.2002, Peter Rothermel wrote: greetings, Has anybody had any luck getting Apache-AuthCookie going on an Apache 2.0 / mod_perl 1.99 setup? The first thing that I hit was $r-connection-user is deprecated. I've changed these to $r-user. The next hurdle is that the status code REDIRECT does not seen to be Apache::Constants. mod_perl 2 doesn't have Apache::Constants. You should use: use Apache::Const -compile = qw(... REDIRECT ..); Good luck on porting it to mod_perl 2! once you get it to work, it would be great if you could contribute it to the community! If you do get it working, feel free to forward patches to me as I am the AuthCookie maintainer. An apache 2.0 port is on my TODO list. Mike
Re: localizing $dbh attributes with Apache::DBI to minimize the number of connections made
On Mon, 06 May 2002 13:30:07 +0800, Stas Bekman wrote:
[snip]
my $dbh = DBI-connect
(DBI:mysql:test:localhost, '', '',
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # don't commit executes immediately
Surely the don't here is wrong?
}
) or die Cannot connect to database: $DBI::errstr;
[snip]
Therefore
it's the best to restore the modified attributes to their original
Therefore it's best is idiomatic English.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 07/05/2002
http://savage.net.au/index.html
RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Strictly speaking _ is (was?) an illegal character for DNS names. I used to go round-n-round with a fellow sysadmin about that fact, and that we shouldn't use _ in hostnames. Jim -Original Message- From: Rafael Caceres [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 10:23 AM To: Peter Bi Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Peter: Squid complains about http://mod_perl.home.att.net which it says contains an invalid character (_), so I can't access it. Rafael Caceres At 10:58 PM 5/3/2002 -0700, you wrote: Try my Apache::AccessCookie too. It provides the same ticketing interface for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and (of course) DBI, plus a number of useful features. One can simply implement her own mechanism too. It can be downloaded at http://mod_perl.home.att.net. BTW, I tried to register the module in CPAN, but was kind of lost in the middle. Peter Bi - Original Message - From: Jim Helm [EMAIL PROTECTED] To: 'Fran Fabrizio' [EMAIL PROTECTED]; 'F.Xavier Noria' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 03, 2002 10:08 PM Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood) p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I wanted (timeout, not just expiry), which CookieDBI didn't have), and it worked as documented with zero hassle... Jim -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:38 AM To: F.Xavier Noria Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
Re: [RFC] New Subject Tag for mod_perl 2.x postings
Thomas Klausner wrote: Hi! As there are more and more mod_perl 2.x related questions on the mailing list, it would be a good idea to introduce a new subject tag (as in http://perl.apache.org/email-etiquette.html#Tags ): Something like: [mod_perl 2.x] [mp2] [2x] [2.x] ?? What do you think? That's a good idea. Any tag that will make it clear that the question is regarding 2.x is fine. Eventually when 2.0 is released and after a while most people will run 2.x, only those ancient [:)] 1x will need to be tagged in the subject line. It would definitly keep my mailbox tidier... Stas, If we decide on something I could patch the new documentation to include this new tag, but I don't know abot the old (i.e. current) one go ahead, add any tags that you prefer. [2.x] or sounds the shortest and the clearest. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
