You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2001/09/24 21:36:28 UTC
[SUGGESTION] mod_auth_xxxx API
Well, there is a module called mod_auth_any and basically that's what I'm
talking about, but I'm offering another approach.
Almost all auth modules currently in the core distribution has a lots in
common so I'm suggesting the following:
1. make a generic auth module that will have a dso interface to
username/password/group feeding.
2. add the 'AuthInterface DB /path/to/auth_db.so' to server config (use hash
table lo load multiple interfaces)
3. load the following functions from that interface dll(auth_db.so)
"Interface functions":
a. ApacheAuthInitialize()
b. ApacheAuthTerminate()
c. ApacheAuthDatabase(flat-file or DSN or whatever);
d. ApacheAuthVerifyUser(username, password)
e. ApacheAuthVerifyGroup(groupname)
4. add the 'AuthInterfaceUse DB' to dir-config
5. use config directives like using standard htasscess file.
6. make auth_file.so, auth_db.so, auth_dbm.so
So what I'm suggesting is that we get rid of mod_auth, mod_autdb,
mod_authdbm and possibly others and make a Authorization module API instead
of writing and maintaining modules for different database file access
methods, and make tree separate interface modules one for flat-files, one
for db and one for dbm.
Using that API one could easily write a 'glue' interface to whatever
authorisation he wants, but if specific authorization is required like ldap
the old way still works.
Do you thing that this makes sense?
I would like to get into if there will be no vetoes.
MT.
RE: [SUGGESTION] mod_auth_xxxx API
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: Monday, September 24, 2001 10:04 PM
> To: dev@httpd.apache.org
> Subject: Re: [SUGGESTION] mod_auth_xxxx API
>
>
> On Mon, Sep 24, 2001 at 10:08:16PM +0200, Mladen Turk wrote:
> > It has fewer config directives then the old style.
> > For example you have AuthFile, AuthDBFile, AuthDBMFile etc,..
> > Using this approach you have AuthInterfaceUse and AuthFile only.
> > The AuthInferaceUse will call the proper database.
>
> You can't enforce the use of shared libraries. You can consolidate
> the code so that they use the same core code though. -- justin
Of course they can be statically linked like modules do, then they will be
in the hash table allready.
MT.
Re: [SUGGESTION] mod_auth_xxxx API
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Sep 24, 2001 at 10:08:16PM +0200, Mladen Turk wrote:
> It has fewer config directives then the old style.
> For example you have AuthFile, AuthDBFile, AuthDBMFile etc,..
> Using this approach you have AuthInterfaceUse and AuthFile only.
> The AuthInferaceUse will call the proper database.
You can't enforce the use of shared libraries. You can consolidate
the code so that they use the same core code though. -- justin
RE: [SUGGESTION] mod_auth_xxxx API
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: minfrin [mailto:minfrin]On Behalf Of Graham Leggett
> Sent: Monday, September 24, 2001 9:44 PM
> To: dev@httpd.apache.org
> Cc: New-Httpd
> Subject: Re: [SUGGESTION] mod_auth_xxxx API
> How is this different from what we have now? As I read it all you're
> suggesting really as that a new module gets created between the various
> auth modules and the core - but this common functionality already exists
> in the core anyway, so I'm not sure what this achieves? What worries me
> at first glance is that something that has a few config directives now
> has a whole lot more config directives that achieve the same thing.
It has fewer config directives then the old style.
For example you have AuthFile, AuthDBFile, AuthDBMFile etc,..
Using this approach you have AuthInterfaceUse and AuthFile only.
The AuthInferaceUse will call the proper database.
> What would be useful is to go through all the modules and form a library
> of common routines and common configuration, and either build that
> module into the core, or allow it's use as a separate module DAV and
> proxy style.
That's what I'm talking about. The difference between the mod_auth,
mod_authdb and mod_authdbm is only in the way they get
username/passwor/groupname from the file.
Re: [SUGGESTION] mod_auth_xxxx API
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> So what I'm suggesting is that we get rid of mod_auth, mod_autdb,
> mod_authdbm and possibly others and make a Authorization module API instead
> of writing and maintaining modules for different database file access
> methods, and make tree separate interface modules one for flat-files, one
> for db and one for dbm.
How is this different from what we have now? As I read it all you're
suggesting really as that a new module gets created between the various
auth modules and the core - but this common functionality already exists
in the core anyway, so I'm not sure what this achieves? What worries me
at first glance is that something that has a few config directives now
has a whole lot more config directives that achieve the same thing.
What would be useful is to go through all the modules and form a library
of common routines and common configuration, and either build that
module into the core, or allow it's use as a separate module DAV and
proxy style.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Apache 2.0 release plan was Re: [SUGGESTION] mod_auth_xxxx API
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Sep 24, 2001 at 01:54:26PM -0700, Ryan Bloom wrote:
> > To me, a useful release plan is one that:
> > * tells developers working on httpd-2.0 what the important things to
> > work on for 2.0-GA are,
> > * tells 3rd-party module developers what sort of interface they can
> > expect, and
> > * tells end users what feature set and performance characteristics
> > they can expect.
> >
> > The "tag when you believe it is appropriate" model is an effective process
> > for software builds, but not necessarily for product releases.
+1.
> We specifically stated that we were not going to do those three things. The point
> to this releaes model, is to allow the code to keep moving forward.
>
> You all may notice that I raikl against this release process quite often, and ask
> people not to make sweeping changes, because we need to release. However,
> this is the model that was decided upon a while ago.
Sweeping changes, eh? I wouldn't know anyone attempting to do that...
I completely agree with Brian here. A release plan and a tag strategy
are very different.
We can tag at any time to produce a build, but we don't have any
guidelines which say, "These need to be addressed or met by 2.0-GA."
We should have performance characteristics (i.e. comparable to 1.3?),
features (SSL), a degree of robustness (survives httpd-test and
daedalus load for 48 hours?), etc. Otherwise, a tag is just a
shot-in-the-dark.
You and OtherBill keep saying that 2.0 is "really soon now" and that
we can't commit or do certain things because of that. IMHO, that's
what Roy was wailing about. I have no clue what you mean by 2.0.
-- justin
Re: Apache 2.0 release plan was Re: [SUGGESTION] mod_auth_xxxx API
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 24 September 2001 01:45 pm, Brian Pane wrote:
> Ryan Bloom wrote:
> >On Monday 24 September 2001 01:27 pm, Justin Erenkrantz wrote:
> >>On Mon, Sep 24, 2001 at 02:49:08PM -0500, William A. Rowe, Jr. wrote:
> >>>Yup, that's the ticket. For 2.1 development. If we keep this up, there
> >>>will never be a 2.0 release this year :(
> >>
> >>You know, we should come up with a *RELEASE PLAN* like the Tomcat
> >>people do.
> >>
> >>I've said it before (it was largely ignored last time):
> >>
> >>"How do we know when we're there if we don't know where we're going?"
> >
> >We have a release plan. An engineer tags whenever they believe it is
> >appropriate. That build is tested, and we give it a thumbs up/thumbs down
> >for alpha/beta/gold. The only reason a tag hasn't been laid recently, is
> > that we have known about showstoppers.
>
> To me, a useful release plan is one that:
> * tells developers working on httpd-2.0 what the important things to
> work on for 2.0-GA are,
> * tells 3rd-party module developers what sort of interface they can
> expect, and
> * tells end users what feature set and performance characteristics
> they can expect.
>
> The "tag when you believe it is appropriate" model is an effective process
> for software builds, but not necessarily for product releases.
We specifically stated that we were not going to do those three things. The point
to this releaes model, is to allow the code to keep moving forward.
You all may notice that I raikl against this release process quite often, and ask
people not to make sweeping changes, because we need to release. However,
this is the model that was decided upon a while ago.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Apache 2.0 release plan
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Sep 24, 2001 at 02:14:56PM -0700, Greg Stein wrote:
> For example, we're still finding interesting things to do with the brigades.
> We're still refining their functionality. We've got architecture issues with
> input filtering. And that is just one piece of the code.
Yeah, this leads me to believe that Apache 2.0-GA is a bit farther
off than some think. But, oh well.
"It's ready when it's ready."
-- justin
Re: Apache 2.0 release plan
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 24, 2001 at 01:45:32PM -0700, Brian Pane wrote:
>...
> To me, a useful release plan is one that:
> * tells developers working on httpd-2.0 what the important things to
> work on for 2.0-GA are,
And the developers will continue to work on what they *want* to work on.
There is no hierarchy, and no task assignments in (most) open source
projects.
If somebody is interested in getting a release done, then they will identify
the showstoppers (which are ideally already listed in STATUS) and work on
those.
The hope is that non-release-interested developers are not getting in the
way of release developers. I believe that is the case. Nobody is really
committing drastic revamps to the core without some review (e.g. Justin's
input filtering fixes). Changes to modules can (almost) never impact the
release stability.
> * tells 3rd-party module developers what sort of interface they can
> expect, and
Those can change up until release, and even after that. Hopefully, we keep
that at a minimum, but Apache is about writing the best code possible. And
that can mean that interfaces may have to change.
> * tells end users what feature set and performance characteristics
> they can expect.
We aren't organized enough to do that. That requires a management process,
which is more or less forbidden :-)
> The "tag when you believe it is appropriate" model is an effective process
> for software builds, but not necessarily for product releases.
Depends upon your point of view. Given the circumstances, I believe it to be
very effective. It is simply that Apache has had so much change over the
past couple years, that we still are not at a stable spot.
For example, we're still finding interesting things to do with the brigades.
We're still refining their functionality. We've got architecture issues with
input filtering. And that is just one piece of the code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Apache 2.0 release plan was Re: [SUGGESTION] mod_auth_xxxx API
Posted by Brian Pane <bp...@pacbell.net>.
Ryan Bloom wrote:
>On Monday 24 September 2001 01:27 pm, Justin Erenkrantz wrote:
>
>>On Mon, Sep 24, 2001 at 02:49:08PM -0500, William A. Rowe, Jr. wrote:
>>
>>>Yup, that's the ticket. For 2.1 development. If we keep this up, there
>>>will never be a 2.0 release this year :(
>>>
>>You know, we should come up with a *RELEASE PLAN* like the Tomcat
>>people do.
>>
>>I've said it before (it was largely ignored last time):
>>
>>"How do we know when we're there if we don't know where we're going?"
>>
>
>We have a release plan. An engineer tags whenever they believe it is
>appropriate. That build is tested, and we give it a thumbs up/thumbs down
>for alpha/beta/gold. The only reason a tag hasn't been laid recently, is that
>we have known about showstoppers.
>
To me, a useful release plan is one that:
* tells developers working on httpd-2.0 what the important things to
work on for 2.0-GA are,
* tells 3rd-party module developers what sort of interface they can
expect, and
* tells end users what feature set and performance characteristics
they can expect.
The "tag when you believe it is appropriate" model is an effective process
for software builds, but not necessarily for product releases.
--Brian
Re: Apache 2.0 release plan was Re: [SUGGESTION] mod_auth_xxxx API
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 24 September 2001 01:27 pm, Justin Erenkrantz wrote:
> On Mon, Sep 24, 2001 at 02:49:08PM -0500, William A. Rowe, Jr. wrote:
> > Yup, that's the ticket. For 2.1 development. If we keep this up, there
> > will never be a 2.0 release this year :(
>
> You know, we should come up with a *RELEASE PLAN* like the Tomcat
> people do.
>
> I've said it before (it was largely ignored last time):
>
> "How do we know when we're there if we don't know where we're going?"
We have a release plan. An engineer tags whenever they believe it is
appropriate. That build is tested, and we give it a thumbs up/thumbs down
for alpha/beta/gold. The only reason a tag hasn't been laid recently, is that
we have known about showstoppers.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Apache 2.0 release plan was Re: [SUGGESTION] mod_auth_xxxx API
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Sep 24, 2001 at 02:49:08PM -0500, William A. Rowe, Jr. wrote:
> Yup, that's the ticket. For 2.1 development. If we keep this up, there will
> never be a 2.0 release this year :(
You know, we should come up with a *RELEASE PLAN* like the Tomcat
people do.
I've said it before (it was largely ignored last time):
"How do we know when we're there if we don't know where we're going?"
-- justin
RE: [SUGGESTION] mod_auth_xxxx API
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> Sent: Monday, September 24, 2001 10:10 PM
> To: dev@httpd.apache.org
> Subject: Re: [SUGGESTION] mod_auth_xxxx API
>
> > It was just an idea between two boring soap operas :)
>
> I hope you aren't implying that there was an intervening,
> intersting soap opera (an oxymoron, no doubt :?)
No, my whife gives me then some spare time ::)
> Seriously, don't dismiss the idea, let's begin discussion, but
> target httpd 2.1 to introduce it. I expect 2.1 will further
> fracture the modules/http dependency and seperate the filesystem
> that Greg and I have been looking at.
Love to be in that. Allways wanna build a site inside the database.
MT
Re: [SUGGESTION] mod_auth_xxxx API
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Mladen Turk" <mt...@mappingsoft.com>
Sent: Monday, September 24, 2001 3:08 PM
> It was just an idea between two boring soap operas :)
I hope you aren't implying that there was an intervening,
intersting soap opera (an oxymoron, no doubt :?)
Seriously, don't dismiss the idea, let's begin discussion, but
target httpd 2.1 to introduce it. I expect 2.1 will further
fracture the modules/http dependency and seperate the filesystem
that Greg and I have been looking at.
Bill
RE: [SUGGESTION] mod_auth_xxxx API
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> Sent: Monday, September 24, 2001 9:49 PM
> To: dev@httpd.apache.org
> Subject: Re: [SUGGESTION] mod_auth_xxxx API
> > Almost all auth modules currently in the core distribution has a lots in
> > common so I'm suggesting the following:
>
> [snip]
>
> Yup, that's the ticket. For 2.1 development. If we keep this
> up, there will
> never be a 2.0 release this year :(
It was just an idea between two boring soap operas :)
MT.
Re: [SUGGESTION] mod_auth_xxxx API
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Mladen Turk" <mt...@mappingsoft.com>
Sent: Monday, September 24, 2001 2:36 PM
> Well, there is a module called mod_auth_any and basically that's what I'm
> talking about, but I'm offering another approach.
>
> Almost all auth modules currently in the core distribution has a lots in
> common so I'm suggesting the following:
[snip]
Yup, that's the ticket. For 2.1 development. If we keep this up, there will
never be a 2.0 release this year :(
I think we want to do the bare minimum of changes to make the server both
correct, and robust, and get it out the door.
Then we open the httpd-2.1 repository for business. I'd love to see the
changes you discuss, and which have been suggested by others, to fix the
authn/authz scheme. Let's keep that idea, just on hold for a bit.
Bill