Re: RFC: Exception::Handler
On Fri, 11 Jan 2002, Tatsuhiko Miyagawa wrote: > use Exception::Handler > MyException => \&my_handler, > AnotherException => \&another_handler, > __DEFAULT__ => \&default_handler; > > eval { MyException->throw }; # my_handler() > eval { AnotherException->throw; };# another_handler() > eval { YetAnotherException->throw; }; # another_handler() : hierarchical > eval { FooBarException->throw; }; # default_handler() I don't like this for the same reason I don't like $SIG{__DIE__} - it promotes action at a distance. In a 1000 line .pm file I *want* to have my exception catching mechanism next to my eval{} block. -- <:->Get a smart net
Re: formmail spammers
On Fri, 11 Jan 2002, Perrin Harkins wrote: > > I assume I'm not the only one seeing a rash of formmail spam lately. > > Is THAT what it is? I have a Yahoo mail account which someone has been > sending literally thousands of messages per day to, CC'ing lots of > people on every one, and they all appear to be from some kind of > compromised form mailer script. I'm open to any suggestions. http://www.spamassassin.org/ Without a doubt, the best anti-spam solution around. -- <:->Get a smart net
the trick of using $SIG{__DIE__} with eval {} disregarding the $^S value
This is an interesting approach to using $SIG{__DIE__} together with eval {} blocks, without relying on the value of $^S which sometimes goes broken. I guess we should add this "trick" to the guide. Original Message Subject: Re: [ID 20020107.001] $^S is sticky Date: Mon, 7 Jan 2002 15:15:58 -0500 From: Michael G Schwern <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> On Mon, Jan 07, 2002 at 02:52:02PM -0500, Christopher Masto wrote: > Is this supposed to happen? $^S breaks a lot. I found both 5.6.1 and 5.005_03 to have broken $^S, though for different reasons. I can't remember why 5.005_03's is broken. If you peek inside Test::Builder you'll find this: $SIG{__DIE__} = sub { # We don't want to muck with death in an eval, but $^S isn't # totally reliable. 5.005_03 and 5.6.1 both do the wrong thing # with it. Instead, we use caller. This also means it runs under # 5.004! my $in_eval = 0; for( my $stack = 1; my $sub = (CORE::caller($stack))[3]; $stack++ ) { $in_eval = 1 if $sub =~ /^\(eval\)/; } $Test_Died = 1 unless $in_eval; }; > chris@lion-around:~$ perl5.00503 -e '$SIG{__DIE__} = sub { die @_ if $^S; die "caught die: @_"; }; print "start: $^S\n"; eval { die "death in eval"; }; print "end: $^S\n"; die "death outside eval"' > start: 0 > end: 0 > caught die: death outside eval at -e line 1. > > chris@lion-around:~$ perl5.6.1 -e '$SIG{__DIE__} = sub { die @_ if $^S; die "caught die: @_"; }; print "start: $^S\n"; eval { die "death in eval"; }; print "end: $^S\n"; die "death outside eval"' > start: > end: 1 > death outside eval at -e line 1. > > In 5.6.1, the value of $^S seems to get stuck once it's been set. > This only happens if the $SIG{__DIE__} handler actually looks at it. t/op/magic.t appears to be the only thing which tests $^S, and it doesn't get $SIG{__DIE__} involved. bleadperl is back to: start: 0 end: 0 caught die: death outside eval at -e line 1. if modified a little, it shows its the correct behavior: $ bleadperl -e '$SIG{__DIE__} = sub { die @_ if $^S; die "caught die: @_"; }; print "start: $^S\n"; eval { die "death in eval"; }; print $@; print "end: $^S\n"; die "death outside eval"' start: 0 death in eval at -e line 1. end: 0 caught die: death outside eval at -e line 1. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One And God created Cat to be a companion to Adam. And Cat would not obey Adam. And when Adam gazed into Cat's eyes, he was reminded that he was not the supreme being. And Adam learned humility. -- http://www.catsarefrommars.com/creationist.htm -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: formmail spammers
> I assume I'm not the only one seeing a rash of formmail spam lately. Is THAT what it is? I have a Yahoo mail account which someone has been sending literally thousands of messages per day to, CC'ing lots of people on every one, and they all appear to be from some kind of compromised form mailer script. I'm open to any suggestions. - Perrin
formmail spammers
Hi all - I assume I'm not the only one seeing a rash of formmail spam lately. I don't have it on my system, but I get a handful of attempts at using it every day. This is the kind of thing I'm talking about: /cgi-bin/formmail.pl?[EMAIL PROTECTED],&subject=Your%20site%20is%20great!&[EMAIL PROTECTED]&=http://ivsoftware.com/cgi-bin/formmail.pl Is there anything out there along the lines of the anti- MSIISProbes/NIMDA/CodeRed modules that will stop this and report it up the chain? -- Mike Schienle Interactive Visuals, Inc. http://www.ivsoftware.com/
Re: Exception::Handler
On Fri, 11 Jan 2002, Jay Lawrence wrote: > For what it is worth - I would encourage you to check out the Error package > as well. > > Rather than: > > eval { }; > if ($@->isa('FooException')) { > # ... > } elsif ($@->isa('BarException')) { > # ... > } else { > # ... > } > > You would have: > try { > code; > } catch FooException with { > code for FooExceptions; > } catch BarException with { > code for BarExceptions; > } otherwise { > }; And the fun potential for memory leaks with nested closures. > And you can throw exceptions with details on the nature of the exception: > > throw FooException ( -text => "You foo'ed at line bar", -value => > $line ); You can do that without using Error.pm's try/catch stuff by simply using Error's exception objects or the Exception::Class provided exception objects. AFAICT, Tatsuhiko's module is designed to work with either of those types of objects transparently, but it provides an alternate mechanism for catching exceptions. And anything inspired by my Sig::PackageScoped module scares me, but its an interesting idea ;) -dave /*== www.urth.org we await the New Sun ==*/
RE: push_handlers
Makes sense, will look over the docs again. Thanks, > "Stathy Touloumis" <[EMAIL PROTECTED]> wrote: > >For some reason the call to 'push_handlers' does not seem to register the > >'handler' with mod_perl correctly when used in the code below. It seems > >that only a few initial requests will successfully be processed by this > >handler. It then just seems to be bypassed. It only works when the > >'push_handler' code is commented out and a Perl*Handler > directive is added > >to the apache conf file. Does anyone know why this is so? > > > >Here is a snippet of code which is read in at server startup through a > >'require' directive. > > > >Apache->push_handlers( > > PerlPostReadRequestHandler=> \&handler > >); > > > >sub handler { warn "Hello World\n"; } > > As far as I know, push_handlers only works the the current request -- > that is, the handlers pushed with it are cleared at the end of the > request. > > It would seem that doing this at startup sets up the handler which > then gets used by the children and cleared after the first request > they serve. This would give you the symptoms you're seeing (each > child called once, and then it disappears). Try running httpd -X to > see what happens. There's also probably something in the guide about > it.
Re: Exception::Handler
For what it is worth - I would encourage you to check out the Error package as well. Rather than: eval { }; if ($@->isa('FooException')) { # ... } elsif ($@->isa('BarException')) { # ... } else { # ... } You would have: try { code; } catch FooException with { code for FooExceptions; } catch BarException with { code for BarExceptions; } otherwise { }; And you can throw exceptions with details on the nature of the exception: throw FooException ( -text => "You foo'ed at line bar", -value => $line ); and in the try block: try { do foo; } catch FooException with { my $exception=shift; print "Uh oh, we have a problem with foo: " . $exception->text; }; Jay - Original Message - From: "Tatsuhiko Miyagawa" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Dave Rolsky" <[EMAIL PROTECTED]>; "Matt Sergeant" <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 8:07 AM Subject: RFC: Exception::Handler > Seeing through Dave Rolsky's Exception::Class and > Sig::PackageScoped has let me make the following module, called > Exception::Handler. > > In fact I rarely use $SIG{__DIE__} for exception handling, but the > concept of the module would be a bit interesting. Especially > > eval { }; > if ($@->isa('FooException')) { > # ... > } elsif ($@->isa('BarException')) { > # ... > } else { > # ... > } > > code like this can be greatly simplified. > > Any suggestions welcome, escpecially from gurus of exception, Matt > and Dave ;) See t/*.t for typical usage. > > http://bulknews.net/lib/archives/Exception-Handler-0.01.tar.gz > > NAME > Exception::Handler - Hierarchical exception handling > > SYNOPSIS > use Exception::Class > 'MyException', > 'AnotherException' => { isa => 'MyException' }, > 'YetAnotherException' => { isa => 'AnotherException' }, > 'FooBarException'; > > use Exception::Handler > MyException => \&my_handler, > AnotherException => \&another_handler, > __DEFAULT__ => \&default_handler; > > eval { MyException->throw }; # my_handler() > eval { AnotherException->throw; };# another_handler() > eval { YetAnotherException->throw; }; # another_handler() : hierarchical > eval { FooBarException->throw; }; # default_handler() > > sub my_handler { > my $exception = shift; > # ... > } > > sub another_handler { } > sub default_handler { } > > DESCRIPTION > Exception::Handler allows you to handle exception with various subs each > of which registered for an appropriate class of exception. This module > can nicely work with Dave Rolsky's Exception::Class and Grahamm Barr's > Error module. > > TODO > * Lexical handler, which may be done via "local". > > AUTHOR > Tatsuhiko Miyagawa <[EMAIL PROTECTED]> > > This library is free software; you can redistribute it and/or modify > it under the same terms as Perl itself. > > SEE ALSO > Exception::Class, Sig::PackageScoped > > > > -- > Tatsuhiko Miyagawa <[EMAIL PROTECTED]> > >
Re: push_handlers
"Stathy Touloumis" <[EMAIL PROTECTED]> wrote: >For some reason the call to 'push_handlers' does not seem to register the >'handler' with mod_perl correctly when used in the code below. It seems >that only a few initial requests will successfully be processed by this >handler. It then just seems to be bypassed. It only works when the >'push_handler' code is commented out and a Perl*Handler directive is added >to the apache conf file. Does anyone know why this is so? > >Here is a snippet of code which is read in at server startup through a >'require' directive. > >Apache->push_handlers( > PerlPostReadRequestHandler=> \&handler >); > >sub handler { warn "Hello World\n"; } As far as I know, push_handlers only works the the current request -- that is, the handlers pushed with it are cleared at the end of the request. It would seem that doing this at startup sets up the handler which then gets used by the children and cleared after the first request they serve. This would give you the symptoms you're seeing (each child called once, and then it disappears). Try running httpd -X to see what happens. There's also probably something in the guide about it. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
push_handlers
For some reason the call to 'push_handlers' does not seem to register the 'handler' with mod_perl correctly when used in the code below. It seems that only a few initial requests will successfully be processed by this handler. It then just seems to be bypassed. It only works when the 'push_handler' code is commented out and a Perl*Handler directive is added to the apache conf file. Does anyone know why this is so? Here is a snippet of code which is read in at server startup through a 'require' directive. Apache->push_handlers( PerlPostReadRequestHandler=> \&handler ); sub handler { warn "Hello World\n"; }
Re: mod_perl framework + code reuse question
> For file organization, I'm thinking of making all "page" modules start > with a common namespace substring (e.g. Projectname::Page) to distinguish > them from the support (model) modules I like to name the top level modules SiteName::Control::* and the model modules SiteName::Model::*. Calling the modules "Page" makes it sound like each one corresponds to a single page, which is not always true, i.e. you might have an adress book module that generates many different pages (with different templates) based on the parameters passed to it. Glad to hear the handlers are working out for you. - Perrin
Re: mod_perl framework + code reuse question
At 01:48 PM 1/10/2002 -0500, Perrin Harkins wrote: >You can actually use subroutines without fear! Also, reducing the amount of >magic (i.e. all of that package generation and eval stuff that Registry >does) can help clear up confusion. And you can use __END__ and __DATA__. Good point. I started writing a handler and have something basically working. It's still pretty barebones, but I'm happy with it so far, and performance is good. It "require"-s the appropriate "page" module based on $r->filename, $r->path_info, and $r->document_root then calls that module's "run" method as a class method (both steps wrapped in separate evals). Apache::Reload is reloading both handler module and "page" module as needed. For file organization, I'm thinking of making all "page" modules start with a common namespace substring (e.g. Projectname::Page) to distinguish them from the support (model) modules for that site and moving them into the same directory tree that contains those support modules, then moving templates (currently in ./tt/*.tpl files relative to *.par scripts) into either that directory tree alongside the modules they are used by or into an entirely separate tree that only contains templates. The latter is probably better for sites that have some division of labor between coders and HTML designers, but that's not the case on this one. Thank you for all the help. Matthew Pressly
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 11 Jan 2002, Matt Sergeant wrote: > Any chance of supporting more template systems in the future, like TT and > XSLT? Adding more Burners (brictalk for templating system) is definitely something we're interested in. If you'd like to give it a try there's a brief set of instructions in the Bric::Util::Burner docs: http://bricolage.thepirtgroup.com/docs/Bric/Util/Burner.html Look for the "ADDING A NEW BURNER" section. For general information about the templating system, see: http://bricolage.thepirtgroup.com/documentation.html -sam
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 2002-01-11 at 11:39, Matt Sergeant wrote: > Looks neat! Thanks, Matt! > Any chance of supporting more template systems in the future, like TT and > XSLT? The templating architecture is managed via subclasses. So anyone who wants to add his/her favorite templating system is welcome to implement a new subclass. I encourage interested developers to join the bricolage-devel list on SourceForge. https://sourceforge.net/mail/?group_id=34789 Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: ANNOUNCE: Bricolage 1.2.0
On 11 Jan 2002, David Wheeler wrote: > On Fri, 2002-01-11 at 01:29, [EMAIL PROTECTED] wrote: > > > Do you provide a demo of Bricolage. Can I expect something similar to > > the Midgard Project on PHP? > > Unfortunately there is no demo of Bricolage at this time. But you can > start reading up on it and see some screenshots at > http://bricolage.thepirtgroup.com/. Looks neat! > I'm not familiar with Midgard, though it looks interesting. What > differentiates Bricolage from other OSS CMSs, however, is its robust > support for configurable workflows. Furthermore, its templates are > written in HTML::Mason or HTML::Template -- that is, Perl. So you have a > complete, robust programming language to work with. Any chance of supporting more template systems in the future, like TT and XSLT? -- <:->Get a smart net
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 2002-01-11 at 01:29, [EMAIL PROTECTED] wrote: > Do you provide a demo of Bricolage. Can I expect something similar to > the Midgard Project on PHP? Unfortunately there is no demo of Bricolage at this time. But you can start reading up on it and see some screenshots at http://bricolage.thepirtgroup.com/. I'm not familiar with Midgard, though it looks interesting. What differentiates Bricolage from other OSS CMSs, however, is its robust support for configurable workflows. Furthermore, its templates are written in HTML::Mason or HTML::Template -- that is, Perl. So you have a complete, robust programming language to work with. Thanks, David -- David Wheeler AIM: dwTheory Bricolage Maintainer ICQ: 15726394 [EMAIL PROTECTED] Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Did "Can't upgrade that kind of..." come back ?!?
Hi, I have written a mod_perl handler that "require" other Perl modules; these modules use the pragma 'warnings' (i.e. 'use warnings'). When I start httpd I get this message in error log:Can't upgrade that kind of scalar (#1) (P) The internal sv_upgrade routine adds "members" to an SV, making ==3Dit into a more specialized kind of SV. The top several SV types are so specialized, however, that they cannot be interconverted. Thismessage indicates that such a conversion was attempted.Uncaught exception from user code: Can't upgrade that kind of scalar.If I eliminate 'use warnings' calls all is OK!Note that I have problems only for package required whenhttpd starts; infact when I process the request I, dinamically, require other packages (according to URI) which includethe pragma 'use warnings' and all is OK!!I looked up in the mod_perl guide and found in the section"Warnings and Errors Troubleshooting" that error'Can't upgrade that kind of scalar"was fixed in mod_perl 1.23.Currently I use httpd 1.3.22 and mod_perl 1.26 (and perl5.6.1)So what's wrong!?!Thank you in advance!! Marco Guazzone ICQ#: 107450046
Re: Questions on note_basic_auth_failure and get_basic_auth_pw
The Sapphire Cat wrote: > > Documentation for these functions reads as follows: > > $r->get_basic_auth_pw > If the current request is protected by Basic authentication, this > method will return 0, otherwise -1. [snip] ok, that's unclear (and not 100% correct, either). I'd change it to: If the current request is protected by Basic authentication, this method will return OK. Otherwise, it will return a value that ought to be propagated back to the client (typically AUTH_REQUIRED). > > $r->note_basic_auth_failure > Prior to requiring Basic authentication from the client, this method > will set the outgoing HTTP headers asking the client to authenticate > for the realm defined by the configuration directive `AuthName'. this looks fine as a high-level overview. > > Experiments have shown that in an AuthenHandler, get_basic_auth_pw > will return AUTH_REQUIRED if the request is protected and the client > did not send credentials. Furthermore, note_basic_auth_failure seems > to have no effect on the realm name. [snip] > So what does > note_basic_auth_failure *really* do? it really does pretty much what it says, it's just that you are misunderstanding it :) note_basic_auth_failure sends the WWW-Authenticate header back to the client, using the value set in httpd.conf for AuthName. this ought to signify that the requested resource requires user credentials for the specified realm - what the client chooses to do with that information is up to the client, but most know how to implement Basic authentication by now :) you really need to look at the headers involved in this multi-step process to understand what's going on. (or see recipe 13.3 ;) > > Finally, I want to fix the get_basic_auth_pw documentation. Where > should patches go for that, and in what format? send a unified diff of Apache.pm (based on the CVS version) to [EMAIL PROTECTED] if you agree with the above changes, I'll submit it for you if you want. --Geoff
RFC: Exception::Handler
Seeing through Dave Rolsky's Exception::Class and Sig::PackageScoped has let me make the following module, called Exception::Handler. In fact I rarely use $SIG{__DIE__} for exception handling, but the concept of the module would be a bit interesting. Especially eval { }; if ($@->isa('FooException')) { # ... } elsif ($@->isa('BarException')) { # ... } else { # ... } code like this can be greatly simplified. Any suggestions welcome, escpecially from gurus of exception, Matt and Dave ;) See t/*.t for typical usage. http://bulknews.net/lib/archives/Exception-Handler-0.01.tar.gz NAME Exception::Handler - Hierarchical exception handling SYNOPSIS use Exception::Class 'MyException', 'AnotherException' => { isa => 'MyException' }, 'YetAnotherException' => { isa => 'AnotherException' }, 'FooBarException'; use Exception::Handler MyException => \&my_handler, AnotherException => \&another_handler, __DEFAULT__ => \&default_handler; eval { MyException->throw }; # my_handler() eval { AnotherException->throw; };# another_handler() eval { YetAnotherException->throw; }; # another_handler() : hierarchical eval { FooBarException->throw; }; # default_handler() sub my_handler { my $exception = shift; # ... } sub another_handler { } sub default_handler { } DESCRIPTION Exception::Handler allows you to handle exception with various subs each of which registered for an appropriate class of exception. This module can nicely work with Dave Rolsky's Exception::Class and Grahamm Barr's Error module. TODO * Lexical handler, which may be done via "local". AUTHOR Tatsuhiko Miyagawa <[EMAIL PROTECTED]> This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO Exception::Class, Sig::PackageScoped -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: ANNOUNCE: Bricolage 1.2.0
Basel, Freitag, 11. Januar 2002, 10:26:28 . *see original email below* Hello David > Bricolage is a full-featured, enterprise-class content management > system. It offers a browser-based interface for ease-of use, a > full-fledged templating system with complete programming language > support for flexibility, and many other features. It operates in an > Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its > repository. Do you provide a demo of Bricolage. Can I expect something similar to the Midgard Project on PHP? Best Regards Christian - [EMAIL PROTECTED] - . == beginn original == Date: Freitag, 11. Januar 2002, 04:06:23 Subject: ANNOUNCE: Bricolage 1.2.0 I'd like to announce the release of Bricolage 1.2.0. It will shortly be available for download from http://bricolage.sourceforge.net/. This release features several bug fixes and quite a few important new features. It uses HTML::Mason exlusively for its UI, and uses either HTML::Mason or HTML::Template for its templating architecture. Here's a brief description of Bricolage: Bricolage is a full-featured, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. Here's a list of the changes from 1.0.2: VERSION 1.2.0 New Features * Added Context-sensitive, online help. [Sam] * Added separate interface for editing templates (via FTP). [Sam] * Added the ability to use HTML::Template Templates. [Sam] * Added ability for differnt Output Channels to function as different component roots for in Mason templates. This will allow for templates that can't be found in the current Output Channel to be searched for in other Output Channels. [David] * Added link to Event log to Find Story, Find Template, and Find Media screens. [David] * Added true previewing for media assets. Now, when you click their URIs to preview them, they will be distributed to the preview server(s) before redirecting the user to them, rather than just serving them up from where they live on the Bricolage file system. The latter can still be accessed under "Download" in the Media Asset profile. This will continue to be the preferred way to grab media files for editing and such, as it will not incur the overhead of distributing the media file. [David] * Allow only one template with a given name for a given category, element, burner and output channel. [Sam] * Added a Maintainer section to the About page. [David] * Updated About page to mimic the layout of the help pages. [David] Bug Fixes * Fixed a bug with local previews where a preview page could show up instead of the Bricoalge UI. Thanks to Sara for the spot. [David] * Fixed a bug where Mason component calls failed in previews when the PREVIEW_MASON directive was enabled. [David] * Changed default value for text area fields added via the form builder (i.e., in Contributor Type and Element profiles) to 0. The values 0 and "" always make the the new field unlimited in length. [David] * Fixed a couple of buttons to be proper case rather than upper case. [David] * Separated the filesystem destinations for assets burned for publication and for assets burned for previewing. This will prevent someone previewing and stomping all over a published version of an asset before the published version is distributed. [David] * Removed hard-coding of the local preview directory in httpd.conf and httpd-ssl.conf. Now using the values stored in PREVIEW_LOCAL, instead, to determine the proper directory. [David] * Added the DEF_MEDIA_TYPE directive. Bricolage will use the value in this directive to assign a Media Type to all file resources if they Bricolage can't figure it out from their file extentions. This fixes a bug where Bricolage would choke if it couldn't figure out the MediaType itself. [David] Enjoy! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] === end original