Apache 2.0.44 binary for Win98

[Max Liokumovich <Ma...@stu.harper.cc.il.us>]

I couldn't find server and error.log.


I found the article on http://httpd.apache.org/docs-2.0/stopping.html 
confusing. Can you tell me how to stop? Where do I need to type apachectl -k 
stop. In, dos, after C: prompt?


Regards

Apache::Request

[angie ahl <an...@vertebrate.co.uk>]

Hi guys

A simple little question (I think ;)

I've just been roaming around my Linux box (Mod_perl 1, Apache 1) and my OSX Box
(Mod_perl 1, Apache 1) looking for Apache/Request.pm

no sign of it on either.

Hs it been removed for any reason anyone would know about (ie supersceeded, or
depracated ) or is it not necessasry. 

I'm just looking for a way to get params from the browser really.

Thanks

Angie

PS Other Apache modules are there eg on my OSX box

Connection.pm
Constants
Constants.pm
Debug.pm
ExtUtils.pm
FakeRequest.pm
File.pm
Include.pm
Leak.pm
Log.pm
ModuleConfig.pm
MyConfig.pm
Opcode.pm
Options.pm
PerlRun.pm
PerlRunXS.pm
PerlSections.pm
RedirectLogFix.pm
Registry.pm
RegistryBB.pm
RegistryLoader.pm
RegistryNG.pm
Resource.pm
SIG.pm
Server.pm
SizeLimit.pm
StatINC.pm
Status.pm
Symbol.pm
Symdump.pm
Table.pm
URI.pm
Util.pm
httpd_conf.pm
src.pm
test.pm

RE: Abusing $r->requirements object in authorization handler

[Frank Maas <fr...@cheiron-it.nl>]

> It doesn't seem to work, and that doesn't surprise me.  I'm guessing
> that the $r->requirements data structure is re-generated with each
> handler call, but I don't know and haven't crawled through the
> mod_perl code to find out. 
> 
> Is the technique I outline here supposed to work or is it just a bad
> idea? 
> 

Why not simply use pnotes to store this information throughout the
request-lifecycle? Seems to perfectly suit your needs.

--Frank

Re: Abusing $r->requirements object in authorization handler

[Stas Bekman <st...@stason.org>]

Ged Haywood wrote:
[...]

> Perhaps I should have said that a lot of work is being done on it,
> it's very much a "work in progress", so things are happening (such as
> changes to the API) which won't be happening to V1.37.

Yes, the mod_perl 2.0 API is not frozen, mainly because Apache/APR keep on 
changing these. So we have to adher as those change. That's one of the main 
reasons why you see 1.99_xx and not 2.0.xx.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Abusing $r->requirements object in authorization handler

[Ged Haywood <ge...@www2.jubileegroup.co.uk>]

Hi Stas,

On Mon, 19 May 2003, Stas Bekman wrote:

> > And pretty unstable right now...
> 
> I'd be more careful making this kind of vague broad statements.

I accept that criticism. :)

Perhaps I should have said that a lot of work is being done on it,
it's very much a "work in progress", so things are happening (such as
changes to the API) which won't be happening to V1.37.

73,
Ged.

Re: Abusing $r->requirements object in authorization handler

[Stas Bekman <st...@stason.org>]

Ged Haywood wrote:

>>trying to become smart on mod_perl, particular the
>>upcoming 2.0 version (which is pretty awesome).
> 
> 
> And pretty unstable right now...

I'd be more careful making this kind of vague broad statements.
This kind of statements takes us backwards rather bringing closer to a 
production release. The less people are going to give it a try the slower the 
polishing process will be. If the question suggests to use a particular 
feature that you know is unstable in mod_perl 2.0, then your answer would be 
more to the point.

Incomplete, yes. Unstable, no. Check your particular needs and chances are 
that you will find mod_perl 2, perfectly stable and production-suitable for 
you. Certainly one has to test things before going with production server update.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

RE: Abusing $r->requirements object in authorization handler

[Ged Haywood <ge...@www2.jubileegroup.co.uk>]

Hi there,

On Sun, 18 May 2003, Marc M. Adkins wrote:

> [snip]
> .htaccess files.
> [snip]
> Hmmm...that alone probably makes this a bad idea.

You're starting to answer your own questions... :)

> not convinced that implementing my own auth handler is the right way

Keep it as simple as you can, you'll have plenty of issues to deal
with without creating them (and it will probably run faster:).  Have
you looked at ready-made Perl modules (e.g. CPAN) which do auth stuff?

> trying to become smart on mod_perl, particular the
> upcoming 2.0 version (which is pretty awesome).

And pretty unstable right now...

73,
Ged.

RE: Abusing $r->requirements object in authorization handler

["Marc M. Adkins" <mm...@Doorways.org>]

