[ic] access_gating whole catalog?

Mike Heins interchange-users@icdevgroup.org
Wed Oct 23 00:33:01 2002


Quoting cfm@maine.com (cfm@maine.com):
> On Tue, Oct 22, 2002 at 10:14:05PM -0400, Mike Heins wrote:
> > 
> > Quoting Mike Heins (mike@perusion.com):
> > > 
> > > I will certainly look at changing 4.9 and enabling it in the root
> > > directory as an option. I have not examined that code in quite some
> > > time, and it is always good to revisit previous decisions and see if
> > > they still make sense. 8-)
> > 
> > Looking at it, it seems to make sense only if I redo the entire
> > way this is all checked and specified. Or if I make the root
> > .access enable .access_gate checking in all subdirectories...
> > I am not sure of the implications of that.
> > 
> > I really hesitate to add yet another file test and corresponding
> > directory lookup. The routine that uses this, Vend::Util::readin,
> > is used in virtually every IC transaction.
> > 
> > I have long thought about incorporating Apache-style .htaccess control.
> > Part of the reason I did not originally is that Interchange has roots in
> > times when Apache was nowhere near as dominant as it is now -- it was
> > far from clear in 1996 (at least to me) what was going to happen.
> > 
> > Were I to do it, I would probably want to integrate with Apache
> > so that DBI authorizations and cookies from Apache::Session
> > could be shared. That would take a lot of work.
> 
> Apache is dominant, yes, but I don't like the idea of IC depending
> on it.

That was never the intent. I said "Apache-style". The integration
with Apache is no different than the integration with Postgres or
MySQL -- it is an enhancement and is not central.

I believe that the IC team is one of the few who really work hard
at making a complex application less and not more dependent on
specific software packages. That is why you don't see me putting
subqueries or database-specific SQL in IC pages, even though in
some cases it would be quite a bit easier.

At this point SQL has taken the day in database land, though,
and I have given up enhancing the DBM stuff. My thoughts on
trying to make it multiuser have gone away as MySQL and Postgres
become routine on most every server. It is simply not worth
the effort.

> Coupling tightly not only means other web servers
> won't work but it may well lock people even into a specific version
> of Apache.  That **decreases** reliability.  I don't need software
> that breaks when I run apt-get upgrade.  The biggest chunk of our
> downtime is upgrade time.
> 
> You get something like Apache2 + mod_perl which might well
> require perl5.8+ and the upgrade path becomes a nightmare or
> even impossible for anyone not running out-of-the-box configurations
> with specific versions.  We stay on the bleeding edge so it
> is usually easier for us.
> 
> IC doesn't use mod_perl - though it is there in config, why? - 

It can run under mod_perl as of 4.9.

> which doesn't work anyway with Apache2 so my head is starting to 
> really hurt because I can't put it on same machine as this and that
> site.  Clear interface, separate daemons and separate processes
> please!

I think we have that. The mod_perl integration is not required
nor is it the default. 

> > 
> > Since we are close to a code freeze on Interchange, and I have
> > several tasks to do before that happens, I will probably not
> > get to that sweeping a change.
> > 
> > So bottom line, I would like to keep .access checking the sam
> > and have any future work and complexity go toward something more
> > useful like emulating Apache Options settings.
> 
> In this particular case, where the web server can do it, why
> should IC do it?

Here I believe you have a point. Why should IC do it? Probably it
should not, other than being able to share authentications and
grant rights.

You can do an awful lot with LocationMatch and Apache. The only downside
is that you must have control over your httpd.conf to get that work.
Since we don't really position IC for shared hosting environments, that
may be a match.

Still in all, if we are to fight the coupling of IIS and things like
ASP and Cold Fusion we have to provide some forays of our own into
"enterprise" capability. Apache is a viable outlet for that. It will
not get to the point of requiring Apache, of that you can be sure.

As for "Apache-style" to do other things, I mean using IC capabilities
and leveraging user understanding of its directives to make our stuff
better. For instance, it might be nice to have:

	<Limit set return>
	require group default
	</Limit>

That would limit the actions "set" (database update) and "return" (values
update) to a logged in user which would be nice in many ways.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike@perusion.com>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer