ANNOUNCE: Apache::RedirectDBI 0.02

2001-10-05 Thread George Sanderson

I needed a module that would allow users' to login (authenticate) using a
single HREF link and then be redirected to their individual web site (URL).
I searched CPAN and found Apache::RedirectDBI.  It was very close to what I
needed, so I modified it so that it would read a URL field from the user's
DBI record and do an external REDIRECT to their site location.

In the process of upgrading the module, I thought to myself; "self, it
would be nice if the cpan released module was updated..., so I fired off an
email to the author, Michael Smith.  Mike replied:
>This is a bit of a blast from the past! I've not looked at it for quite 
>some time (is it in my name on CPAN?)
>
>Anyway, very happy to get your changes in to what's on CPAN ... or better 
>still, hand it over to you. 

So that is what I did.  I contacted CPAN and uploaded
RedirectDBI-0.02.tar.gz on 05 Oct. 02 to CPAN.  (It will take a while for
it to show up on CPAN.)

The module is also available for download at:
http://www.xorgate.com/Apache/RedirectDBI

[I think that the Perl public community is really awesome. . .]


++
| George Sanderson <[EMAIL PROTECTED]>
| http://www.xorgate.com
++




Re: backticks in mod_perl

2001-10-05 Thread Brian Reichert

On Fri, Oct 05, 2001 at 10:51:49PM +0200, EXP wrote:
> Hi
> 
> Simple question, it seems that the backticks won't work as expected in 
> mod_perl scripts.

'As expected'?  What does that mean?

> Is there some module like Apache::SubProcess to read the output of a 
> command into an array?

What's wrong with system(), and doing a split on $/, or the like?

> (my @out = `command`;)
> I am sure the answer is somewhere out there, but I couldn't find it.
> thx.
> 
> 
> BYe!
> EXP

