RE: [OT] Wanted: beginning perl books for poor kids
Me too. (and sorry to for a couple of private replies its early and I haven't had much
caffeine this morning).
-Original Message-
From: Ryan Parr [mailto:ryanparr;precisiontechonline.com]
Sent: Friday, November 01, 2002 12:57 AM
To: Nick Tonkin; [EMAIL PROTECTED]
Subject: Re: [OT] Wanted: beginning perl books for poor kids
What open-source geek doesn't understand the importance, and
calling, of
supporting your community?
Count me in. I think it's great that you are donating your time and
patience. Teaching isn't easy, but you've got a great cause.
Send me your
shipping address and I'll send you a Llama book.
http://www.rain.org/~artworks/NewATW/students/norma_web/sonar.html is
striking. I hope this girl goes on to great things.
--
Ryan
- Original Message -
From: Nick Tonkin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 31, 2002 9:57 PM
Subject: [OT] Wanted: beginning perl books for poor kids
Hi all,
I am going to be working with a small group of
disadvantaged youngsters
here teaching them how to build web applications with perl and
apache.
These are mostly Latino kids who have been doing analog and
digital art
for years and have self-selected into webmastering,
html-ing and such.
I'm excited to get them going in perl, and I want to appeal
to the list
for donations of books on learning perl.
Of course I'm most hopeful that we can get half a dozen
copies of the
Llama book and use it as a sort of textbook, but anything will be
gratefully accepted.
An existing site that shows some of the art these kids make
(and also
why we need a new one!) can be viewed at
http://www.rain.org/~artworks/
A cool project by one of the students is at
http://www.rain.org/%7Eartworks/NewATW/students/norma_web/norm
a_intro.html
Thanks folks,
- nick
Nick Tonkin {|8^)
RE: [OT] Wanted: beginning perl books for poor kids
I would guess that these kids do not have access to computers outside school. Which makes access to printed material advantageous. I guess a printer would be nice, but by the time the cost of it, paper, ink, and other supplies are factored in, I would guess that books would be cheaper. -Original Message- From: Stone, Derrick J [mailto:DJS6D;hscmail.mcc.virginia.edu] Sent: Friday, November 01, 2002 9:01 AM To: John Saylor; Nick Tonkin Cc: [EMAIL PROTECTED] Subject: RE: [OT] Wanted: beginning perl books for poor kids Amen. http://www.comp.leeds.ac.uk/Perl/start.html http://archive.ncsa.uiuc.edu/General/Training/PerlIntro/ http://www.ebb.org/PickingUpPerl/ http://www.cclabs.missouri.edu/things/instruction/perl/perlcourse.html http://www.lanka.pair.com/techweb/perl/tutor/ oh wait... did you say spanish? http://epq.com.co/~cjara/perl/tutorial.html no? German? http://www.tekromancer.com/perl/inhalt.html Japanese? http://plaza27.mbn.or.jp/~satomii/jdoc/ Perldoc is a challenge if you're new, because the syntax can be hard to pick up. But for a good tutorial, a nice printer would go a long way... Derrick Stone Internet Specialist Web Development Center UVa Health System ICQ# 1464194 -Original Message- From: John Saylor [mailto:johns;worldwinner.com] Sent: Friday, November 01, 2002 9:05 AM To: Nick Tonkin Cc: [EMAIL PROTECTED] Subject: Re: [OT] Wanted: beginning perl books for poor kids Hi ( 02.10.31 21:57 -0800 ) Nick Tonkin: I'm excited to get them going in perl, and I want to appeal to the list for donations of books on learning perl. I'd say the best 'books' are all on line. Don't underestimate the [lowly] man pages. Or perldoc [-f]. And there are stories and tutorials and good stuff at perl.apache.org or perlmonks.org or www.perl.org [and so on]. Hopefully, your students [or school] has/have the resources necessary to use the on line resources. Good luck! -- .--- ...
RE: evil scripts kill the server...
-Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:49 PM To: Joerg Plate Cc: [EMAIL PROTECTED] Subject: Re: evil scripts kill the server... Hi there, On Wed, 16 Oct 2002, Joerg Plate wrote: Is it true that you can kill the whole server, not just the script if you do something wrong with mod_perl? Yes, I'm afraid it is. How? For example by swallowing all the memory, by consuming all the CPU, and of course by making root access available to the world through careless programming practice... Need I continue? Yes you should. You are making it sound like these problem are unique to mod_perl when they are not. While you allude to the real causes of many server problems - careless programming practice - you leave it open like mod_perl somehow intrinsically fosters careless programming or that even worse it is inherently not secure. Like any web server, a poorly configured and poorly programmed mod_perl enable server is prone to failure. Of course some could say that a poorly configed/programmed mod_perl/apache server is better than a well configed/programmed server of another brand. The original poster should know that any server can fail under to proper circumstances and that while technically the rumors are true (and are they really rumors? I don't think there is some hidden agenda in the mod_perl/apache community to hide server security issues) it is also just as true that a problem in a mod_perl script is not going to cause the server to fail completely. And all of that is true with any brand server. That is why you should have a development server to work on new code on, a QC server to test newly released code and a production server (or servers) for code you have tested and a sure is ready for prime-time. And again, that is not true only for mod_perl/apache, but is true for all webservers regardless of brandname.
RE: Memory leak on reload when the 'Pg' driver is preloaded
For what it is worth, we use a DSO mod_perl/apache that we compiled ourselves, on RedHat thought, that is very stable and does not have noticeable memory leaks and have been using it for over 3 years. Just thought I would throw that out there. -Original Message- From: Keith G. Murphy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:02 PM To: mod_perl Mailing List Subject: Re: Memory leak on reload when the 'Pg' driver is preloaded Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. Actually, that is what I have done already, several months ago. Seeing several reports of memory leak problems in the list made me think: Hmmm, wonder if someone else has seen this?
RE: [OT] - Mailing List Servers/mods .. etc
Look at MIME::Lite on CPAN -Original Message- From: Jim Morrison [Mailinglists] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 8:44 AM To: [EMAIL PROTECTED] Subject: [OT] - Mailing List Servers/mods .. etc Sorry.. This is completely off topic.. but I have a question you guys might help me with.. I'm writing then next part of a big modperl project I'm doing.. This bit could be loosely called a mailing-list-server.. The listserver is going to handle out-going (only'ish) opt-in mailing lists. The opting-in bit is all bound into the rest of the project, as is the construction of the outgoing email, and the list management... I'm wondering if there is any point in looking for a piece of third party software/module etc, that will handle the sending of the mail or should I work directly with sendmail? (Is sendmail the best mailserver for this kind of thing?) I'd be happy to write something along the line of formail.pl on my own, so I kinda know what I'm doing, but I'm gonna have to take things like Return to sender errors and such into account.. My question I guess is: - Is it ok to send 100's or 1000's of mails to sendmail in one go, or is there a better way of doing bulk mail? - Are there any mods to help with dealing with returned mail etc..? - Is there a good list of people doing this sort of thing? (Or do you mind the thread being a little off-topic!) I don't think I'm trying to reinvent the wheel.. Just that I think there is so much of my own coding involved, I'm not sure if I'm going to be able to get away with anything less than writing it from scratch.. Would be greatful for any advice, Kindest, Jimbo Jim Morrison _ Technology Development Partner Isotope LLP 9, 2 Laura Place Bath, BA2 4BH UK +44 (0) 1225 446170 +44 (0) 7940 937822 www.mediaisotope.com
RE: apche + mod_perl
Testic, Listed below are a few links that should get you on your way: First start with "The Guide" http://perl.apache.org/docs/1.0/guide/index.html. It has been very helpful to me when I have questions. Second go to http://www.modperlcookbook.org/(buy their book) It has some sample code and such which should help out immensely Finally visit http://modperl.com:9000/(buy this book also) It is a little hard to follow in the beginning, but it is worth while in the long run. I hope these help and good luck with you mod_perl adventure. Joe -Original Message-From: testic [mailto:[EMAIL PROTECTED]]Sent: Tuesday, September 17, 2002 3:22 PMTo: [EMAIL PROTECTED]Subject: apche + mod_perl Hi Guys, Having decided to give Linux a go I installed Linux and Apache on a spare machine at work with the intention of using it to run an intranet. I managed to run Apache succesfully to serve up simple HTML files, but I wanted some dynamic content so I installed Mod_perl as well. However I have run into a few difficulties regarding its configuration. The install process of mod_perl didn't throw up any errors and no lines were added to httpd.conf. I added a few lines that I found on a website to run mod_perl when Apache starts. Unfortunatley Apache generates errors with this config so I modified it so Apache starts. Could anyway tell me the lines I need to add to httpd.conf? Also, seeing as I've never used mod_perl (or Perl for that matter) I don't have any scripts, nor do I know how to add a script to a HTML page, so would it be possible for someone to tell me a very basic script that will merely let me know that it is running? System specs: RedHat Linux 7.1 (2.4.2-2) on i386 Apache installed in '/web/apache' Perl 5.6.0 Mod_perl 1.99_5 I realize that this is a very menial problem, but I scoured the Perl section of apache.org and couldn't find the information I required. Thankyou very much for any help you can offer. Testic
RE: Mail::Sender modperl.
I MIME::Lite to send messages. It uses your native sendmail install, or you can use it to send to an SMPT port. We actually have Qmail installed and it use the sendmail link Qmail configs and works just fine for about 40k emails a day. -Original Message- From: Richard Clarke [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 20, 2002 8:28 AM To: [EMAIL PROTECTED] Subject: Mail::Sender modperl. List, Have any of you had any problems using Mail::Sender from within mod_perl. My script seems to just sit there waiting for $sender-Open to do anything. I will email the author also but imagined he *might* not be familiar with mod_perl so won't be able to offer any suggestions. Anyone? I looked through the archives but saw no reference to a problem like this. Some people indicated much success with Mail::Sender (not so for me however!). Second, the recommended solution for sending mails is to instead put them on a queue for an external daemon to handle. My question is, is there a standard implementation people use when doing this. Is the KISS theory invoked and the outoing mail simply written to some plain text spool file or do people use something more involved like writing the to,cc,from,subject,body test to a database and storing any temporary files (attachment) in a directory for later encoding? Ric p.s. here is an excerpt from my apache log indicating precisely what happens 220 mail.likewhoa.com ESMTP Postfix 421 Error: timeout exceeded ehlo localhost mail from: [EMAIL PROTECTED] rcpt to: [EMAIL PROTECTED] data To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] X-Mailer: Perl script null using Mail::Sender 0.7.14.1 by Jenda Krynicky running on localhost (127.0.0.1) under account root Date: Sat, 20 Jul 2002 13:18:12 - Message-ID: [EMAIL PROTECTED] Subject: msg msg msg close sender . quit done The request took 305.710375070572 seconds
RE: Static vs. DSO on Linux specifically
Of course this is an old conversation, but we use mod_perl as a DSO here extensively with no problems. We have servers that have uptimes of almost 1 year (306 days as of today) and were taken down because the servers were moved to a new server room and not because of a problem with the DSO. And we get several thousand hits a day during the school year. It has been my experience that DSO vs. Static is not the issue it once was. Joe -Original Message- From: David Dyer-Bennet [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 10:27 AM To: [EMAIL PROTECTED] Subject: Static vs. DSO on Linux specifically I've seen a lot of comments which seem to me to say that a static mod_perl is the only way to go. But Redhat ships it as a DSO. Now, on the one hand, I wouldn't just automatically assume that Redhat knew what they were doing. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). (And I know a static setup would use somewhat less memory; but the last memory I bought for this server cost me $16.04 per 128MB, and it's connected to the net over only a 768k DSL line, so I'm not running *hundreds* of server processes; more like *tens*.) What I've found on the web so far makes claims strong enough that I feel my experience contradicts them adequately, and makes few actual *explanations*. So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
RE: Sending Mail
We use MIME::Lite seems to work well for us. -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 8:57 AM To: [EMAIL PROTECTED] Subject: Sending Mail Can anyone give me recommendations on a good Mail handler that integrates well with mod_perl? I have a system whereby I want to give people the ability to mail the currently viewed page to someone. Once they select a To: address, the system will look up some data, re-construct the viewed page in a textual format, and send the mail. I'm just looking for recommendations on a good perl mailing module for this kind of use. --Jon Robison
RE: OSC early bird and mod_perl T-Shirts
Why hasn't the logo that was voted on been considered? What's the point of a logo if you don't use it everywhere? -Original Message- From: Alfred Vahau [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 4:54 PM To: 'mod_perl list' Subject: Re: OSC early bird and mod_perl T-Shirts May I suggest a camel with the wings of an eagle or a double humped eagle??? The two icons are associated with the two invaluable references of the Perl world and somehow the design must incorporate them. I'm not about to suggest which creature gets the prominence. Final point: I'm 10 hrs ahead of GMT on the other side of the world. In these hard times, it's difficult to find a generous sponsor so I won't be attending the OSC. But I'd like to have a mod_perl 'T' one day. Please advice how I could go about getting one. Alfred Vahau Project Breeeze SNPS Uni. PNG Gunther Birznieks wrote: Maybe this year Randal Schwartz can get his idea implemented. I think he had suggested a motto last year that people seemed OK with but then the T-Shirts never got done in the end... Ah, the annual motto vote... :) Just re-read the same thread in the archives last year. Later, Gunther At 06:55 PM 6/11/2002, John Bass wrote: mod_perl: The camel with wings John -Original Message- From: Lupe Christoph [mailto:[EMAIL PROTECTED]] Sent: 11 June 2002 11:51 To: Leon Brocard Cc: mod_perl list Subject: Re: OSC early bird and mod_perl T-Shirts On Tuesday, 2002-06-11 at 10:44:26 +0100, Leon Brocard wrote: Yup, I have a designer here who is willing to come up with something. Constructive ideas welcome offlist. Better slogans than modperl: the only way to fly, modperl: obey your thirst etc. very welcome too ;-) SCNR: Quetzalcoatl: The Feathered Snake mod_perl: The Feathered Camel Profound excuses, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm | __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
RE: persistent Mail::ImapClient and webmail
We
implemented our own because mail is one part of a larger application and we
needed it to beintegrated with all the other part of the application. For
a pointer on the backend server config we used see the url http://howtos.eoutfitters.net/email.
I believe that the webmail that comes with courier-imap should work with this
configuration.
Thanks,
Joe
-Original Message-From: Medi Montaseri
[mailto:[EMAIL PROTECTED]]Sent: Saturday, June 08, 2002 5:13
PMTo: Joe BreedenCc:
[EMAIL PROTECTED]Subject: Re: persistent Mail::ImapClient and
webmailI was wondering why you implemented your own vs
using any of the following
- twig http://twig.screwdriver.net - Open
WebMail http://www.openwebmail.org
- WING http://users.ox.ac.uk/~mbeattie/wing/
- IMPhttp://www.horde.org/imp/
I am asking because I'm also interested in such an application (ie a
webmail app) Did you find something wrong with the above list, etc...
I tried WING, its PostgreSQL and Perl based, and very scalable but I found
the installation a hellas all complex systems would be
Thanks
Joe Breeden wrote:
We implemented a webmail front end with
Mail::IMAPClient and Mail::IMAPClient::BodyStructure without persistent
connections and it seems to work fine with several hundred connections. We
just opened up a connection to server do what we want then disconnect on
each request. I'm sure through persistent objectification we could have
reduced the load on the IMAP server and sped up the retrieval process, but
what we did worked fine.
We use qmail/maildrop/courier-imap for the mail storage see http://howtos.eoutfitters.net/email
for destructions on how to config that setup. I would share the code we used
for the IMAP client, but my company does sell that as a service so I think
they might get mad if I gave away our product.
I hope this helps.
Joe
-Original Message- From: Richard Clarke [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 9:28 AM To:
[EMAIL PROTECTED] Subject: persistent Mail::ImapClient and
webmailList, I
have the task in my hands of creating a web mail application.
Initial thoughts lead me to think I would use an external popper to
pop mail and parse it into a database for retrieval by the
modperl application. The only problem here is that I must
provide the implementation of the mail storage and folder
management etc. Something I would rather not spend my time on. So
my thoughts turned to IMAP. Retrieve the mail from an IMAP
server. IMAP itself supports most mail management methods such as
move message, delete message, save draft, mark seen etc.
So a few lines of perl later I had a PerlChildInitHandler
which connected to the IMAP server and saved the connection object.
I wanted to know if people saw any immediate problems with
this solution and also if anyone could explain the following
percularities. If I store a single imap object in $imap,
e.g. my $imap; sub connect {
my ($self,$centro_id) = @_;
print STDERR $imap,"\n";
unless (defined $imap) {
print STDERR
"Connecting to IMAP for $centro_id\n";
$imap =
Mail::IMAPClient-new( Server = 'cyrus.andrew.cmu.edu',
User = 'anonymous',
Password = '[EMAIL PROTECTED]',
); }
return $imap; } This seems to successfully save
the connection object. However if I attempt to store the
object in a hash, e.g. my %imap_cache; sub connect {
my ($self,$centro_id) = @_;
print STDERR $imap,"\n";
unless (exists $imap_cache{$centro_id}) {
print STDERR
"Connecting to IMAP for $centro_id\n";
$imap_cache{$centro_id} = Mail::IMAPClient-new( Server =
'cyrus.andrew.cmu.edu',
User = 'anonymous',
Password = '[EMAIL PROTECTED]',
); }
return $imap_cache{$centro_id}; } I seem to have
intermitent success in retrieving an already connected object.
Using the first example, as far as I can tell the object remains
available flawlessley. But storing the object in the hash
doesn't. Am I making a mistake here? Another
question sprung to mind, should I think about using
Persistant::Base or some similar approach to store the IMAP
objects?, or should I lean towards Randal's and others suggestions
of having a seperate (possibles SOAP or LWP::Daemon or
even apache server in single user mode) server specifically
designed for performing IMAP requests? Finally, does
anyone with experience in having to write webmail interfaces
see any problems with using the functionality provided by IMAP.
Richard p.s. Yes quite obviously if I
have 100 children then I'll be connecte
RE: persistent Mail::ImapClient and webmail
That's not necessarily the most secure way. We have found that even though IMAP is supposed to be a long state protocol many clients (PINE, Netscape, Balsa, M$ Outlook Express, etc) implement as connect/work/disconnect cycle. So I don't think this persistency of connection across multiple accesses is really necessary. -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 08, 2002 5:32 PM To: Richard Clarke Cc: [EMAIL PROTECTED] Subject: Re: persistent Mail::ImapClient and webmail On Fri, 7 Jun 2002, Richard Clarke wrote: p.s. Yes quite obviously if I have 100 children then I'll be connected to the IMAP server 100 times per user, hence possibly the need to have a either a dedicated daemon connected to the IMAP server once or some successfuly way of sharing IMAP objects between children. the trivial way would be to have the mod_perl processes login (once each) as some kind of super user and then access the folders as [username]/INBOX etc. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
RE: dso
I have to agree with this statement. We have a server farm with 15 apache servers running mod_perl as a DSO (not counting the several development and QC servers) with no problems. IMHO mod_perl as a DSO probably had problems in the beginning, but I couldn't confirm that without some research and I'm too lazy to do it, and as a result people now recommend compiling mod_perl into httpd. So I would say if DSO works for you use it, if not don't use it. -Original Message- From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 6:54 AM To: Arnold van Kampen Cc: [EMAIL PROTECTED] Subject: Re: dso At 11:41 29.05.2002, Arnold van Kampen wrote: Hi Some messages ago, someone still mentioned that modperl had been - compiled in -, when describing his configuration, that he was having trouble with. Does this mean it is still better to compile it in instead of using mod_perl as a dso? If you're having problems, it's often known to be the quick answer to try. If you're not having trouble, keep using DSO happily! -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: default page
or try in the perl.conf Location / SetHandler perl-script PerlHandler My::HandlerPackage /Location -Original Message- From: Dzuy Nguyen [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 3:12 PM To: [EMAIL PROTECTED] Subject: Re: default page Try DirectoryIndex. adam nelson wrote: I have a script that needs to be run when some one goes to the site: www.mysite.com/ it seems like the different ways that I've tried simply run the script through the normal cgi scenario without using perl-handler. Am I missing something obvious with httpd.conf?
RE: SOAP and web services
Bart, I would have to recommend SOAD::Lite ( http://www.soaplite.org) also. We use it accomplish many tasks - not the least of which is exposing Perl data structures to M$ ASP applications - which have a moderate load and have had no problems. Joe -Original Message- From: Bart Frackiewicz [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 12:34 PM To: [EMAIL PROTECTED] Subject: SOAP and web services Dear List, i want to create a server in mod_perl/apache, which receives request via get/post (plain), process this request (with database access and some functions) and answers in xml (with correct header), after planning this about a month i realized that this is called a web service. the difference between my solution and all articles was SOAP, which i understand as an extension to http, so in my opinion i need something that allows to parse the request and creates the output, is there a solution for mod_perl anyway? and is this solution stable for a production server which more than 10.000 request/day? i hope this is the right place to ask, but in all articles i read there were only examples for java/tomcat, not for perl/mod_perl. Thanks in advance Bart Frackiewicz -- BART FRACKIEWICZ systementwickler inity - agentur fuer neue medien gmbh birkenstrasse 71 40233 duesseldorf
RE: Cheap and unique
If you look at the docs for mod_unique it will generate a unique number in a properly configured server farm making it a good candidate for this process if you are worried about getting a unique number across several systems. -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 2:44 PM To: David Jacobs Cc: [EMAIL PROTECTED] Subject: Re: Cheap and unique David Jacobs wrote: I'm converting a few CGI scripts that used the PID as a cyclical unique number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). Our goal is to find a replacement function that is extremely cheap (cheaper than say, random(100)) and will never repeat. Any ideas? Yes, mod_unique_id will do that, as will Sys::UniqueID and Data::UUID on CPAN. Of course that random function is probably very lightweight, but it's not actually unique. - Perrin
RE: full-featured online database apps
Arghhh! Enough! Enough! Enough!. The question of which Template/App/Embed technique is best has been discussed to death. Please don't start a new round of 'beat the dead horse'. Links to a list of Application Servers/Toolkits/Embedded Perl see the url: http://perl.apache.org/#appservers or see the website for the mod_perl Cookbook which can be found at: http://www.modperlcookbook.org/ Joe -Original Message- From: Peter Bi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 4:06 PM To: Wim Kerkhoff Cc: [EMAIL PROTECTED]; Ken Y. Clark Subject: Re: full-featured online database apps Well, I changed it back to HTML::Template . It takes relatively less time to work it out with graphic designers. Peter - Original Message - From: Wim Kerkhoff [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Ken Y. Clark [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 1:50 PM Subject: Re: full-featured online database apps Since the excellent HTML::Template, the code becomes more re-usable... Sorry, had to be said. My point is that there are many templating systems to choose from. With a bit of fore thought, the Show, List, Delete, Add, etc buttons can be moved into different objects/methods/templates, so that it's easier to pick and choose your interface components. Wim On 24-Apr-2002 Peter Bi wrote: Since the excellent HTML::Template, the codes becomes more re-usable... Peter - Original Message - From: Ken Y. Clark [EMAIL PROTECTED] To: Adi Fairbank [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 1:23 PM Subject: Re: full-featured online database apps I've written so many on-line database apps in mod_perl/MySQL/Oracle that I think I'll go crazy sometimes. They all have so much in common, esp. the typical administrative interface where you have to show all, show one, edit, create, [confirm] delete, etc. Everytime I find myself following the same basic formula, but they're all so significantly different that I can't really see reusing much code. I guess you could abstract things to such a degree that lots of directives could be passed to extremely generic methods, but that actually has always seemed more trouble to me than it's worth.
RE: [ANNOUNCE] The New mod_perl logo - results now in...
Could you make it flaming? ;) -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 12:31 PM To: Jonathan M. Hollin Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] The New mod_perl logo - results now in... OK, here's my attempt at SVGing the logo. Works in Adobe's SVG viewer (Linux and Windows). I'll work on animating it next (making the cog spin). -- !-- Matt -- :-Get a smart net/:-
RE: [ANNOUNCE] The New mod_perl logo - results now in...
I think buttons based on the new logo are the way to go. -Original Message- From: Jonathan M. Hollin [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 9:17 AM To: 'Andrew Green'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [ANNOUNCE] The New mod_perl logo - results now in... :: Was there a button in the same style as the winning logo? :: Could Michael be persuaded to create one if not? :: :: I'm inclined to think a new logo is little use if you're not :: consistent with the imagery it uses. Tying a button design :: into that imagery is, IMO, essential. Michael Demers (the designer) will submit a few buttons, to match his logo design, in the near future. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ -- Temporarily off-line http://wypug.digital-word.com/
RE: Problem With DB_File Installation On Red-Hat Linux 7.1 [OT]
I had this problem the other day. And it was a screwy problem to fix. I had to get the latest BerkeleyDB, something like v4.0.14 (www.sleepycat.com) install it. Then reinstall the DB_File and I believe Storable modules making sure they pointed to the new install of BerkeleyDB. Of course, when I went through all of this I screwed up rpm somehow and other parts of my system so bad I surrendered and wiped my machine (which is my development desktop) and loaded RedHat 7.2. I think that trying to figure out the problem I uninstalled some RPMs I needed. If I had CAREFULLY followed the instructions for installing DB_File that came with the 4.0.14 BerkeleyDB install I think I would have been ok. It has been a few weeks since I went through this and I have seen a squirrel or two since then and it was a bad experience so I have tried to block the memories of the awful awful day. I hope this helps, but I doubt it will. Good luck. -Original Message- From: James McKim [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 9:01 AM To: [EMAIL PROTECTED] Subject: Problem With DB_File Installation On Red-Hat Linux 7.1 I'm trying to install DB_File on our Red-Hat Linux. 7.1 box and am getting an error about having 2 versions of BerkeleyDB installed. The log of the installation follows. Any help would be appreciated. James CPAN.pm: Going to build P/PM/PMQS/DB_File-1.803.tar.gz Parsing config.in... Looks Good. Checking if your kit is complete... Looks good Writing Makefile for DB_File cp DB_File.pm blib/lib/DB_File.pm AutoSplitting blib/lib/DB_File.pm (blib/lib/auto/DB_File) cc -c -I/usr/local/BerkeleyDB/include -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.803\ -DXS_VERSION=\1.803\ -fpic -I/usr/local/lib/perl5/5.6.1/i686-linux/CORE -D_NOT_CORE -DmDB_Prefix_t=size_t -DmDB_Hash_t=u_int32_t version.c /usr/local/bin/perl -I/usr/local/lib/perl5/5.6.1/i686-linux -I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp -noprototypes -typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap -typemap typemap DB_File.xs DB_File.xsc mv DB_File.xsc DB_File.c cc -c -I/usr/local/BerkeleyDB/include -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.803\ -DXS_VERSION=\1.803\ -fpic -I/usr/local/lib/perl5/5.6.1/i686-linux/CORE -D_NOT_CORE -DmDB_Prefix_t=size_t -DmDB_Hash_t=u_int32_t DB_File.c Running Mkbootstrap for DB_File () chmod 644 DB_File.bs rm -f blib/arch/auto/DB_File/DB_File.so LD_RUN_PATH=/usr/lib cc -shared -L/usr/local/lib version.o DB_File.o -o blib/arch/auto/DB_File/DB_File.so -ldb chmod 755 blib/arch/auto/DB_File/DB_File.so cp DB_File.bs blib/arch/auto/DB_File/DB_File.bs chmod 644 blib/arch/auto/DB_File/DB_File.bs /usr/bin/make -- OK Running make test PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl5/5.6.1/i686-linux -I/usr/local/lib/perl5/5.6.1 -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/db-btree..Can't load 'blib/arch/auto/DB_File/DB_File.so' for module DB_File: blib/arch/auto/DB_File/DB_File.so: undefined symbol: db_version at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 206. at t/db-btree.t line 23 Compilation failed in require at t/db-btree.t line 23. BEGIN failed--compilation aborted at t/db-btree.t line 23. t/db-btree..dubious Test returned status 255 (wstat 65280, 0xff00) t/db-hash...Can't load 'blib/arch/auto/DB_File/DB_File.so' for module DB_File: blib/arch/auto/DB_File/DB_File.so: undefined symbol: db_version at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 206. at t/db-hash.t line 23 Compilation failed in require at t/db-hash.t line 23. BEGIN failed--compilation aborted at t/db-hash.t line 23. t/db-hash...dubious Test returned status 255 (wstat 65280, 0xff00) t/db-recno..Can't load 'blib/arch/auto/DB_File/DB_File.so' for module DB_File: blib/arch/auto/DB_File/DB_File.so: undefined symbol: db_version at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 206. at t/db-recno.t line 23 Compilation failed in require at t/db-recno.t line 23. BEGIN failed--compilation aborted at t/db-recno.t line 23. t/db-recno..dubious Test returned status 255 (wstat 65280, 0xff00) FAILED--3 test scripts could be run, alas--no output ever seen make: *** [test_dynamic] Error 2 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force -- James McKim, President ISRG, Inc. V: (603) 497-3015 F: (603) 497-2599 http://www.isrginc.com Strategic use of information
RE: Problem With DB_File Installation On Red-Hat Linux 7.1 [OT]
That rings a bell. I think that the problem was that a secondary required file for the db.h for one of the versions db3 I believe is not a part of the RedHat install and that relinking the db.h file didn't help. It was at that point that I went to sleepcat.com to get the complete kit and installed from there. -Original Message- From: Nicholas Studt [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 9:32 AM To: Joe Breeden Cc: [EMAIL PROTECTED] Subject: Re: Problem With DB_File Installation On Red-Hat Linux 7.1 [OT] Joe Breeden wrote [ 2002/03/14 at 09:15:44 ] It has been a few weeks since I went through this and I have seen a squirrel or two since then and it was a bad experience so I have tried to block the memories of the awful awful day. I hope this helps, but I doubt it will. Good luck. A much easier fix specfically for Redhat 7.1 is to correctly link /usr/include/db.h to the same version of the /lib that DB_File is picking up. Redhat has versions 1, 2, and 3 of Berkeley db installed to support all of the applications. If you relink db.h, generally pointing it to db2/db.h ( though it may be db3/db.h or db1/db.h depending on the rest of the stuff you have installed ) will make DB_file happy. -Original Message- From: James McKim [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 9:01 AM To: [EMAIL PROTECTED] Subject: Problem With DB_File Installation On Red-Hat Linux 7.1 I'm trying to install DB_File on our Red-Hat Linux. 7.1 box and am getting an error about having 2 versions of BerkeleyDB installed. The log of the installation follows. Any help would be appreciated. | nicholas l studt [EMAIL PROTECTED] | GPG: 0EBE 38F2 342C A857 E85B 2472 B85E C538 E1E0 8808 `---
RE: Site Host Providers that Support mod_perl?
I use a small ISP in Cookeville to co-locate my equipment. They charge $79.00 per month for co-location charges. It is a no-frills setup, so you should provide your own UPS as they do not have power generators. They have been in business since 1995 and I don't see them going away any time soon. I wouldn't recommend putting a machine that is going to stream a lot data, but something to do a reasonable amount of ecommerce/data serving should ok for their bandwidth ( around 6Mbps with about 25 hosted servers and 300/400 dialup lines in the facility where the server would be co-located). If you, or anyone, contact them, please mention that I sent you. Thanks, Joe Breeden -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 10:35 AM To: [EMAIL PROTECTED] Subject: Re: Site Host Providers that Support mod_perl? I thought I had posted to this thread yesterday but looking back I don't see that it showed up, so I'll try again. :) I'm also looking for good mod_perl-supporting ISPs. Recently I went through the list on the web site, and either the links were broken, or the sites made no mention of supporting mod_perl. The best I've managed to find on my own is an ISP that starts supporting it at the $250/month level! Yikes. =) The inaccuracy of the list doesn't surprise me since the ISP world has experienced so much turnover and turmoil in the last couple of years. I'd be willing to compile a list of ISPs that you all know about and/or use, and forward that on to the web site maintainer. I know one option is to run your own mod-perl enabled apache but I imagine that a lot of ISPs would get pretty upset about you running servers (especially ones that love memory) on non-privileged ports, if they even allow connections to those ports in the first place. My ideal setup would be to be able to colocate one of my servers and just use the ISP's bandwidth, but those plans are all pretty pricey. So, I'd really like to have a good ISP that supports mod_perl that I can afford because I'd enjoy being able to play around and create sites that use mod_perl outside of work. Of course, I can do it at home, but it's not the best place to host a web app, it'd have an audience of one. =) Thanks, Fran David Simcik wrote: Alright, I'm a total mod_perl newbie and would like to find a host for my personal site that allows me to develop mod_perl scripts. First off, I'm assuming that there is no way to install mod_perl on my current provider due to (obvious) access privilige restrictions to Apache? Secondly, the obvious question here, whom would you folks recommend for hosting services, assuming the afforementioned? Thanks! David
RE: Site Host Providers that Support mod_perl?
I forgot their URL for those interested ( http://www.multipro.com/hosting.html ). -Original Message- From: Joe Breeden Sent: Thursday, March 07, 2002 10:39 AM To: Fran Fabrizio; [EMAIL PROTECTED] Subject: RE: Site Host Providers that Support mod_perl? I use a small ISP in Cookeville to co-locate my equipment. They charge $79.00 per month for co-location charges. It is a no-frills setup, so you should provide your own UPS as they do not have power generators. They have been in business since 1995 and I don't see them going away any time soon. I wouldn't recommend putting a machine that is going to stream a lot data, but something to do a reasonable amount of ecommerce/data serving should ok for their bandwidth ( around 6Mbps with about 25 hosted servers and 300/400 dialup lines in the facility where the server would be co-located). If you, or anyone, contact them, please mention that I sent you. Thanks, Joe Breeden -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 10:35 AM To: [EMAIL PROTECTED] Subject: Re: Site Host Providers that Support mod_perl? I thought I had posted to this thread yesterday but looking back I don't see that it showed up, so I'll try again. :) I'm also looking for good mod_perl-supporting ISPs. Recently I went through the list on the web site, and either the links were broken, or the sites made no mention of supporting mod_perl. The best I've managed to find on my own is an ISP that starts supporting it at the $250/month level! Yikes. =) The inaccuracy of the list doesn't surprise me since the ISP world has experienced so much turnover and turmoil in the last couple of years. I'd be willing to compile a list of ISPs that you all know about and/or use, and forward that on to the web site maintainer. I know one option is to run your own mod-perl enabled apache but I imagine that a lot of ISPs would get pretty upset about you running servers (especially ones that love memory) on non-privileged ports, if they even allow connections to those ports in the first place. My ideal setup would be to be able to colocate one of my servers and just use the ISP's bandwidth, but those plans are all pretty pricey. So, I'd really like to have a good ISP that supports mod_perl that I can afford because I'd enjoy being able to play around and create sites that use mod_perl outside of work. Of course, I can do it at home, but it's not the best place to host a web app, it'd have an audience of one. =) Thanks, Fran David Simcik wrote: Alright, I'm a total mod_perl newbie and would like to find a host for my personal site that allows me to develop mod_perl scripts. First off, I'm assuming that there is no way to install mod_perl on my current provider due to (obvious) access privilige restrictions to Apache? Secondly, the obvious question here, whom would you folks recommend for hosting services, assuming the afforementioned? Thanks! David
RE: webmail for mod_perl?
We use a combination of Mail::IMAPClient and MIME::Lite. You can look at http://howtos.eoutfitters.net/email for a description of our email servers. The mod_perl IMAP client handler has not been completed enough to release to the community, but once it is ready I put an announcement here. -Original Message- From: will trillich [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 28, 2002 5:49 PM To: [EMAIL PROTECTED] Subject: webmail for mod_perl? is there a sane implementation of webmail-style mod_perl modules for apache? we're looking to offer email access online through apache/mod_perl similar to what folks get at yahoo/egroups -- and we're hoping to find some mod_perl code that'll hook into pop/imap email servers. (and we're hoping to avoid loading php into ram.) i saw a thread in the archives (begun on Wed, 12 Dec 2001 by Medi Montaseri) but most of the suggestions seemed to point to php. we're hoping to stick with mod_perl. :) rtfm welcome if you specify which fm to r. :) thanks... --thanks! -- Legalize Liberty. [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
RE: New mod_perl name was [Re: New mod_perl Logo]
I like Monkey Butter v1.0.. On a serious note, I work in a predominately MS shop - of 25 developers me and one other are the only Perl developers with 3 more doing some combination of Java,C++, and C. I would suggest that anyone looking to make a case for 'Perl in the Enterprise' should look at the P5EE project ( http://p5ee.perl.org). From that site - The mission of the P5EE initiative is to promote the development, deployment, and acceptance of Enterprise Systems written in Perl. It has been my experience that results count, unless you are dealing with pointy-headed bosses. If that is the case, you application should spit gold bricks out of the floppy drive and it wouldn't matter. If you're looking for a name to justify Perl in Enterprise then I think the P5EE project and name is as good as any. Joe -Original Message- From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 7:20 PM To: [EMAIL PROTECTED] Subject: New mod_perl name was [Re: New mod_perl Logo] how about Everest? Niagara? Multiphase? Slipstream? DigiServer? Pointillion? Web Mammoth? SharpWeb? Web Enterprise? EnterWeb? Ged Haywood wrote: Hi there, On Tue, 29 Jan 2002, Chris Thompson wrote: mod_perl is a lousy name. [snip] mod_perl needs a name. Something marketable, something catchy. How about BigFoot? 73, Ged. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
RE: [OT] Re: New mod_perl Logo
The last time I looked the Yeti is Himalayan and Nessie is from Scotland. -Original Message- From: Stephen Reppucci [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 9:16 AM To: Ron Savage Cc: mod_perl Subject: [OT] Re: New mod_perl Logo All right -- I know I should just silently delete this, and let it go, but it's like a bad traffic accident, I just have to sneak a look. In exactly what way do you connote American-style out of any of those names? The fact that Big Foot is a mythical being often associated with the US northwest? (I think the Canadians talk about Big Foot too...) And racist?? Come on, that's certainly a reach... When in doubt, accuse others of being provincial, and act damn indignant. Curse their nationality too... Steve Reppucci On Wed, 30 Jan 2002, Ron Savage wrote: Jeezus you guys. All these American-style names are verging on the racist. This is world-wide code, not f---ing American-wide code. Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Wednesday, January 30, 2002 12:48 PM Subject: Re: New mod_perl Logo In a message dated 30-Jan-02 12:50:50 AM GMT Standard Time, [EMAIL PROTECTED] writes: How about BigFoot? Probably not the best for a server application. Might make one think of the footprint involved ... and isn't one of the major reasons to moving to mod_perl to reduce the overhead and footprint of the server? Now Yetti no conotation there. Or Swamp Beast, Sasquatch, or possibly even the local favorite Nessie (I'd love to see Ora get a picture of her on the next book!) -Chris -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
RE: [modperl site design challenge] and the winner is...
All that makes it really easy for someone new to feel comfortable. And isn't that what the mod_perl site should do? It would be nice to see license info, too, as someone new might want to be clear on that right away, too. You can also quickly see a list of supported modules. This shows that it's easy to extend, but also allows someone to see that it can do the thing *they* might be interested in. Sure, perl has CPAN, but I think it would be good to show a list of commonly used modules for mod_perl, and what they do, in a simple list. If someone is just learning about mod_perl (or php) the list doesn't need to be that big, as their needs will be reasonably basic. The list could give the module authors a chance to write a paragraphs describing what the module does in 50 words or less to new users can get an idea without have to wade into the CPAN pool. crazy idea Maybe as a community (of programmers not designers) we could hire a professional designer to help develop our brand. Cool web site. Some print ads in the trades. What's a small amount in dues to the Association of Mod_perl Programmers compared to increase of mod_perl work overall? /crazy idea I'm all for this. I use mod_perl on a daily basis, but either due to lack of time or lack of knowledge or other reasons I don't get to give back to the community as much as I would like. This is a way for me and others in a situation similar to mine to give back to mod_perl.
OT RE: load balancing on apache by IP CHAINING
I don't know how many of you read SysAdmin (http://www.samag.com), but there is an interesting article on running IPChains at runlevel 0. --Joe Breeden What to do... if you get a phone call from Mars: Speak slowly and be sure to enunciate your words properly. Limit your vocabulary to simple words. Try to determine if you are speaking to someone in a leadership capacity, or an ordinary citizen. if he, she or it doesn't speak English? Hang up. There's no sense in trying to learn Martian over the phone. If your Martian really had something important to say to you, he, she or it would have taken the trouble to learn the language before calling. if you get a phone call from Jupiter? Explain to your caller, politely but firmly, that being from Jupiter, he, she or it is not life as we know it. Try to terminate the conversation as soon as possible. It will not profit you, and the charges may have been reversed. -Original Message- From: David Young [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 16, 2001 10:45 AM To: [EMAIL PROTECTED] Subject: Re: load balancing on apache by IP CHAINING Servlet chaining is what the Java web server will do, and it has nothing to do with load balancing (that I can think of). ipchains is the command to enable firewall/packet filter/packet masquerading capability in linux. I would suppose that it can be used to round-robin requests or something, but I don't know how to set that up. From: Medi Montaseri [EMAIL PROTECTED] Date: Sat, 15 Dec 2001 20:57:19 -0800 (PST) To: Anand R [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: load balancing on apache by IP CHAINING I'm confused'IP chainging' as the name says is at the IP (or Network) layer, what does that have to do with Apache or any HTTP server at the application level. I think any such IP based load balancing technologies are inherently unaware of the total system issues and are simply making a jugdment based on the IP level or perhaps a specific protocol on top of IP to route the next packet (or next session). Having said that a Perl HTTP would/could benefit from it just as well... On Sat, 15 Dec 2001, Anand R wrote: IP chaining can be done in Java Webserver, How to do it in Apache Webserver. Please let the Ring know this, Thanks in advance, Regards, Anand - Original Message - From: Derek Jones To: Hemant Singh ; [EMAIL PROTECTED] Cc: Derek G Jones Sent: Friday, December 14, 2001 7:29 PM Subject: RE: load balancing on apache Hi all, You can do load balancing using ipchains as well. Can't remember the program name offhand, but if I have time I'll look it up and let the list know. Only works if your servers are Linux of course. Kind regards Derek. -- Derek Jones 1051, Bollinger Road, Tel:717 359 8817 Littlestown, Mobile: 717 977 4556PA, 17340, USA Email: [EMAIL PROTECTED] AIM: scunacc -- -- --- Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems Engineer HTTP://www.CyberShell.com CyberShell Engineering -- ---
RE: Cookie authentication
Thanks David. It hadn't dawned on me to do the cookie storing/retrieving over SSL - sometimes I need to be hit over the head with a sledgehammer to see the obvious. Without some sort of secure mechanism to transport the cookie between the browser and app all the app can be assured of is that the cookie is valid. The app cannot be 100% certain that the cookie being sent is sent by the real owner of the cookie. Generally, I would say that most applications could use any of the proposals floated on the list yesterday and today and not worry about client sessions being hijacked. Of course, if a session is hijacked - how much damage is done is a question the developer needs to ask themselves. If the risks are acceptable then what is in the Eagle book and has been discussed is OK. If the risks are not acceptable then what David suggests is the way to go. And thanks to everyone who posted. --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: David Young [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:30 PM To: [EMAIL PROTECTED] Subject: Re: Cookie authentication I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT. The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. From: Perrin Harkins [EMAIL PROTECTED] Date: Thu, 15 Nov 2001 18:40:03 -0500 To: Joe Breeden [EMAIL PROTECTED], mod_perl List [EMAIL PROTECTED] Subject: Re: Cookie authentication Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
RE: Doing Authorization using mod_perl from a programmers perspective
The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
RE: [challenge] new mod_perl site
I disagree with you both. --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 7:56 AM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: [challenge] new mod_perl site -Original Message- From: Robin Berjon [mailto:[EMAIL PROTECTED]] there have been several prior fits of new website creation threads on this list. And it always seems to bring out the worst out of this list (remember the first time, when someone said Stas was a nazi for trying to make the site better ?). This thread hasn't gotten into the worst bits yet. Please, lets try to keep it as polite as possible, even when there's disagreement. I disagree. :-P _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: Cookie authentication
Before I read an article about the European Union POV of cookies I hadn't really thought of myself as someone who would violate basic human rights. I guess this goes to show that one has to be ever vigilant in today's society. The resolution banning cookies did not pass the EU Parliament, this time. A ban on unsolicited SMS messages like those sent via a cell phone was approved (http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/index.html) . We use cookies to track session state here and have had no complaints. I don't think it is wrong to require the use of cookies. Of course to make everyone happy you could backup cookies with some sort of non-cookie based state management, like a URL encoded sessionid or a hidden form field passed in every page. Like everything, your mileage will vary with any implementation you choose to use. --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Andrew Ho [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 2:17 PM To: Charles Day Cc: John Michael; mod_perl List Subject: Re: Cookie authentication Hello, CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Not those clever European governmental folks, though. http://www.vnunet.com/News/107416 http://news.zdnet.co.uk/story/0,,t269-s2099128,00.html http://news.bbc.co.uk/hi/english/sci/tech/newsid_1653000/1653907.stm http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/ Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
RE: Cookie authentication
Here we insert a session id on all requests, with Apache::Session whether the request is for a static or dynamic page and have a TransHandler to strip the session id and insert it into %ENV which seems to work for us. With this approach we don't necessarily need cookies, but verifying if a user is who the session was originally assigned to without a cookie is really impossible. At least to me with the limited amount of brain time I have put into it. Using some algorithm consisting of the end-users IP and some random number is OK until users behind the same NAT device try to steal each others session. Using the cookie is a way to verify that a user is the owner of the session id. I hope this doesn't sound like the ramblings of a mad man, but in general I think SESSION cookies are ok and you should feel ok using them. I hope this helps a little. --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:25 PM To: mod_perl List Subject: Re: Cookie authentication On 15 Nov 2001, at 12:16, Andrew Ho wrote: CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. http://perl.apache.org/guide/modules.html#Apache_Session_Maint ain_sessi I used Apache::Session and HTML::Template to embed the session_id in the url in a recent job site.I planned this before I built the site (all templates built according to the plan :). No problems there. There were no static pages. I find cookies are used when one has a site static/dynamic pages. How do you keep a user if they click to a static page? I don't know. But one should always check if a user has cookies turned on. I recall an internal site I did for FedEx a few years back and I used cookies for it as it was before my mod_perl use. Well it turned out that the vice-president had cookies turned off. He was not a customer we wanted to ignore:) Peter A government that robs Peter to pay Paul can always depend upon the support of Paul. -- George Bernard Shaw
RE: Doing Authorization using mod_perl from a programmers perspective
How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: fliptop [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:50 PM To: Jon Robison Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround?
RE: Cookie authentication
See it always pays to read the Eagle book several times - in this case pages 213-218. Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Thanks for the help, --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:52 PM To: Joe Breeden; mod_perl List Subject: Re: Cookie authentication Here we insert a session id on all requests, with Apache::Session whether the request is for a static or dynamic page and have a TransHandler to strip the session id and insert it into %ENV which seems to work for us. With this approach we don't necessarily need cookies, but verifying if a user is who the session was originally assigned to without a cookie is really impossible. At least to me with the limited amount of brain time I have put into it. Using some algorithm consisting of the end-users IP and some random number is OK until users behind the same NAT device try to steal each others session. Using the cookie is a way to verify that a user is the owner of the session id. Cookies are very easy to fake and modify on the client side. If you want to verify that a user is returning a session ID you sent him without modifying it you should use a MAC, like the ticket access stuff in the Eagle book. - Perrin
RE: [Templates] Re: Excellent article on Apache/mod_perl at eToys
I work in a predominately M$ shop. AS a matter of fact, I am one of only two Perl/mod_perl programmers in a development department with 25 other programmers. Sometimes it feels like we are working in a vacuum. This list and articles like the eToys article along with the overwhelmingly superior performance of mod_perl/Apache vs. either M$ IIS/ASP or M$ IIS/ColdFusion are what make, at least for me, doing what I do for a living where I do it possible. If it weren't for our success with mod_perl/Apache I really believe that this project would have been converted to ColdFusion a long time ago. Anecdotal evidence like the eToys article only add to the growing body of evidence that what we do with mod_perl is really the best of the available alternatives. Not only doe Perrin deserve a pat on the back for his article, but everyone who promotes the use of these technologies should feel good about what themselves. --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Drew Taylor [mailto:[EMAIL PROTECTED]] Sent: Friday, October 19, 2001 8:59 AM To: Perrin Harkins; mod_perl List Cc: Template Toolkit List Subject: Re: [Templates] Re: Excellent article on Apache/mod_perl at eToys What I found most interesting was the detail of the extensive caching which was implemented to survive the seasonal rush. I look forward to working on a project one day that is big enough to warrant such a system. All in all, a most excellent and informative read. Thanks again for everything you've personally done for the community! I look forward to seeing those graphics. :-) At 09:49 AM 10/19/01 -0400, Perrin Harkins wrote: Thanks to all for the kind words. This article actually went up a little bit before it was supposed to, and there should be a revision going up soon with some grammatical fixes and a set of graphics to illustrate parts of it. I'll post a follow-up when that happens in case anyone wants to go and look at the pretty pictures. While we're on the subject, thanks to everyone who contributed to the many open source projects that we used. We couldn't have done it without you. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
RE: Programmer Wanted
Sounds like morning talk radio to me. 'And now Ernie the Eye in the Sky with traffic, but first YOU to can be RICH. With our patented money making scheme the money literally prints itself.' --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Robert Landrum [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 3:50 PM To: BuildReferrals.com; [EMAIL PROTECTED] Subject: Re: Programmer Wanted At 10:43 AM -0700 10/12/01, BuildReferrals.com wrote: Hello, My name is James Ventrillo, the webmaster of BuildReferrals.com and CompanionBar.com. I am looking for a programmer to be part of my company. We have a staff of 8 and we desperately need an additional programmer. Over the next few weeks, we need extensive programming performed on our websites. We will pay an hourly rate, dependent on your experience. Is it just me, or do all these multi-level-marketers sound the same? Whether they're writing spam or job postings, it still comes out sounding cheezy... Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
RE: Knowing if a apache server is compiled with mod_perl
Or you could do: perl -nle 'print $_\n if m/mod_perl/' /path/to/error_log where /path/to/error_log is the file pointed at by the ErrorLog directive in you httpd.conf file. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Steven Lembark [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 3:07 AM To: [EMAIL PROTECTED] Subject: Re: Knowing if a apache server is compiled with mod_perl -- Mat [EMAIL PROTECTED] Hi everyone, I'd like to know if there is a simple way to find if an apache server is compiled with mod_perl and with which version. My aim is to write a script which compile mod_perl if it is not installed. For the moment I've found only two ways, launch the actual server and telnet it to parse the server signature. But it has the disadvantages of having the Apache server running and the server signature on.The other way would be to get the return of httpd -v, but I won't have the version and I think this won't work if the module is compiled in dso. So is it possible from the Apache binary to check mod_perl ? If the server is compiled w/ mod_info check that for mod_perl. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
RE: Can't build (was Re: Apache.pm fails to load...)
Maybe you could build mod_perl as a DSO with APXS. That way you could build it after the apache/mod_ssl is built and working. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: U n d e r a c h i e v e r [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 8:36 AM To: Philippe M . Chiasson; Stas Bekman; [EMAIL PROTECTED] Subject: Re: Can't build (was Re: Apache.pm fails to load...) a search for libssl reveals: find / -name libssl.so.0 /usr/local/ssl/lib/libssl.so.0 what do you see when you do: ls -l /usr/local/ssl/lib/libssl.so.0 -rw-r--r-- 1 bin bin 844468 Oct 29 2000 /usr/local/ssl/lib/libssl.so.0 so mine's not a symlink nor an executable... or your /etc/ld.so.conf doesn't have /usr/local/ssl/lib. indeed, i do not /have/ an ld.so.conf ... the closest match seems to be an ld.so.1 in /etc/lib, but that's a binary :) i also don't have an ldconfig executable ssh has been compiled and happily running against this version of openssl for a couple of weeks. I've re-made and re-installed openssl (windows habits die hard) before posting this message, but the whole build still fails in exactly the same way as previously reported. when i build apache directly (that is to say running configure and make in the ./apache_ directory, as opposed to in mod_perl) it does not stall on a missing ssl library, and happily compiles with mod_ssl. = u n d e r a c h i e v e r (and proud) [EMAIL PROTECTED] __ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/
RE: Knowing if a apache server is compiled with mod_perl
You could also do something like: grep 'Apache' /path/to/error_log --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Mark Schmick [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 2:05 PM To: Adam Worrall; Mat Cc: [EMAIL PROTECTED] Subject: Re: Knowing if a apache server is compiled with mod_perl Adam's technique below doesn't work for me, but this does (assuming you have LWP installed): sh HEAD -de http://server_you're_interested_in|grep Server: -Mark At 05:20 PM 9/17/2001 +0100, Adam Worrall wrote: Mat == Mat [EMAIL PROTECTED] writes: Mat Hi everyone, I'd like to know if there is a simple way to find Mat if an apache server is compiled with mod_perl and with which Mat version. This does it for me: $ strings /some/httpd | grep 'mod_perl\/' The 'strings' command works under Linux and Solaris, I think it's fairly standard ... and handy :) - Adam
RE: my()
That is the way to do it. It can get a little confusing at first, but once
you get used to doing things that way it will become 2nd nature.
--Joe Breeden
--
Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com)
-Original Message-
From: swade [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 2:53 PM
To: [EMAIL PROTECTED]
Subject: my()
Hi, I'm completly confused by this my(X) not being available
outside of a
subroutine, I've read everything but must not still get
itis this an
approriate solution? it makes @countries available...
my @countries; - solution?
my $sql = select distinct country from geo;
my $sth = $match::dbh-prepare( $sql );
$sth-execute;
while ( (my $country_db) = $sth-fetchrow )
{
push(@countries,$country_db);
}
I've read the solutions but dang if they don't seem like
rocket science for
something simple. Like suppose I wanted to do this
if ($var eq whatever) {
$sql = select.yada;
} else {
$sql=somthing else...;
}
dbi $sql stuff
In this case $sql wouldn't be available and use strict would
complain. So if
I did this:
my ($sql);
ifas above
Is that an appropiate solution?
Thanks for _any_ info anyone can provide,
shawn
[OT] Inspired by closing comments from the UBB thread.
All, In his closing comments about UBB Kyle Dawkins made a statement that got me wondering. He said there's SQL embedded all throughout the Perl everywhere (who does this?! oh my god, are they on crack?). This comment got me wondering about alternatives to embedding SQL in to the code of a program. Alternatives I see are to use stored procedures which would limit one to using a certain DB server (or to be proficient in many servers and write stored procedures for all server flavors which would mean one is a very busy Perl and SQL guru) or possibly storing the embedded SQL in some sort of external file structure accessible via storable, XML::Simple or some other means. It would be interesting to know how other people have solved that problem. Currently, we are essentially using embedded SQL in our apps. Thanks in advance. --Joe Breeden --
RE: [OT] Inspired by closing comments from the UBB thread.
Woooie!?!
I didn't expect the firestorm this post would generate. From what I hear
people are either embedding SQL or writing their own utility module to
essentially do something along the line of:
$s-StartDBI ( DSN = 'somedsn_pointer') ;
eval {
$s-SelectSQL ( NAME = 'sql_select',
TABLE = 'sometable',
FIELDS = ['field1', 'field2', 'field3'],
WHERE = 'field1=?',
VALUES = $some_value_for_field1);
while ( my $return = $s-SQLGetArray( NAME = 'sql_select')) {
#do something $return - maybe complete a template object?
}
};
$s-EndDBI ( DSN = 'somedsn_pointer', QUERIES = 'sql_select', RESULTS =
$@);
Where the different calls do the things hinted at in their name (i.e.
StartDBI opens the DSN and connects to the database in question, SelectSQL
would prepare the SQL select statement and execute it via DBI). This allows
the us to pass a native Perl structure which is reformatted to work with
DBI. We also get back scalars, arrays, or hashes that are easy to work with.
This is what we do here where I work. I still consider this embedded SQL
because a change to the table or even to the server could cause the program
to break in a lot of places. I think what I had in mind was some way to put
this type of processing into a layer where all the SQL related items are
essentially in a template file somewhere maybe a SQL::Template type thingy.
If this is something that people feel would be a worthwhile endeavor, let me
know and maybe when there's have a little free time in the Fall one could
write a CPAN module that has this functionality.
We had the conversation awhile back about adding redundant and unnecessary
crap to CPAN and I want to make sure something like this would be a good
thing or not.
Thanks,
--Joe Breeden
--
RE: [OT] Inspired by closing comments from the UBB thread.
I have to agree here. Is this just a hash of SQL statements or is there more to it than that? --Joe Breeden -- -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 01, 2001 1:29 PM To: Matt Sergeant Cc: [EMAIL PROTECTED] Subject: Re: [OT] Inspired by closing comments from the UBB thread. http://axkit.org/docs/presentations/tpc2001/anydbd.axp Is this basically a hash of SQL statements, indexed by DBD type? Or is there something more that I'm missing? (I should have gone to your TPC talk...)
RE: [OT] Inspired by closing comments from the UBB thread.
Nick,
Thanks for the comments. Actually, we use something like the example code
now and can do select from multiple tables (TABLES = ['table1', 'table2',
'table2 as someAlias']), can do inner and outer joins, order by clauses,
binding values, just about anything we want with straight SQL. Essentially,
our Database.pm delivers $dbh and the modules create their own $sth so what
we do and what you do probably isn't very far apart.
I was shocked at how much response the thread generated so I thought that
maybe a solution was warranted and just want to give something back. I still
think the solution I've outlined is not the best, but it may a good solution
for a lot of people.
Thanks everyone for the comments. I can see from the responses this
something everyone deals with everyday and that I not alone out here
wondering if my solution is the right one or not.
--Joe Breeden
--
Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com)
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 01, 2001 4:15 PM
To: Joe Breeden
Cc: [EMAIL PROTECTED]
Subject: RE: [OT] Inspired by closing comments from the UBB thread.
Since you asked, my opinion is that what you describe would not be
useful. Primarily for the reason pointed out already by a
number of people
-- lack of flexibility. Most, if not all, database servers
accept highly
customizable performance params to a query, and most even moderately
evolved applications make use of SQL queries that are significantly
more complex than a single-where-clause select.
At ValueClick we built a wrapper module (DB.pm :) that
delivered a $dbh
into the API, handling everything up to that point with minimal
fuss. From that point on, some standard things were collected
in a utility
class, but most modules created their own $sth, usually with bind
variables, with SQL statements nicely formatted in the source
using a here
doc ... it was highly manageable and functional, and most of
all it was
flexible. Not all applications are fast-developing, but my
experience is
that it pays to develop as if yours were ... rapid access to
tweak the SQL
fetching data into the application is very desirable, IMHO.
The point is not that you can't abstract it all away as you
show in your
code below, it's that by the time you have covered all eventualities
(sorts, groups, selects from multiple tables, et al.), your
interface is
so complicated you are basically paraphrasing the SQL in some
new language
of your invention. And that, if I am not mistaken, is the
purpose of SQL
in the first place!
There is such a thing as over-abstraction, IMHO, and having
played with
this a lot, I have found that this type of effort would be such.
Hope this helps,
~~~
Nick Tonkin
On Wed, 1 Aug 2001, Joe Breeden wrote:
Woooie!?!
I didn't expect the firestorm this post would generate.
From what I hear
people are either embedding SQL or writing their own
utility module to
essentially do something along the line of:
$s-StartDBI ( DSN = 'somedsn_pointer') ;
eval {
$s-SelectSQL ( NAME = 'sql_select',
TABLE = 'sometable',
FIELDS = ['field1', 'field2',
'field3'],
WHERE = 'field1=?',
VALUES = $some_value_for_field1);
while ( my $return = $s-SQLGetArray( NAME = 'sql_select')) {
#do something $return - maybe complete a
template object?
}
};
$s-EndDBI ( DSN = 'somedsn_pointer', QUERIES =
'sql_select', RESULTS =
$@);
Where the different calls do the things hinted at in their
name (i.e.
StartDBI opens the DSN and connects to the database in
question, SelectSQL
would prepare the SQL select statement and execute it via
DBI). This allows
the us to pass a native Perl structure which is reformatted
to work with
DBI. We also get back scalars, arrays, or hashes that are
easy to work with.
This is what we do here where I work. I still consider this
embedded SQL
because a change to the table or even to the server could
cause the program
to break in a lot of places. I think what I had in mind was
some way to put
this type of processing into a layer where all the SQL
related items are
essentially in a template file somewhere maybe a
SQL::Template type thingy.
If this is something that people feel would be a worthwhile
endeavor, let me
know and maybe when there's have a little free time in the
Fall one could
write a CPAN module that has this functionality.
We had the conversation awhile back about adding redundant
and unnecessary
crap to CPAN and I want to make sure something like this
would be a good
thing or not.
Thanks,
--Joe Breeden
--
RE: Porting CGI scripts help needed
You might try adding use lib '/path/to/global.pm'; to you startup.pl. (Without the s of course) Good luck. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Bryan Coon [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 26, 2001 6:01 PM To: '[EMAIL PROTECTED]' Subject: Porting CGI scripts help needed Hi, I have (happily) compiled and configured Apache with mod_perl, mod_ssl, mod_php and DSO. Whee! Now I am working on porting my scripts over... I have always used strict and perl -w, so for the most part, I think I can just pop my cgis in the /perl directory as Ive defined it in httpd.conf. However, I had to implement some trickery for my scripts a while ago via require/use and am having problems getting my scripts to work. Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: --- use strict; ## Local parameters our $cgibin = http://path/cgi-bin;; our $htmldir = /apache/htdocs our $a = /some/path; our $b = /some/other/path; ## Common modules use CGI qw(:standard); use DBI; use Data::Table; ## Custom stuff require /path/to/custom/script1.pl; require /path/to/custom/script2.pl; 1; --- The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. What am I doing wrong with this? Any ideas? Thanks! Bryan
RE: BOF?
Yeah, I'll be there on Sunday in the afternoon. We could go geek and all wear some sort of Perl hat or t-shirt. But of course that is just a supposedly funny suggestion. Maybe I could wear my getpushed.com t-shirt, get real drunk and obnoxious and the mod_perl-ers could come and hang out with me. Of course, if that is the plan I would hope the mod_perl-ers would change affiliation to something else like VBscript rather than hanging out with a drunken Joe Breeden. At any rate, I look forward to meeting everyone there. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Robin Berjon [mailto:[EMAIL PROTECTED]] Sent: Monday, July 16, 2001 9:48 AM To: [EMAIL PROTECTED] Subject: Re: BOF? On Monday 16 July 2001 07:10, James G Smith wrote: Judging by where the hotel is, I think probably the hotel bar is going to be best. I arrive on Sunday. As do I. Just let me know where and when. I arrive on Sunday evening too, is there a good way to recognize a bunch of modperlians ? I've only ever seen two people on this list so if they aren't there I won't recognize anyone :) -- __ _ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com -- - Windows may be pretty. And easy. But it has no depth or soul. It's like the one-night stand of operating systems. You feel cheap after using it. -- Steph, in User Friendly
RE: detecting ssl
Looking at the port number still doesn't ensure that the request is a SSL
request. I believe the mention to looking at $ENV{HTTPS} is the best couse
as that is set when the connection is a SSL connection and not just a
connection to port 443.
--Joe Breeden
--
Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com)
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 8:50 AM
To: brian moseley
Cc: [EMAIL PROTECTED]
Subject: Re: detecting ssl
no need to do a lookup or rely on PerlSetupEnv On I
wouldn't think...
my $ssl = Apache::URI-parse($r)-scheme =~ m/^https/;
Or maybe just look at the port # of the request.
- Perrin
RE: API Design Question
Shawn, We have taken the approach here of a format like the on laid out below: (in startup.pl - use lib '/usr/local/apache/lib'; - add the directories to @INC) /usr/local/apache/lib/APP - where APP is the main name of our application. In this directory we will have perl modules that are shared by all the handlers that make up the application. Inside this directory we have a directory for our handlers - the handler would relate to the 'command=foo' part of your current call - like: /usr/local/apache/lib/APP/Command Inside the directory for the handler we have at least a Handler.pm which is reference in out perl.conf something (well exactly like): Location /command SetHandler perl-script PerlHandler APP::Command::Handler /Location Inside the Handler.pm perl module is a sub called handler that processed the requests made to that command. We also have a perl module for each action related to a command, like: List.pm - to process things related to a /command?action=list call. For out situation, this works well because it allows several developers to work on different parts of the same Command without stepping on each others toes, so to speak. Of course, this does add a level of complexity to project, that in the beginning was met with some resistance by long time perl programmers - myself included and I thought of the layout, but in practice it has let our team cut development times significantly. Of course a good versioning system will allow multiple users to access the same file and not cause problems, and we use CVS to provide version control. As with anything, you milage may vary with this method. I'm sure there are hidden pitfalls involved with this method, but for the timebeing it does seem to work for us. I hope this helps. Good Luck Joe Breeden -Original Message- From: Shawn Devlin [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 1:18 PM To: [EMAIL PROTECTED] Subject: Re: API Design Question Adam Worrall wrote: SD == Shawn Devlin [EMAIL PROTECTED] writes: SD My first thought is to break the API up so that there is a SD module per API call (there are some 70 calls in the API). My SD reasoning is that I can modify existing calls and add new ones SD without affecting everything else. Does this make sense or is it SD better to have the API as one large program as I have it now? I'd have thought you'be best to put the API in a large module, and then make calls to it from mod_perl handlers. You oculd even write a generic handler which chose which function to execute based on the arguments. Having a module per function may start to do your head in :) The bulk of the API is in 4 or 5 .pm files. My cgi script basically determines the call being made, vets the parameters, calls vaious functions in the .pm files, and then returns the result. The current format for the call is server.com/cgi-bin/api.pl?command=fooparm1=parm2= What I want to have is server.com/api/foo?parm1=parm2= The module that handles foo would check the parameters, make it's calls to the various internal functions, and then compose and send the results. What I like about this is I can add a new function without needing to disturb the existing code. Also, each function call is then self-contained. Currently, my existing API script is essentially a big switch statement. My concern is that each handler links the .pm files so with 50 or so functions I will have 50 or so copies of the various .pm files in memory. Yes - when some Perl in an Apache child process executes DBI::connect (which has been overridden by Apache::DBI), it first looks in a hash of existing connections before opening a new one. Good news ! Thanks for the conformation. Shawn
RE: Questions Concerning Large Web-Site
I like Writing Apache Modules with Perl and C from O'Reilly (ISBN: 1-56592-567-X). -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Ron Beck [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 2:42 PM To: John Armstrong Cc: '[EMAIL PROTECTED]' Subject: Re: Questions Concerning Large Web-Site Is there a good tutorial or book on the subject of constructing Perl modules? I too have done some of this and would like to create actual modules instead of required subroutines. Ron John Armstrong wrote: I'd convert each 'module' into a real Perl module( YourPackage::Search.pm etc ) and then configure it at the directory level. Location /search SetHandler perl-script PerlHandler YourPackageSpace::Search /Location Or you can just take your script and throw it into a single module's handler() routine : Location / SetHandler perl-script PerlHandler YourPackageSpace::YourNewModule /Location Your modules will be pre-compiled and your source is much more manageable in the future for other people involved in the project. I find it best to 'break' the boundary between CGI and ModPerl by generally _not_ writing '.pl' scripts and instead moving everything into pure modules. It just makes the conceptual jump between CGI and mod perl much easier for newbies who join the team. I'm sure it has performance and integration impacts that I am not to knowledgeable on though. John- On 6/11/01 10:28 AM, Purcell, Scott [EMAIL PROTECTED] wrote: Hello, I have a large asset-management system that is web-based. In the past I have always used cgi and perl. I need to rewrite it so that it works with mod-perl or PerlEx Anyway, I used to tie my site together with a main, and a ton of requires (which required pages of subroutines). I would use a hidden variable to do the navigation. So each time the user hit something, I directed them back to the main and used a hidden variable to go spawn a different subroutine. So it was basically a nested application. The site got large (a lot of perl code, over 20,000 lines), and it got slow because each user ended up recompiling the code for each submit. Lately as I am thinking about rebuilding the site, but not using a nested config, but just offering each page to be its own perl file. So when the user submits for a search, I just point them at the search.pl file. Sounds simple enough, but I work alone, and do not know how the world builds large sites. I was hoping to hear some simple input from people who have architected good, sound sites, and was hoping for some good feedback, or some old sample code that I can study and find out how the other half live. I hope this is not asking too much, Any input would be most helpful. Sincerely Scott Purcell
RE: Apache::Session / No-Cookie-Tracking
use Apache::MindReader; my $future = Apache::MindReader-new( no_mistakes = 1 ); $future-read_mind( no_info_whatsoever = 1 ); my $reliable_unknown_id = $future-track_user(); die Could not figure out user without knowing one single piece of information about them. Weird\n unless ( $reliable_unknown_id ); (Of course your mileage may vary) (For entertainment purposes only) Wink. Wink. Nudge. Nudge. Joe Breeden -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Apache::Session / No-Cookie-Tracking
Seems like the site in question is using either a hidden form element or a session cookie. I'm guessing that with the session being only valid as long as the browser window is open a session cookie is being used. The reason you don't see this in the Cookie directory for you particular browser is that these cookies are stored in the memory - they are not to be save after the browser session is over. I hope that helps. Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:29 AM To: '[EMAIL PROTECTED]' Subject: FW: Apache::Session / No-Cookie-Tracking Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Apache::Session / No-Cookie-Tracking
You may also want to store a hidden field in every form with a sesionid that is generated by you. Depending on how unique the number needs to be, we use either the number generated by mod_unique_id - potentially less reliable - (a part of the standard apache dist) or generate one with MD5 - generally more reliable. Joe -Original Message- From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:51 AM To: 'Ilya Martynov' Cc: '[EMAIL PROTECTED]' Subject: RE: Apache::Session / No-Cookie-Tracking The feeling of magic only lasts until you know how it's done, and I have seen the light. What happens is that they use a per-session cookie, so it doesn't appear in my temp folder. But, if per-session cookies are disabled, then it relies on the IP address. I guess that is better than just one method, but I think I may use the same method, but base the no-cookie method on both IP address AND HTTP_USER_AGENT to try to make things more unique. Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:35 AM To: Jonathan Hilgeman Subject: Re: Apache::Session / No-Cookie-Tracking JH Sure - I believe in magic, depending on your definition of it. I KNOW JH there's a 4th method, because I've seen it work. There is an e-commerce web JH site which uses an outside cart programmed in CGI (Perl?). The original web JH site passes no identifying marks such as the session ID through the URL or JH through the form's submit button to add an item to the cart. I know, because JH I designed and created the web site. JH [..skip..] Interesting. If you will say me url of your web site where you are using this outside cart probably I'll find how they do tracking. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Concepts of Unique Tracking
ASCEND SOAPBOX I agree with Alex (and it's not just because we work together). Companies have been doing the kind of data collecting Alex is talking about for years. As a matter of fact, some Cultural Anthropologists specialize in Corporate Anthropology (for a recent related news item see -http://www.cnn.com/2001/CAREER/dayonthejob/05/23/corp.anthropologist.idg/in dex.html ). Collecting anonymous information about users is something almost all websites do - I'm hesitant to say all, because I'm sure one website out there doesn't keep a usage log (i.e. /usr/local/apache/logs/access_log or /usr/local/apache/logs/error_log). It would be almost impossible to run a good website that changes based on user trends and preferences and not do some form of user tracking. Of course the real problem is when the website tries to link the collected data in someway to real people. Knowing that 15% of your users HTTP_REFERRER is www.porn.com is one thing, knowing that Persons X, Y, and Z came from www.porn.com and acting on that knowledge to send them information about the latest sale on leather underwear and selling their names to the porn_users mailing list is completely wrong. In my opinion, a good website has to track generalizations about user preferences so it can react to add to the user experience in positive ways. One way to do this to collect anonymous data about the things a user does on the site. This can be done and still protect a users privacy. DESCEND SOAPBOX Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Alex Porras Sent: Friday, May 25, 2001 2:38 PM To: '[EMAIL PROTECTED]' Subject: RE: Concepts of Unique Tracking Although I agree about privacy issues, I will keep it short by stating that there is a difference between identifying you as unique user 1309850825 (assuming no personally identifiable information is also collected) versus identifying you as Stephen Adkins. You can use the first method to collect aggregate information about what percentage of your users are accessing what parts of your website the most/least, so you could customize your website appropriately. That does not require me to know who everyone is, personally speaking. --Alex -Original Message- From: Stephen Adkins [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 1:14 PM To: Jonathan Hilgeman; '[EMAIL PROTECTED]' Subject: RE: Concepts of Unique Tracking How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
