Re: PERL/java interface available?
I believe there's a Java.pm module on CPAN that will allow a perl program to instantiate java objects and call methods on them. That may or may not be enough intercommunication for what you need. Wes Sheldahl Charlie Smith [EMAIL PROTECTED] on 06/09/2003 09:34:04 AM To:[EMAIL PROTECTED] cc: Subject:PERL/java interface available? Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
RE: how to secure perl modules?
Regarding the use of source filters, they only seemed to cause me trouble under mod_perl. A while ago I tried using Switch.pm, another source filter from Damian that provides a switch... case sort of syntax, together with HTML::Mason and mod_perl. It led to some really strange errors that didn't really make sense, but the errors went away when I stopped using Switch. Wes Perrin Harkins [EMAIL PROTECTED] on 05/29/2003 05:56:05 PM To:[EMAIL PROTECTED] cc:John Saylor [EMAIL PROTECTED], modperl [EMAIL PROTECTED] Subject:RE: how to secure perl modules? On Thu, 2003-05-29 at 17:41, Kirk Rogers wrote: why the scarcasm? You asked a very loaded question that is guaranteed to get you a lot angry responses on most Perl mailing lists. Hiding your source code is a FAQ ( http://perldoc.com/perl5.8.0/pod/perlfaq3.html#How-can-I-hide-the-source-for-my-Perl-program- ) so the real question is more whether or not the method you've chosen to hide it works with mod_perl. I believe source filters do work, although I've never tried them myself. If you search in the mail archives you'll find many long and flaming threads on the subject. Personally, I would appreciate it if everyone would let this thread die quietly unless they have something specific to add about the use of source filters (or alternate methods) with mod_perl. If you want to argue the ethics of hiding source code, please do it off the list. - Perrin
Compiling Apache::Scoreboard
Hi, I'm getting a bizarre compile error while trying to build Apache::Scoreboard 0.10 on a Mandrake Linux 9.0 system. Here's a snippet of make output, from the first gcc command that failed to just the first few errors it generates: gcc -c -I../ -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/include -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/regex -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/os/unix -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -DVERSION=\0.04\ -DXS_VERSION=\0.04\ -fpic -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -DPERL_THREADS DummyScoreboard.c In file included from DummyScoreboard.xs:14: /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:261: parse error before '*' token /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:261: warning: data definition has no type or storage class /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:264: parse error before '*' token /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:264: warning: data definition has no type or storage class And here's a snippet from mod_perl.h with line numbers: 256 257 typedef request_rec * Apache; 258 typedef request_rec * Apache__SubRequest; 259 typedef conn_rec* Apache__Connection; 260 typedef server_rec * Apache__Server; 261 typedef cmd_parms * Apache__CmdParms; 262 typedef TiedTable * Apache__Table; 263 typedef table * Apache__table; 264 typedef module * Apache__Module; 265 typedef handler_rec * Apache__Handler; 266 typedef command_rec * Apache__Command; 267 As you can see, the first two errors happen in the middle of pretty normal looking typedef statements. This was built using perl 5.8.0 (Mandrake's rpm), gcc 3.2 (Mandrake rpm again), and mod_perl 1.27 (compiled from source). I've talked to one other person who found the same errors on Red Hat 8.0, also using Red Hat's perl 5.8.0 and gcc 3.2 rpm's and a custom built mod_perl. Googling turned up someone from last fall with the same setup and problem, but no solution. Anyone else seen this? Other troubleshooting tips? Thanks in advance, Wes Sheldahl
Re: Upgrading to perl 5.8.0 (newbie question)
No, but you will need to recompile it plus lots of other modules, basically any module that includes XS code. Consider using CPAN's autobundle feature. :-) Wes Sheldahl Gazi, Nasser (London) [EMAIL PROTECTED] on 02/24/2003 06:24:32 AM To:[EMAIL PROTECTED] cc: Subject:Upgrading to perl 5.8.0 (newbie question) Hi, I have a server which has the following pre-installed on it: Apache/1.3.27 mod_perl/1.27 Perl/5.6.1 If I upgrade to Perl/5.8.0 will I have to upgrade mod_perl to a newer version as well? Thanks, NG
Re: Has Apache::Cookie been ported to mod_perl-2 yet?
No it hasn't. Need to use CGI::Cookie for the time being. Apache::Cookie and Apache::Request I believe are both either provided by or dependent on libapreq, which is still a work in progress for apache2/mod_perl2. That's the biggest reason I'm still using Apache 1.3.x now. Wes Sheldahl Charles McElhose Jr. [EMAIL PROTECTED] on 02/10/2003 10:43:57 PM To:[EMAIL PROTECTED] cc: Subject:Has Apache::Cookie been ported to mod_perl-2 yet? Has Apache::Cookie been ported to mod_perl-2 yet? I tried to install the libapreq-1.1 module with mod_perl-2/apache 2 and am getting a can't locate Apache/MyConfig.pm ... error. Charles M. [EMAIL PROTECTED]
Re: coredump with 3 PerlSetVars
Apache 1.3.6 is ancient, has numerous known bugs and security exploits. Same for mod_perl 1.21. Update to apache 1.3.27 and I think mod_perl 1.27, see if it still happens. Wes Hann, Brian [EMAIL PROTECTED] on 02/03/2003 11:43:23 AM To:[EMAIL PROTECTED] cc: Subject:coredump with 3 PerlSetVars Can anyone tell me why Apache would dump core when more than 2 PerlSetVars are used in a Location directive? This is Stronghold 2.4.2, Apache 1.3.6 and mod_perl 1.21 Brian Hann (See attached file: C.htm) Title: Message Can anyone tell me why Apache would dump core when more than 2 PerlSetVars are used in a Location directive? This is Stronghold 2.4.2, Apache 1.3.6 and mod_perl 1.21 Brian Hann
Re: OSCON ideas
I agree. There are probably more of us than might be immediately obvious, too. If a mod_perl programmer doesn't see too many mod_perl jobs in their area, they're likely to highlight other areas when they go job hunting even if they'd rather do mod_perl and could do it well. I wonder if telecommuting plus occasional travel for face-to-face would sell better than pure telecommuting. Is this done very often in telecommute situations? Wes Geoffrey Young [EMAIL PROTECTED] on 01/09/2003 01:49:23 PM To:Narins, Josh [EMAIL PROTECTED] cc:mod_perl list [EMAIL PROTECTED] Subject:Re: OSCON ideas but where do you get a corporate experienced, clean-cut (75%, at least) person willing to put on the tie 5 days a week and do mod_perl? I suspect that there are actually quite a few people on this list that would _love_ to do mod_perl full time. after talking to a few employers over the past year, it's getting them all in one place that's the problem - you probably want them onsite and, unlike the slurry of java programmers in your immediate area, what mod_perl experts there are are spread over the globe and may be unwilling to relocate. open up to telecommuting and I suspect you would soon find yourself fully staffed. --Geoff
Re: development techniques
I use HTTP::WebTest for that sort of regression testing, just to make sure nothing breaks along the way. I also use LWP and HTML::LinkExtor to check some dynamically generated pages to make sure it's still generating valid links. (It broke once, so after fixing I added a test for it... ) For debug messages I generally just use warn statements temporarily, then remove them when done. I've toyed with Log::Log4perl a little bit, and will probably use that if I ever decide it's worth the setup time. I think it's based on a Java logging tool called Log4J or Log4Java or the like. Wes Andrew Wyllie [EMAIL PROTECTED] on 01/09/2003 04:22:43 PM Please respond to [EMAIL PROTECTED] To:Jim Martinez [EMAIL PROTECTED] cc:mod_perl list [EMAIL PROTECTED] Subject:Re: development techniques On Thu, 09 Jan 2003, Jim Martinez wrote: (snip) Will the use of lwp instead of a browser improve my coding ability (either in terms of speed or just improving my perl coding)? Seems like I'd have to spend too much time with the lwp script (tell it to first request the page then choose option A and B then hit the submit button ... ) I think the advantage of using LWP for testing is that you could write a large series of tests which could be run frequently. So, if you make some little change way down in the guts of your code, you can then run all your tests to make sure everything is still working without having to worry about missing something along the way. So, it may seem like a lot of work up front, but in the long run you are better off. There is other stuff out there that you can use for testing. Test::Unit come to mind, and there is a test framework I read about called puffin (http://www.puffinhome.org/) which sounds like it could be useful. andrew
Re: use http-equiv to refresh the page
Any time you see an Internal Server Error, you should be looking in your
apache server's error_log file to see what exactly the error was. That will
help you (and the list) figure out what's going wrong.
Wes
Wei Gao [EMAIL PROTECTED] on 11/05/2002 06:10:34 PM
To:Perrin Harkins [EMAIL PROTECTED]
cc:[EMAIL PROTECTED]
Subject:Re: use http-equiv to refresh the page
Thanks.
I have tried print $query-redirect('http://somewhere.else/in/movie/land')
; before, which works fine as to redirect the user to the web page.
However, if the user then tries to refresh this page, the CGI script is
called again without any params, which result in Internal Server Error.
So, the goal I want to achieve is that the user can refresh the page I
returned without getting an error. It should refresh the web page, not
calling my CGI script again.
I also tried print $query-redirect(-uri
='http://somewhere.else/in/movie/land', -nph=1); moments ago, which
generated an Internal Server Error in IE window.
Is using meta tag a bad approach? I thought this is a way to solve my
situation here.
Wei
- Original Message -
From: Perrin Harkins
To: Wei Gao
Cc: [EMAIL PROTECTED]
Sent: Tuesday, November 05, 2002 2:50 PM
Subject: Re: use http-equiv to refresh the page
Wei Gao wrote:
In my perl program executing in Apache web server, I have the
following code:
use CGI ;
$query = new CGI ;
$url = http://www.mycite.com ; #The url to refresh.
print $query-header(-status='200 Ok', -type='text/html');
print htmlheadmeta http-equiv=\Refresh\
content=\0;URL=$url\ //head/html;
Uh, that's not a redirect; that's an ugly proprietary hack. You should
be using standard HTTP redirects. See
http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm#GENERATING_A_REDIRECTION_HEADER
for more.
- Perrin
(See attached file: C.htm)
Thanks.
I have tried "print
$query-redirect('http://somewhere.else/in/movie/land') ;" before, which
works fine as to redirect the user to the web page. However, if the user then
tries to refresh this page, the CGI script is called again without any params,
which result in "Internal Server Error". So, the goal I want to achieve is that
the user can refresh the page I returned without getting an error. It should
refresh the web page, not calling my CGI script again.
I also tried "print
$query-redirect(-uri='http://somewhere.else/in/movie/land',
-nph=1);" moments ago, which generated an "Internal Server Error" in IE
window.Is using meta tag a "bad"
approach? I thought this is a way to solve my situation here.
Wei
- Original Message -
From:
Perrin Harkins
To: Wei Gao
Cc: [EMAIL PROTECTED]
Sent: Tuesday, November 05, 2002 2:50
PM
Subject: Re: use http-equiv to refresh
the page
Wei Gao wrote: In my perl program executing in
Apache web server, I have the following code:
use CGI ; $query = new CGI ; $url = "http://www.mycite.com
; #The url to refresh.
print $query-header(-status='200 Ok',
-type='text/html'); print "htmlheadmeta
http-equiv=\"Refresh\" content=\"0;URL="$url\""
//head/html";Uh, that's not a redirect; that's
an ugly proprietary hack. You should be using standard HTTP
redirects. See http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm#GENERATING_A_REDIRECTION_HEADER
for more.- Perrin
RE: [OTish] Version Control?
Hi Jesse, I really like your approach, and appreciate your explanation. I'm wondering how you handle the packaging and installation; do you just use a shell script to put the different pieces where they belong, or have you devised something else? Right now I'm also using CVS for my web development, and have the modules built around ExtUtils::ModuleMaker. The server gets updated via the standard perl Makefile.PL make make test make install. My htdocs and templates are in their own dirs but in the same overall hierarchy as what ModuleMaker generates, and they get installed during the 'make install' part through some extra rules in the Makefile.PL files. Devdocs are all in POD, but I don't really have the bin and cron types of things from your system well integrated; they seem too peripheral to include with the 'make install' stuff. Of course another consideration is that I'm developing for an intranet, not deploying to external customers, so I have a lot more control of the production server. Wes Sheldahl Jesse Erlbaum [EMAIL PROTECTED] on 10/30/2002 04:47:41 PM To:[EMAIL PROTECTED] cc: Subject:RE: [OTish] Version Control? small excerpt from original post follows Web development projects can map very nicely into CVS. We have a very mature layout for all web projects. In a nutshell, it boils down to this: project/ + apache/ + bin/ + cron/ + devdocs/ + htdocs/ + modules/ + templates/ Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Copying Apache/Mod_perl/perl installation
For the CPAN perl modules, check out the CPAN autobundle feature. It will make a Bundle file of every perl module installed on your machine, which you can then copy and install on the new machine. Installing the bundle file will make it download and install all the CPAN modules. For the rest, either copy and install the same RPM files, or put the installation steps into a script, copy the script and tarballs to the new machine and run the script there. Hope this helps, Wes Sheldahl Ganesan M [EMAIL PROTECTED] on 10/08/2002 10:31:09 AM To:[EMAIL PROTECTED] cc: Subject:Copying Apache/Mod_perl/perl installation Hi all, This is kinda installation question. I have installed perl, Apache, Mod_perl with some modules (GD, Apache FileManager, DBD-Chart etc.,) in my development machine. Is there anyway to copy the installation to a similar OS/architecture without going through all the installtion proceedures. In another words, can I copy the installed software/packages to another machine which is of same OS/architecture? Any help/url/RTFMs... 'd be appreciated. TIA, G-Man.
Re: Seg Fault with PHP and Perl together
Check the mail archives for this list, there was a thread about using perl and
php together not that long ago. I think that one suggestion was to compile
mod_perl statically with apache, and to load php as a module. Also, you may want
to upgrade your perl to at least 5.6.1, if not 5.8.0. Are you using apache
1.3.26? (anything older has a well-known security exploit). What version of
mod_perl?
Wes
Jon Harris [EMAIL PROTECTED] on 09/04/2002
01:17:44 PM
To: [EMAIL PROTECTED]
cc:(bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: Seg Fault with PHP and Perl together
Hi
I inherited a very happy cobalt raq3 with 2 sites using embedded Perl
which work very well. There are about 20 sites on the box. I needed to
get PHP running on the same box, so I made the module, added it into the
httpd.conf and PHP was working fine - Except that it broke the perl sites.
The http error log entry is:
child pid 22610 exit signal Segmentation fault (11)
- the client gets a 'page not found error'.
All I have to do get perl working again is to comment out
LoadModule php4_module /usr/lib/apache/libphp4.so
(and)
AddModule mod_php4.c
and restart httpd, it works fine again, obviously minus the php
Bearing in mind, I am on about page 3 of O'Reilly's Apache - The
definitive Guide does anyone know the simplist way I can get it
working? I don't need any sites to use both embperl and php together.
This is a virtual site section in httpd.conf for one of the perl sites
(anonymised) there is also a big Perl chunk in the httpd.conf, not
sure if that is relevant here.
*
VirtualHost 0.0.0.0
ServerName thedomain.com
ServerAdmin root
DocumentRoot /home/sites/site42/web
ServerAlias thedomain.com
PerlModule Apache::DBI
PerlModule HTML::Embperl
PerlSetEnv EMBPERL_OPTIONS 8208
PerlSetEnv EMBPERL_ESCMODE 0
RewriteEngine on
RewriteCond %{HTTP_HOST}!^0.0.0.0(:80)?$
RewriteCond %{HTTP_HOST}!^www.thedomain.com(:80)?$
RewriteRule ^/(.*) http://www.thedomain.com/$1 [L,R]
RewriteOptions inherit
#Files *.htm*
#SetHandler perl-script
#PerlHandler HTML::Embperl
#Options ExecCGI
#/Files
AliasMatch ^/~([^/]+)(/(.*))? /home/sites/site42/users/$1/web/$3
AliasMatch ^/users/([^/]+)(/(.*))? /home/sites/site42/users/$1/web/$3
# AddHandler server-parsed .shtml
# AddTypetext/html .shtml
AddHandler cgi-wrapper .cgi
AddHandler cgi-wrapper .pl
/VirtualHost
*
It looks like perl and PHP are getting in each others way, should I try
and make a new apache? what order should I do things in? Should I look
for another job? :), I need to get it working quickly and with the
minimum disruption to the server. Every time I try and do things like
this on a RAQ something breaks something else, usually its the GUI and I
get about 50 phone calls.
perl is version 5.005_03, Apache 1.3, PHP 4.21
TIA
Jon Harris
[EMAIL PROTECTED]
Re: [Q] Exception Handling
Take a look at Exception::Class, which I believe uses Devel::StackTrace. Both
are available on CPAN.
I personally derived a lot of benefit from seeing how exceptions were done in
Alzabo (http://www.alzabo.org), even though I'm not using Alzabo itself in my
applications. All three modules are developed mainly by Dave Rolsky, IIRC.
(Thanks again, Dave.)
Wes Sheldahl
THC Soft [EMAIL PROTECTED] on 08/28/2002 03:00:24 AM
To: [EMAIL PROTECTED]
cc:(bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: [Q] Exception Handling
Hi all,
I usually receive just the digest mails and don't take part in the
discussions, so I'm maybe new to the list. I studied mod_perl guide,
grepped through my archives, visited search.cpan and even asked some
perlmonks, but couldn't find an answer to my problem. Here it is:
I have a content handler, which calls another module for translating
perl sources into valid html code. As this results in various nested
eval blocks, and each of these blocks will possibly die or warn for some
reason, I like to have a stacktrace through the eval{}s being reported
to the client in error cases, something like:
A mystic Perl error in some context
at /var/www/html/test/t3.html line 8
at /var/www/html/test/t2.html line 2
at /var/www/html/test/t1.html line 889
(Please believe me: Carp is for special reasons *not* the answer)
If I understand the mod_perl guide (pp. 70-73) right, the solution will
be in an Exception class, overriding the CORE::die function. Well, but
if my translation module implemented that class, and Exception.pm
finally CORE::die()s, what about the content handler? Let's say the
translator dies with a well formed stacktrace, how can I get this to
the browser? Is it possible to override CORE::die twice? In the inner
loop, the translating module, and again by the content handler? Would
Exporter-export_to_level be a way out? Or the Exception class being
used by the translator, while the content handler simply uses CGI::Carp
qw(fatals_to_browser) ? (If the content handler used the Exception
class, this one would have to interfere with values it cannot know.) Or
is there actually no problem at all, and I've just lost my way?
I hope I could make clear what I mean, my English must read awful for
native readers. Anyway, if you got a clue, or just an address where I
could dig a little deeper...
Thanx a lot in advance
regards
Martin
Re: Flaky behavior with modperl module
When you View Source in your browser, are the img url's in the broken images correct? Do you get any errors in your error log? anything strange in your access log? Wes The Surprises [EMAIL PROTECTED] on 08/27/2002 01:37:14 PM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Flaky behavior with modperl module Greetings, I am writing a modperl module to create dynamic picture web pages created from .jpg files in a given directory. It basically puts a bunch of pictures on the screen. I am seeing inconsistent behavior and I don't know where to look for a solution. When I load the page, random pictures don't get loaded. They're just small boxes on the screen. Reloading the page will give me another set of random missing pictures. The server is behind a cable modem and it has a max upload bandwidth of 256kb, so it's kinda slow. Am I seeing some sort of timeout or flakiness with my cable modem bandwidth? Thanks for any help Jason
Re: [Newbie Q] Cleanest way to implement one logon per user?
The drawback could probably be at least partially mitigated with an inactivity timeout. When they attempt to login, you check both the flag and the last time you heard from them. If they had timed out, then you log them out and let them go ahead and try to log in. It does cost an extra database write on each request though, to keep the last activity time up to date. Wes Robert Landrum [EMAIL PROTECTED] on 08/01/2002 03:28:05 PM To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: [Newbie Q] Cleanest way to implement one logon per user? On Thu, Aug 01, 2002 at 03:08:40PM -0400, Baljit Sethi wrote: Hello. I am hoping someone can point me in the right direction. What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. The problem isn't determining when they've logged in, but determining when they've logged out. While it may be possible to write a record to the db that contains username, password, and IP address, it does not gaurentee that the user's ip address will not change mid session. (cable modem disconnect and reconnects with new ip, transparent to the user.) The short answer is, you can't. The long answer is that you can, but it takes way more work than it's worth. The only way I've seen is to set a cookie (encrypted) on the client's machine and flag the user as logged in. If the user tries to log in again (from anywhere), it rejects it. Only if the original client connects and clicks logout (and the cookie still exists) does it actually remove the flag (and the cookie). The drawback here is that if any user ever deletes their cookies before logging out, they're screwed, and will call asking you to fix it. Good luck, Rob
Re: Problems using Perl v 5.8
Does it help to update mod_perl to 1.27? Wes Pasquale Pagano [EMAIL PROTECTED] on 07/29/2002 12:35:10 PM To: Modperl [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Problems using Perl v 5.8 Hi, We have some problems using: 1) Perl v 5.8 2) Mod_Perl v 1.26 3) Apache v 1.3.26 In particular: a) if we use simple CGI, everything works fine; b) if we use a custom handler for mod_perl, everything works fine; but if we try to use our CGI via Apache::Registry or Apache::PerlRun handler the code is ran correctly but we are able to send back to the browser only the HTTP header (everything else is missed). Here below an example of the http response -__- HTTP/1.1 200 OK Date: Mon, 29 Jul 2002 17:20:02 GMT Server: Apache/1.3.26 (Unix) mod_perl/1.26 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -__- Any of you have some hints?? Any help will be welcome, Regards, Lino PS: The same code works fine using Perl v 5.7.2. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR - Istituto di Elaborazione della Informazione Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 E-mail: [EMAIL PROTECTED] .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Re: Hiding perl code
Thanks, Iain! This helps explain some problems I ran into when I tried to use Switch. ;-) Wish the Switch docs included some caveats about using it with mod_perl Wes Sheldahl Iain Truskett [EMAIL PROTECTED] on 07/21/2002 11:10:25 PM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Hiding perl code * Jonathon M. Robison ([EMAIL PROTECTED]) [22 Jul 2002 13:03]: Anyone know offhand a good way to hide your perl code when using mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on initial test [...] Acme::Bleach is a source filter. Source filters will just screw up your mod_perl stuff. IIRC, you get similar problems using Switch and so on. Perhaps perl2exe? Nope. That does weird compiler stuff that will interfere with the fact that Apache's using Perl internally. As far as I know, there's no good way to do it. It is Perl after all. And with mod_perl things just get trickier. Out of interest, why? cheers, -- Iain.
Re: [OT] RE: Question about Work Wanted ads
That's true. However, you can deduct any expenses incurred in the course of volunteer work, such as milage to and from the site, and so forth. Again, this is in the US, YMMV elsewhere. David Harris [EMAIL PROTECTED] on 06/20/2002 04:04:38 PM To: 'Marc Spitzer' [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: [OT] RE: Question about Work Wanted ads Marc Spitzer [mailto:[EMAIL PROTECTED]] wrote: 3: you maybe able to deduct your volunteer work from your taxes( I have no idea about AU's laws though). You can not claim donated services as a tax deduction in the US. (Probably not other places too, I'd guess.) The theory is this: you'd have to book both a revenue for the work you did and a deduction for the donation. These would cancel out. David
Re: mod_perl module documentation
Just speaking as a mod_perl user/developer, I think the format of Rich's docs is excellent. Since these are directives that belong in httpd.conf, it makes sense for their documentation to look like the documentation of other non-perl directives that belong in httpd.conf. Organization-wise, Rich's docs seem like a reference, whereas most of the docs Stas points to seem to be more tutorial or task-oriented in nature. Perhaps Rich's docs should remain fairly slim, with links to more comprehensive discussion in the 'tutorial/howto' docs? Would that be maintainable? Wes Stas Bekman [EMAIL PROTECTED] on 06/18/2002 02:09:51 PM To: Rich Bowen [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: mod_perl module documentation Rich Bowen wrote: It has long frustrated me that there was no mod_perl module documentation, in the style of the standard Apache module documentation. I don't mean to bash the docs that are there - clearly, they are of exceptional quality. But I wanted something like the standard module docs. So, rather than complaining, which would seem to be, at best, in poor taste, given the quantity of stuff that folks like Stas have already written, I've started on a mod_perl module doc, based on the Apache 2.0 module documentation XML template. You can see the first cut at http://www.apacheadmin.com/mod_perl.html I know, it is gravely lacking, and needs help. And I intend to do something about that. But I have a few questions before I burn a lot of time on that. If you plan to leave it just as it's now (bare bones) it's ok. But if you plan to really write full fledged docs, please don't. Why duplicated efforts and confuse users with inconsistent documentation which is already *huge*. Have you see the work we have done in the last half a year? http://perl.apache.org/release/docs/ I've been working on docs similar to your doc recently: http://perl.apache.org/release/docs/2.0/user/config/config.html http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html not very different than yours but adhers to the rest of the documentation. We already have 106 pods (2.3MB) and growing. So if you want to help please join the docs list and let's talk there: http://perl.apache.org/release/maillist/docs-dev.html#Subscription_Information we may come up with an idea to make Apache style docs as well, but only bare bones with pointers to the real docs. let's talk over docs-dev. Where, if anywhere, should such a document go? Yeah, it can stay where it is, but I would not think that anyone would think to look there. we have it already. Has someone already done this, and I'm just missing it? I know that there is similar information at http://www.apacheref.com/ref/mod_perl.html but I was hesitant to steal that wholesale. Besides, everyone should buy Ralf's book, and I don't want to dilute that in any way. ;-) Is there currently, or are there any plans for, a mod_perl documentation cvs repository, where something like this could live? the repository exists for some 9 months, called modperl-docs Anyways, tell me what you think. I have the original XML, which is vastly more useful than the HTML output, and would be glad to give that to anyone that wants it. see above __ 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: Separating Aspects (Re: separating C from V in MVC)
Ow. That philosophy of 'make it impossible for the programmer to mess up' sounds too reminiscent of Pascal and other straightjacket development environments. I don't think there's any real substitute for well-disciplined, thinking programmers. So my own quest right now is to develop more of the right disciplines, rather continue on some quest for a mythical Template System to End All Template Systems or whatever. For example, you mentioned you don't like objects in templates because they introduce complexity. But others have already pointed out that objects can be used in templates as simple read-only accessors by HTML designers who don't need to know how the object is implemented. That's the great thing about encapsulation. Sure this feature could be abused, but I'd rather err on the side of freedom. --Wes Sam Tregar [EMAIL PROTECTED] on 06/05/2002 06:45:34 PM To: Andy Wardley [EMAIL PROTECTED] cc: modperl List [EMAIL PROTECTED], Template Toolkit List [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Separating Aspects (Re: separating C from V in MVC) Here's my theory: the best usage of most templating systems are virtually indistinguishable and all result in reasonably maintainable systems. However, the bad usage of some templating systems is much worse than others. Also, the general usage of a templating system, even by otherwise bright people, tends more towards the bad than the good. Thus my solution: a templating system that simply will not allow you to put anything significantly complicated in the template. You can't. If you want complexity you'll just have to put it in the code, where it belongs. That's HTML::Template in a nutshell. [% silver.bullet %] isn't the answer by itself... Here here. Neither is tmpl_var silver_bullet but I'd rather get shot with mine than yours! -sam
Re: DBI Bug
By that do you mean DBI 1.24? That was just released a day or two ago IIRC. Just checking, Wes Udlei Nattis [EMAIL PROTECTED] on 06/05/2002 03:39:00 PM To: Stas Bekman [EMAIL PROTECTED] cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: DBI Bug i using last version of DBI bye nattis
Re: Apache+Modperl Website Statistics
One solution would be to put the javascript in its own .js file, and have every page on your site reference that js file. Now every page will send a cookie with the resolution information. You may want to adjust the server-side processing to avoid duplicate database work, but that shouldn't be a big issue. Wes Philip M. Gollucci [EMAIL PROTECTED] on 03/27/2002 05:40:47 AM To: darren chamberlain [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Apache+Modperl Website Statistics Well I've basically taken your route the first time I tried to do this a year ago. The other problem is that this requires the vistors go to this particular page. If they bookmark to another page or type the url of a sublink, this is bypassed, and I loose the statistical information. My problem is that the PerlLogHandler I've set up isn't actually supposed to ever display anything to the browser. (I don't think any PerLogHandler anyone writes should send anything to the browser as is basically an extension to use instead of the apache's access_log file. Although it could if you had a good reason. In order for the javascript I gave to get values it has to be sent to the browser on a page so its processed my the javascript engine in the browsers. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 snip On Wed, 27 Mar 2002, darren chamberlain wrote: * Philip M. Gollucci [EMAIL PROTECTED] [2002-03-27 09:59]: I know perl is server side and javascript is client side. AFAIK, getting the resolution is a client side thing. I know I can embed an html page with javascript in it that redirects to a perl file setting the query string with width=1024;height=768 [-- snip --] But, I need to find someway to do this without the extra redirect. Since, as you already realize, there is no way to get the client information from the server size, I think the best you can do would be something along the lines of: have a javascript enabled page that gets the height and width of the client (as you've shown), that then redirects the client to a location that can read the height and width from the query string and set a session cookie, which can then be read and acted upon for every subsequent request by a PerlTransHandler or RewriteRule. Does that sound reasonable? (darren) snip
Re: [OT] Off topic question a little worried
This link offers some general guidelines for recovering from a compromised server: http://www.cert.org/tech_tips/win-UNIX-system_compromise.html Hope it helps, and good luck. Wes Perrin Harkins [EMAIL PROTECTED] on 03/21/2002 03:42:55 PM To: John Michael [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Off topic question a little worried John Michael wrote: Any idea as to how it got on my server. Someone found a serious security hole in something you're running. You have to assume that your server has been completely compromised and that the entire world now has root access to it through a hundred backdoors they installed. Take it off-line now, before you find out it sent millions of porn spam messages. You can study it later to try and find the problem. - Perrin
RE: [OT-ish] Session refresh philosophy
I can see how your approach adds functionality by performing as expected if the user uses the Back button or opens the app. in more than one browser window. The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? Wes Sheldahl David Harris [EMAIL PROTECTED] on 02/20/2002 09:50:11 AM To: Perrin Harkins [EMAIL PROTECTED], Drew Taylor [EMAIL PROTECTED], mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: RE: [OT-ish] Session refresh philosophy Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain:
Re: [OT-ish] Session refresh philosophy
You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the hidden cleartext data from others on the client side. I guess that's a matter of how paranoid you think you need to be, and how confidential is the data you're storing. Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. Looks like it might worth be taking another look at this approach next time I start a new project. Wes [EMAIL PROTECTED] on 02/20/2002 11:48:28 AM Please respond to [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: Re: [OT-ish] Session refresh philosophy The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. Both page types may have form input validation code on the server side, but in the first case this is just convenience for the user (warn early and don't say woops after 9 pages and 10 minutes of typing). The latter MUST have validation for security to hold (even if this means validating twice). This way, changing hidden fields gains an attacker nothing, since he will be blocked at the final submit anyway. Doing things this way also has other advantages e.g. interfacing: one can write automatisms with wget or LWP::UserAgent to trigger actions in the database without any further programming needed on the server side. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
Re: inheritance and Apache::Request
Hi Alex,
The problem is that package FooBar doesn't have a new method. Here's what
happened as a result.
When you called 'FooBar-new($r), perl looked for a sub called new in package
FooBar. Since it didn't find one, it looked at FooBar's @ISA, and looked in
Apache::Request for a new method. There it presumably found one, so that
statement didn't return an error. But, the new() in Apache::Request probably
returned an Apache::Request object instead of a FooBar object, so when you
called $form-fooey, it only looked in Apache::Request and any modules in it's
@ISA.
You might want to look at using the universal isa and can methods while
you're debugging and trying stuff out. Good luck!
Wes Sheldahl
Alex Porras [EMAIL PROTECTED] on 02/14/2002 01:44:20 PM
To: mod perl list [EMAIL PROTECTED]
cc:(bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: inheritance and Apache::Request
I am slowly learning about OO from Tom's tutorial, and was able to do
inheritance with two dummy classes I wrote, including adding methods to the
subclass and have them work too. However, when I tried to inherit from
Apache::Request, it doesn't seem to work right. Maybe this isn't an
Apache::Request issue, so forgive me if that's the case, but here's what I got:
FooBar.pm
-
package FooBar;
use strict;
use Apache::Request();
@FooBar::ISA = qw(Apache::Request);
sub fooey {
print hello world, I'm in FooBar;
}
-
Handler.pm
-
sub handler {
my $r = shift;
$r-send_http_header('text/html');
my $form = FooBar-new($r);
$form-fooey;
$r-exit(OK);
}
Here's the error I get:
[Thu Feb 14 12:35:14 2002] [error] Can't locate object method fooey via
package Apache::Request (perhaps you forgot to load Apache::Request?) at
/path/modified/Handler.pm line 21.
Re: FW: PerlEditor - Freeware or Trialware
Use vim, namely the gvim or graphical vim editor, which works very well under windows. syntax highlighting, full toolbar, and all the rest. If you've tried vim before and the two modes gave you fits, there's now an Easy version that doesn't make you switch between command and insert mode; can't say I've tried it, but it's another reason to check it out. I've also heard that vim can actually integrate with Visual Studio, if that matters to you. If you go to http://www.vim.org, and look for the mirrors, you should be able to find a precompiled Windows binary of gvim without too much trouble. --Wes Sheldahl Anand Ratnasabapathy [EMAIL PROTECTED] on 12/25/2001 11:19:38 PM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: FW: PerlEditor - Freeware or Trialware Sorry ! I am on Windows NT 4.01, I need some thing similar to PerlBuilder which has only 14 days trial, something more ,I need... TIA, Anand -Original Message- From: Anand Ratnasabapathy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 25, 2001 12:37 PM To: [EMAIL PROTECTED] Subject: PerlEditor - Freeware or Trialware Can any one help me with a Nice Editor for working on Perl-cgi, Must be trial or freeware for me to test. Any Takers, Regds, Anand R DSM Soft I am back to the ring
Class::Singleton dies on warn?
Hi, I just started experimenting with Class::Singleton to store some static config information. I subclassed it, put a couple test variables in it, and loaded in my HTML::Mason page. Everything seemed fine. Then I added a simple warn statement to the _instance_new() method so I could verify exactly when it got instantiated from scratch, and it basically got treated like a die statement, spewing the standard Mason stack trace that Mason normally does on run-time errors. Is this a bug or a feature? The solution seems to be to avoid warning statements like the plague in any Singleton objects. Versions: Apache: 1.3.20 mod_perl 1.26 perl 5.6.1 HTML::Mason1.03 Class::Singleton1.03 OS: Linux, kernel 2.2.19 Thanks, Wes Sheldahl
Re: Tips tricks needed :)
1. Regarding the switch to postgresql, I think that's a good choice. Just pay attention to postgresql's data types, and try to get your fields types and lengths correct the first time if possible. It doesn't completely support the ALTER TABLE command, so changing column types can be a pain, although it's still possible. The other thing is that SQL syntax might be slightly different in a few cases, though it's been too long since I used MySQL to remember any examples. Postgresql's web site has some tips for switching, I think at http://techdocs.postgresql.org. 2. Have them read some articles on the whole MVC approach, since it sounds like you'll be using that. And of course read Damian's book several times for OO perl. 4. You might put the formulas in a perl superclass, with one method per formula. Then create a subclass for each different company that has that company's algorithm. All the calling code has to worry about is which company it's dealing with when it instantiates the object; after that all the right formulas will get used automatically. This should make it easy to add more companies, too. I guess the general principle is that when you're faced with tons of complexity, try breaking it down into smaller pieces and add an abstraction layer or two, so you and the program can deal with it. Hope this helps. I'll be watching for the success story! -- Wes Sheldahl Viljo Marrandi [EMAIL PROTECTED] on 12/19/2001 03:50:49 AM To: modperl list [EMAIL PROTECTED], templates list [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Tips tricks needed :) Hello, We're going to make a web-site for insurance company (err, more like portal for several companies) and the problem is that ( I think ) it's going to be our biggest and most complex site we've ever done AND we're going to use some new stuff we've never used. So I'd be very happy if you can give me some points what to look at, what are real no-no's and what are go-go's. 1. We're going to switch from mysql to postgresql, because we need transactions, triggers and all other stuff that mysql doesn't support. What could be possible problems going from mysql to postgres, if any? 2. We will use Template-Toolkit and Apache/mod_perl. Problem is that 2 out of 3 people have never used TT or programmed mod_perl and OO Perl. Only I've made sites this way, they've used Embperl til now. How can I make this switch for them a little easier? I know I must spend a lot of time teaching them, but may-be there are some kinda switchover tutorials or something? 3. Authorization. Is cookie based auth most reasonable or are there some other ways too? .htaccess will not do, I think, because all data is in the same directory and authorized access/login is needed only on some parts of site. Which data should I send with cookie? Only some random key which is also stored in dbase and this key is used to find real data from dbase? (I guess I must read again this thread about cookies). 4. How is most reasonable to store(and use too) complex formulas and coefficients? Problem is that there are 4 companies and each of them has different way to calculate same thing eg. insurance for travelling, car insurance etc. Unfortunately they are all quite different, because every company uses even different things to calculate final result. So if we use different formula for every company and insurance type we end up with ~50 formulas and none understands afterwards which is which. Are there any guidelines to generalize formulas? Ok, let's say we even somehow make these formulas general enough to use, but where shall the calculation take place? Postgres stored procs or in perl code/module (i think this) or even in TT? Constans will be in db. 5. Any other things to look out when creating large site and/or running it over SSL and/or using above described configuration? P.S. I hope that in about few months I can write about this project to success stories ;-) Thanks for your attention, Viljo
Re: mod_perl vs. C for high performance Apache modules
... years ago ... Are you even sure he evaluated mod_perl and not Perl CGI scripts?? Launching the interpreter and compiling every time might spike the CPU. Like others have said, you would really have to benchmark the mod_perl and Apache that you're using now; both have improved considerably over the years. You can point to the success stories others have mentioned to show that it really is one of the standard industry solutions that works well in many high-traffic situations. He's clearly arguing from outdated data and emotion. Also, if you delivered what you said you would deliver, that ought to be the end of it. If the site is performing according to expectations and promises, then he doesn't have any real basis to complain. If it would truly deliver tangible advantages to the client to rewrite it in C, or incorporate some of his C code in your work (Perl and C can get along sometimes), then you might consider giving him a quote to rewrite it. Ask him to put up or shut up. A gentler approach might be, Given we did what we did (and it works), what do you really want us to do now? What should happen from this point forward? If there isn't a constructive answer to that, then all you're dealing with is a temper tantrum. ---Wes Sheldahl ( father of four young'uns ) Jeff Yoak [EMAIL PROTECTED] on 12/14/2001 03:58:51 PM To: Thomas Eibner [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: mod_perl vs. C for high performance Apache modules [snip] So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. [snip] Cheers, Jeff
Re: Excellent article on Apache/mod_perl at eToys
Matthew Kennedy wrote: Secondly, I've worked on a good-sized commerce site with mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end of the site involves several standalone perl programs running as daemons. What's even worse is; most of them have to sit in poll/wait loops waiting on message from external systems (such as pop3 servers, ccvs etc.) Why exactly is that a dirty secret? I've been thinking about writing one or two standalone poe daemons to handle interfacing with other systems, and it doesn't seem like such a bad idea. Code to talk to or listen to web clients can be in mod_perl, and code to talk to other systems can be outside. I've even thought about taking some of the database objects out of mod_perl, but am less sure about doing that. Is anyone else using independent perl processes in a web app, or have strong reasons not to?
Re: Can't locate object method cleanup_for_exec via package Apache
You might be able to do what you want without forking, and without tying up your apache process while the database sync takes place. Just write a server process using something like IO::Socket or POE (see http://poe.perl.org). Have the mod_perl handler send a message to the separate server process to start the long-running job. You might even be able to query the server process from mod_perl to check on the status of said job, to report the status to the web browser.I started work on this sort of solution last spring, and it looked feasible, but I got pulled to a different project before I could fully implement it. I'm curious to see what others think of this approach. HTH, Wes Sheldahl Mike P. Mikhailov [EMAIL PROTECTED] on 10/08/2001 10:46:41 AM Please respond to Mike P. Mikhailov [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Can't locate object method cleanup_for_exec via package Apache Hi list, I'm understood that fork'ing from mod_perl is not very good idea, but we have no choice. Because it is up to user to decide to launch job which syncronize data in the two database sources. And this job may take a long time. I'm has no expirience before in using fork call, so I'm reading chapter '10.4.3 Forking and Executing Subprocesses from mod_perl' of mod_perl Guide careful. I'm understood that I must cleanup soket in child process. In '10.4.3.2 Freeing the Parent Process' written [cp]: 'Apache::SubProcess comes to help and provides a method cleanup_for_exec() which takes care of closing this file descriptor.' p 365. But I'm does not see such sub in the Apache::Subprocess. And my code generates run time error Can't locate object method cleanup_for_exec via package Apache My RH linux with kernel 2.2.14-5.0, Apache/1.3.12 (Unix) mod_perl/1.25 mod_perl Guide: Version 1.30 Sep, 2 2001. Apache::SubProcess v0.02. Am I miss something ? -- Best regards, Mike mailto:[EMAIL PROTECTED]