-- 
Brian 'you Bastard' Reichert<[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path



Re: [patch] overriding per directory PerlSetEnv (including bugreport)

2001-10-05 Thread ___cliff rayman___

much more well understood this time.  thank you.

the developers monitor this list - so if your patch has merit,
i'm sure they will either commit it or something similar.

YAMAMOTO Kengo wrote:

> Thank you responding.
>
> On Thu, 4 Oct 2001 13:48:19 -0400,
> Robert Landrum <[EMAIL PROTECTED]> wrote:
> > Couldn't you do the same thing by reversing the ordering of your
> > Directory entries...
>
> On Thu, 04 Oct 2001 10:43:31 -0700,
> ___cliff rayman___ <[EMAIL PROTECTED]> wrote:
> > i don't think it is supposed to work this way according to the
> > apache documentation.  if you want the most specific (longest) one
> > to take precedence, put it before the shorter one in the config file.
>
> Rewriting config file so takes no effect (had tested) because
> Apache reorders  section config with most specific to
> least specific order (by ap_core_reorder_directories()) precede
> merging these configs by directory_walk().
>
> It seems that I had explained my intention not enough in last
> mail. I had written the patch to solve following problem.
>
> (1) Since perl_merge_dir_config() uses ap_overlay_tables() to
> merge PerlSetEnv variables, overridden variables remains in
> the table as association list elements (internal
> representation of Apache's table).
>
> (2) The table remains precedences and consistency kept while
> manipulated by Apache's standard table APIs
> (e.g. ap_table_get()).
>
> (3) Although (2), mod_perl scans through internal structure of
> the table directly as association list to dumps variables
> into %ENV by mod_perl_dir_env(). This causes precedence
> reversed on dumped %ENV variables because the list elements
> is ordered by descending precedence.
>
> Above process results that PerlSetEnv always activates least
> specific  section value. It's a real bug.
>
> My patch modifies (3) by reverses iterating direction on dump.
> I would like the patch to be tested by someone else and included
> in the mod_perl distribution. Please help!
>
> > YAMAMOTO Kengo wrote:
> >
> > > I think that per directory PerlSetEnv variable should be
> > > overridden by the value that in the most specific(longest)
> > >  section.
> > >
> > > http://localhost/cgi-bin/subdir/printenv with following config
> > > will generate VAR="/usr/local/apache/cgi-bin/subdir", but
> > > generated result is VAR="/usr/local/apache/cgi-bin".
> > >
> > >   
> > > PerlSetEnv VAR /usr/local/apache/cgi-bin
> > >   
> > >
> > >   
> > > PerlSetEnv VAR /usr/local/apache/cgi-bin/subdir
> > >   
>
> -
> YAMAMOTO Kengo [EMAIL PROTECTED]

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/





backticks in mod_perl

2001-10-05 Thread EXP

Hi

Simple question, it seems that the backticks won't work as expected in 
mod_perl scripts.
Is there some module like Apache::SubProcess to read the output of a 
command into an array?
(my @out = `command`;)
I am sure the answer is somewhere out there, but I couldn't find it.
thx.


BYe!
EXP

3DWARS.de - Your resource for 3Dimensional Warfare
   http://www.3DWARS.de

PS: Big Brother IS Watching You!




Re: [patch] overriding per directory PerlSetEnv (including bugreport)

2001-10-05 Thread YAMAMOTO Kengo

Thank you responding.

On Thu, 4 Oct 2001 13:48:19 -0400,
Robert Landrum <[EMAIL PROTECTED]> wrote:
> Couldn't you do the same thing by reversing the ordering of your 
> Directory entries...

On Thu, 04 Oct 2001 10:43:31 -0700,
___cliff rayman___ <[EMAIL PROTECTED]> wrote:
> i don't think it is supposed to work this way according to the
> apache documentation.  if you want the most specific (longest) one
> to take precedence, put it before the shorter one in the config file.

Rewriting config file so takes no effect (had tested) because
Apache reorders  section config with most specific to
least specific order (by ap_core_reorder_directories()) precede
merging these configs by directory_walk().

It seems that I had explained my intention not enough in last
mail. I had written the patch to solve following problem.

(1) Since perl_merge_dir_config() uses ap_overlay_tables() to
merge PerlSetEnv variables, overridden variables remains in
the table as association list elements (internal
representation of Apache's table).

(2) The table remains precedences and consistency kept while
manipulated by Apache's standard table APIs
(e.g. ap_table_get()).

(3) Although (2), mod_perl scans through internal structure of
the table directly as association list to dumps variables
into %ENV by mod_perl_dir_env(). This causes precedence
reversed on dumped %ENV variables because the list elements
is ordered by descending precedence.

Above process results that PerlSetEnv always activates least
specific  section value. It's a real bug.

My patch modifies (3) by reverses iterating direction on dump.
I would like the patch to be tested by someone else and included
in the mod_perl distribution. Please help!


> YAMAMOTO Kengo wrote:
> 
> > I think that per directory PerlSetEnv variable should be
> > overridden by the value that in the most specific(longest)
> >  section.
> >
> > http://localhost/cgi-bin/subdir/printenv with following config
> > will generate VAR="/usr/local/apache/cgi-bin/subdir", but
> > generated result is VAR="/usr/local/apache/cgi-bin".
> >
> >   
> > PerlSetEnv VAR /usr/local/apache/cgi-bin
> >   
> >
> >   
> > PerlSetEnv VAR /usr/local/apache/cgi-bin/subdir
> >   

-
YAMAMOTO Kengo [EMAIL PROTECTED]



RE: Setting Perl-stuff inside section

2001-10-05 Thread Geoffrey Young



> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 05, 2001 2:26 PM
> To: Scott Lanning; [EMAIL PROTECTED]
> Subject: Re: Setting Perl-stuff inside  section
> 
> 
> > @PerlModule = qw(Blah);  # add others to the list
> 
> Might as well just say "use Blah;", I think.

unless you are using directive handlers with recent mod_perls, in which case
PerlModule is required.

--Geoff



Re: Setting Perl-stuff inside section

2001-10-05 Thread Perrin Harkins

> @PerlModule = qw(Blah);  # add others to the list

Might as well just say "use Blah;", I think.
- Perrin




Re: Setting Perl-stuff inside section

2001-10-05 Thread Scott Lanning

On Fri, 5 Oct 2001, raptor wrote:
>How can I set in  section, say :
>
>PerlModule Blah.pm
>PerlSetVar XXX On
>PerlSetVar YYY Off


@PerlModule = qw(Blah);  # add others to the list
push @PerlSetVar, [ XXX => 'On'  ];
push @PerlSetVar, [ YYY => 'Off' ];


There's good examples in the eagle book, chapter 8.




Re: webDAV server in mod_perl?

2001-10-05 Thread Craig McLane

There was some talk on the mod_perl dev list a week or so ago by Gerald
Richter of using some of the XS auto generation functionality in mod_perl
2.0 to wrap mod_dav inside perl.

Here is work he has done posted to the web_dav list: 
 http://marc.theaimsgroup.com/?l=dav-announce&m=100139218624911&w=2

Here is the posting the the mod_perl dev list:
 http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=100141271317363&w=2


Craig


On Fri, 5 Oct 2001, tim fulcher wrote:

> Hi
> 
> I'm arriving at the conclusion that a few of the things I'm trying to do
> in my application are basically pseudo webDAV type actions such as
> PROPFIND
> & PROPATCH, but currently all handled on the server side via Perl & PHP.
> I'm looking to see whether I could move to a proper webDAV type
> solution but reuse a lot of the work I've already done. Client side
> libraries seem to be reasonably prolific in a number of languages but
> server side
> implementations are a bit thin on the ground.
> 
> The mod_dav module seems to be a solution of kinds, though people seem
> to have lots of hassle getting it to operate alongside mod_perl (indeed
> my build of  mod_dav as a shared object with mod_perl built statically
> prevented the server starting up properly).
> But the reason I'd rather not use mod_dav is that  I want more control
> over how the properties get stored. Ideally I'd want some abstraction to
> the
> storage layer where I could try out different ideas (Berkeley DB, MySQL
> or whatever) to stash the properties (dead ones I guess), plus maybe
> lock and version information of resources
> 
> The Jakarta Slide approach seems more akin to what I'm after with webDAV
> functionality as just a component, but for now I'd like to stick to
> something
> in Perl or maybe PHP.
> 
> Frankly I'm surprised no one seems to have attempted a Perl server side
> webDAV implementation by now :-)
> 
> Anybody out there tinkered with the possibilities of a mod_perl based
> webDAV server  ?
> 
> cheers
> 
> 
> Tim Fulcher
> 







Setting Perl-stuff inside section

2001-10-05 Thread raptor

hi,

How can I set in  section, say :

PerlModule Blah.pm
PerlSetVar XXX On
PerlSetVar YYY Off

and similar...

$VirtualHost{address} = {
PerlModule => 'Blah.pm',
PerlSetVar => { XXX => 'On', YYY => 'Off' }
};
!!?!

Thanx
=
iVAN
[EMAIL PROTECTED]
=




Re: webDAV server in mod_perl?

2001-10-05 Thread Robin Berjon

On Friday 05 October 2001 13:03, tim fulcher wrote:
> Frankly I'm surprised no one seems to have attempted a Perl server side
> webDAV implementation by now :-)

I've been thinking about it for a while, but haven't had the time to get down 
and have a close look at the details. A completely hookable WebDAV 
server-side implementation in mod_perl would definitely be a must. I too 
don't want to have to use mod_dav as it makes the property, lock, collection, 
and file storages pretty much hardcoded. I'd like to put properties and locks 
into a db, collections as virtual URLs (URIs really), and files in some sort 
of custom data store. I also want in and out filtering of the properties so 
that I could accomplish my idea of mixing DAV and RDDL, something which imho 
would be a great solution (though it requires extending RDDL somewhat).

By all means if you do have the time, jump ahead !

-- 
___
Robin Berjon <[EMAIL PROTECTED]> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
---
"Many people would sooner die than think. In fact, they do." 
-- Bertrand Russell




webDAV server in mod_perl?

2001-10-05 Thread tim fulcher

Hi

I'm arriving at the conclusion that a few of the things I'm trying to do
in my application are basically pseudo webDAV type actions such as
PROPFIND
& PROPATCH, but currently all handled on the server side via Perl & PHP.
I'm looking to see whether I could move to a proper webDAV type
solution but reuse a lot of the work I've already done. Client side
libraries seem to be reasonably prolific in a number of languages but
server side
implementations are a bit thin on the ground.

The mod_dav module seems to be a solution of kinds, though people seem
to have lots of hassle getting it to operate alongside mod_perl (indeed
my build of  mod_dav as a shared object with mod_perl built statically
prevented the server starting up properly).
But the reason I'd rather not use mod_dav is that  I want more control
over how the properties get stored. Ideally I'd want some abstraction to
the
storage layer where I could try out different ideas (Berkeley DB, MySQL
or whatever) to stash the properties (dead ones I guess), plus maybe
lock and version information of resources

The Jakarta Slide approach seems more akin to what I'm after with webDAV
functionality as just a component, but for now I'd like to stick to
something
in Perl or maybe PHP.

Frankly I'm surprised no one seems to have attempted a Perl server side
webDAV implementation by now :-)

Anybody out there tinkered with the possibilities of a mod_perl based
webDAV server  ?

cheers


Tim Fulcher




proxy block list module?

2001-10-05 Thread Mark Tiramani

I was looking for an Apache module to handle access control via URL/regex that reads a 
list of rules from file.

I find it hard to believe no-one has done this yet so appologies in advance if I just 
didn't search properly.

I tried searching all the usual sources but came up blank so I adapted the 
Apache::BlockAgent handler from the 
Eagle book (excellent). If anyone has more info on an existing module/handler I'd be 
grateful. 

The original requirement was to control a clients proxy access so that only a list of 
about 30 URLs were accessible 
from their LAN. I needed an Apache config directive and handler that reads its list of 
names/IPs/regexes from a text 
file, caches the list at startup/restart and stats the text file so that 
additions/alterations take immediate effect. The 
list has to be an 'allow' list as well as a 'deny' list so that the overhead is 
minimised and admin tools have an easier 
job of controlling access by editing/validating only one file.

Just in case there really are no such modules out there: Apache::URLControl.pm is 
still pretty basic but it does the 
following:

Adds an Apache config directive that specifies a ServerRoot relative text file:

PerlSetVar  URLControlFile  access_filters/url_control
PerlPostReadRequestHandler  Apache::URLControl