> > I'm writing an authorization handler.  It seems somewhat inefficient
> > [snip]
> > I was trying to parse the strings the first time I see them and hang the
> > result on the requirement hash to save time in future handler calls.
> > [snip]
> > is it just a bad idea?
>
> It might be.
>
> Tell us more.  What's it for?  How secure is it to be?

In the current instance:  user roles.  admin, accounting, editor, that sort
of thing.  Somewhat like the group stuff but in a database and editable via
panels on the site.  All of these roles are being used within the SLL part
of the site.

In the future:  I was considering using a similar mechanism for different
parts of the site (assuming I get that far).  These sections would be
outside of the SSL area.  Not so secure.

All of this should be accessed completely within the authorize handler.
There should be no way for it to be visible on a web page or changed by a
malicious user.  I have complete control of the Perl code on the site.
Nothing seems obviously insecure (unsecure?) but it's hard to prove a
negative.

I could, of course, just use the basic group-based authorization.  Why not?
Well,

* It's not in the database, and I'd like it to be.
* There's the possibility that my second application will be three-way
  authorization (user, site-section, role) so that non-admin users can
  be allowed roles in particular sections of the site.  I suppose I could
  use composite group names (e.g. section1-editor) for that.
* The editing roles via site panels thing, which is harder with the group
files.
* Group files require user names, which are really user ID numbers in the
  database, unique but not really the ID key, makes things less good.

My question, however, is mostly concerned with speed of authorization.  I've
noticed (I think) that when I attach the handler to a part of the site
anything on that part of the site must be authorized.  This includes images,
CSS files, etc.  So it needs to be fast, yes?  I don't know if the group
file is read each time.  I would like to cut down on database hits in my own
implementation (though this may cost me currency of the role-checking
algorithm).  The parsing of the require lines seems like something that
could be done once and cached as well, with no loss of currency EXCEPT for
.htaccess files.

The last bit hadn't occurred to me until just now.  I had been thinking that
the configuration tree was static after Apache launch, but that's NOT true
for areas that are updated via .htaccess.  I'm not using same but the
possibility is there.  Hmmm...that alone probably makes this a bad idea.

I'm not convinced that implementing my own auth handler is the right way to
go.  I may yet drop back to group files.  I'm playing with this stuff right
now.  Part of this is trying to become smart on mod_perl, particular the
upcoming 2.0 version (which is pretty awesome).

mma

Re: Abusing $r->requirements object in authorization handler

[Ged Haywood <ge...@www2.jubileegroup.co.uk>]

Hi there,

On Sun, 18 May 2003, Marc M. Adkins wrote:

> I'm writing an authorization handler.  It seems somewhat inefficient
> [snip]
> I was trying to parse the strings the first time I see them and hang the
> result on the requirement hash to save time in future handler calls.
> [snip]
> is it just a bad idea?

It might be.

Tell us more.  What's it for?  How secure is it to be?

73,
Ged.

Abusing $r->requirements object in authorization handler

["Marc M. Adkins" <mm...@Doorways.org>]

I'm writing an authorization handler.  It seems somewhat inefficient to
parse and re-parse each requirement line each time the handler is called per
the example code I have found thus far, for example:


http://perl.apache.org/docs/tutorials/tips/mod_perl_tricks/mod_perl_tricks.h
tml#Gender_Based_Authorization

The $r->requirements object is an array of hashes, with the source for the
requirement line off of each hash, for example (I'm ignoring the other field
that's in the hash):

	[
	    { requirement => 'role admin root' }
	]

I was trying to parse the strings the first time I see them and hang the
result on the requirement hash to save time in future handler calls.  For
example:

	map {
	    $_->{parsedroles} = split /\s+/, $1
	        if $_->{requirement} =~ /^role\s+(.*)/
	    } @{$r->requirements};

would yield:

	[
	    {
	        requirement => 'role admin root',
	        parsedroles => [ 'admin', 'root' ]
	    }
	]

Subsequent calls could just grab the pre-parsed array structure (in theory).

It doesn't seem to work, and that doesn't surprise me.  I'm guessing that
the $r->requirements data structure is re-generated with each handler call,
but I don't know and haven't crawled through the mod_perl code to find out.

Is the technique I outline here supposed to work or is it just a bad idea?

mma

Re: Apache 2.0.44 binary for Win98

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Sat, 17 May 2003, Max Liokumovich wrote:

> I couldn't find server and error.log.

They should be under $APACHE2\logs\, where $APACHE2 is
the top-level directory where you installed Apache2.
 
> I found the article on
> http://httpd.apache.org/docs-2.0/stopping.html confusing. Can
> you tell me how to stop? Where do I need to type apachectl -k
> stop. In, dos, after C: prompt?

That's more unix-specific - for Win32, it's typical to start
and stop Apache as a service. See
 http://httpd.apache.org/docs-2.0/platform/windows.html#winsvc

-- 
best regards,
randy kobes