Re: [Mod-auth-devel] mod_authn_dbi

[Paul Q. <ch...@fo...>]

On Sat, 2004-01-17 at 12:01, Axel Grossklaus wrote:
> for this to work, apache would have to change the prototype
> from
> 
> authn_status (*check_password)(request_rec *r, const char *user,
>                               const char *password);
> 
> to
> 
> authn_status (*check_password)(request_rec *r, const char **user,
>                                const char *password);
> 
> i wonder if it would be worth asking on apache-devel since the
> answer would probably be "no". on the other hand, this still
> is a developer version. hmmm....
> 
> maybe a cleaner way would be to create a mod_map_username....
> 

I think most on dev@apache will advocate a seperate module, although
this might now be possible since it is still 2.1.

Another option is an ap_change_username(*r, char* new_username) type
function that would be in the core httpd.


> > 1.0.0
> >      - Testimonials / Who is using it - put it on the website?
> 
> well, that would really be interesting. i google for mod_authn_dbi every
> once in a while, but nothing really interesting turns up although it got
> mentioned in an article of a german linux magazine.
> (http://www.linuxenterprise.de).
> 
> well, people will probably start using it once apache-2.2 is out.

Yep, I think more people will once 2.2 is out.  Perhaps have a "In the
Press and Users" Section on the Website?

Cyan Worlds uses mod_authn_dbi in production for URU Clients.  I think a
few people are using the module in non-public ways aswell.

I also use it for my personal subversion repo... but i guess thats not a
good example of a 'user' :)

> >      - Create Patches to use 2.1 Authentication on 2.0.XX Releases?
> 
> that would be a really nice features...but probably also a lot
> of work...

Yup, I agree, it would take a large ammount of work. I was just thinking
of it as an option to allow more people to use it faster.  Most likely
will be dropped.


> >      - Test on all supported libdbi databases.
> >      - Test on 32bit, 64bit, little/big endian machines (might be a
> little exterme)
> >           - Linux x86
> >           - FreeBSD 5 x86 [chip]
> >           - Linux SPARC [chip]
> >           - AMD64?
> >           - Linux MIPS [chip]
> >           - PPC?
> 
> i can test it on solaris/sparc and maybe get someone to test it
> on IRIX.

Cool.  Doing all of these for every release might not be worth it (just
about all would be using GCC...), but I would at least like to try them
once before 1.0.

> >      - Create Binary Releases (rpm and deb?)
> >           * For now perhaps just create /debian/ and RPM .specs files,
> >             pending a 2.1/2.2 -release of Apache?
> >      - Get into Package Systems: (post 1.0?)
> >           * requires httpd 2.1 or 2.2 -release?
> >           - Debian
> >           - FreeBSD
> >           - Gentoo
> >           - Lunar
> 
> do you know which of these distributions include libdbi?

Debian, FreeBSD, Gentoo and Lunar all have libdbi.  Redhat 9 includes an
old version (at Cyan we built our own updated RPMs), but I think Fedora
Core has a newer one.  Don't know about SuSe.

> > 0.9.0
> >      - Include HTML/XML Documentation in Releases?
> >           - Bigger Files...
> 
> yes, including the docs into the tarball would be useful.
> not all the places where this will be used have internet
> access as an http-client.
> 
> i think putting a text-version of the doc-website into release tarballs
> would be a good idea.

Yup, should be a XSLT transformation away.

> 
> >      - Use APXS for Makefiles [chip]
> >      - Remove extra files from CVS (autoconf/make stuff we don't need)
> >[chip]

I think I will do those two today.

> >      - Have external people look for security issues (Prep for 1.0)
> >      - Create "security-issues" contact address (for whole auth project?)
> 
> in general, yes. but what domain would this address be under?
> do we want modauth.org?

I just might buy that or a simular domain today. I already need to renew
force-elite.com

> some pgp-key for security related stuff should also be available.
> 
> i will create a ho...@so... pgp-key and publish the keyid
> on the website for now.
> maybe you could do the same.
> 
> until we have decided this a note on the homepage saying "for security
> related issues, contact the develpers directly by email" should be ok.
> 
> 
> and we should start signing the releases with gpg.
> 
Agree. Should be done for 0.9

> i would also like to have some way to sign the sources as
> they go into cvs, although this is probably not going to
> be easy to do in a useful way..
> 
> do you have a pgp key?
> 
I used to (2+ years ago).  I haven't used it, and I beleive it might of
been completely lost in a format.  I will create one for
ch...@fo... today.

> >      - Support mod_dbi_pool [chip?]
I need to finish mod_dbi_pool first.  This might not be ready untill
1.0.

> >      - Merge In Cyan changes to Mainline? [chip]
> >          * These Officaly Might break how the Digest RFC Works...
> what do those changes do?

Basicly hash the username/password again with two secrets known 
by the client and server.  Prevents any Joe with Internet Explorer
from downloading the files.

> >      - Send Announcements:
> >          - SourceForge
> >          - FreshMeat [chip]
> >          - modules.apache.org [chip]
> >          - Other?
> 
> 
> i would also like to change the  dbi_result_get_* functions
> into  dbi_result_bind_*.
> 
I think we could do some good refactoring on the code right now. Not
just changing those functions, but some better re-organization.  It
shows its ... origins as an evil hack to get it working, and not a
proper design.

> the semantics of dbi_result_get_string are sort of broken.
> on error, it returns the string "ERROR" (which is also
> not documented), so you have no way to tell an error from
> a field containing "ERROR". :(
> 
Yes, this is a very bad part of the libdbi API.  I wish they would do it
another way, perhaps we should just create a patch todo it for them :)

-chip