URLControl.pm currently handles the request as a: PerlPostReadRequestHandler in two 
test setups.
Used in this way it is obviously not proxy-specific and blocks/allows requests at the 
earliest opportunity.

The control file can contain:

DEFAULT DENY
www.adomain.com ALLOW
anotherdomain.com   DENY
http://somewhere.com/.*.asp DENY
https://domain.com/
194.164.46.4/blah/blah
/apath/asubdir/afile.htm
.*microsoft.*   DENY
# a comment etc.

If DEFAULT DENY is used then only access to locations matching an ALLOW line are 
allowed. Otherwise the list 
can contain specific DENY rules and if DENY is omitted the rule defaults to DENY.

If the rule begins with https:// then a CONNECT adomain.com:443 is denied or allowed. 
The rule could also be 
written as:
adomain.com:443 DENY

The '.' in domain.com and index.htm are escaped in the module, as are %,/,+  This just 
simplifies writing the file 
somewhat. Otherwise the Perl regex in a rule is handled as-is.

A 403 is returned if the request is blocked but the URL from $r->the_request is 
substituted for $r->uri so that proxy 
requests are denied with the full URL as the reason and not '/'.

If anyone is interested I will stress-test it and then enter the module to CPAN. If 
there is nothing similar I will develop 
it to allow for cached IP lookups (to convert the IP->domain name and match on that in 
the list) and add other 
refinements.

Mark

Mark Tiramani
FREDO Internet Services
[EMAIL PROTECTED]