mod-auth-devel

[Mod-auth-devel] mod_authn_dbi

[Axel G. <ag...@pr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



moin,

i spent a few hours working on mod_authn_dbi today,
but it seems the "mangle username" feature will not
be possible without changing apaches authn-interface.
i can change the value of the username string, but i
cannot change the string itself, so the new username could
only be as long as the old one.

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....

well, we'll see...


i had a look through the TODO file and have a few comments:


> 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.


>      - Some Sort of Official Security Audit
>      - Benchmarks?
>           - vs File, DBM and No Authentication?
>           - High Load Throughput?
>           - with mod_authn_cache?
>           - Classic MySQL, PgSQL, SQLite.. etc?

>      - 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...


>      - Update Documentation (README Specificly needs to be reworked)

i will try to add some documentation into it.

>      - 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.

>      - 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?

> 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.


>      - Use APXS for Makefiles [chip]
>      - Remove extra files from CVS (autoconf/make stuff we don't need)
>[chip]
>      - 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?
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.

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?


>      - Mangle usernames [axel]

postponed.

>      - More SQL Variables [axel]

mainly done..

>      - Support mod_dbi_pool [chip?]

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

what do those changes do?

>      - 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_*.

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". :(



tty, axel



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFACYaRHAHtNfez9GYRAuE6AJ0fVX1o/BbUzmqF+VAvdlZC+H3RcACfTvQf
ZbP0Rrc+MrHwtbs2J1+hWTQ=
=6CHu
-----END PGP SIGNATURE-----

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