Re: DBD framework, APR, caching

[Helmut Tessarek <te...@evermeet.cx>]

On 30.03.2007 05:24, Tom Donovan wrote:
> One problem with your patch is that it wouldn't distinguish between a
> 32-character password (plain-text passwords work on Windows) and an md5
> hash.

This is correct, but plain text passwords are only supported on Windows because
of the lack of the crypt functionality on Windows.
So it would be unfair not to allow other algorithms for UNIX, but I think I have
another solution to this.
Another possibility woulde be either:
1) only do my check for non Windows platforms
or (which would be best for both worlds)
2) do the check, and if it does not validate, use plaintext on Windows

I have attached the new patch (for 2).

In this case my patch does not change anything, except that it also validates
32-char md5 hashes on all systems.

> I think it would be better to use a prefix, like {MD5}.  Not perfect,
> but the {SHA1} prefix has already set a precedent for this in apr.  If
> the database contains only the 32-char hash, you could use an SQL stmt
> like this:
> 
>  "SELECT '{MD5}' || Password AS Password FROM Users WHERE UserName = ?"

When using a prefix, then you would have to change either the rows in the table
or you would have to use a statement as you have suggested.
If you change the statement then only 32-char md5 hashes can be used for
authentication.
The good thing when using apr_password_validate is that you can use all the
different hashes in one table.

> SP errors seem to be handled the same as with ordinary SELECT statements.

Oops, I think my question was not clear. My fault. I know how to handle errors
in respect of coding. I meant how to handle them logically.

In DB2 you can define SQLSTATES within a SP for different exceptions. Or you
could get a warning, even if you get the correct result set. This makes it a
little bit hard to handle errors and warnings...
But since it is already possible to use SPs, these questions are obsolete.

> I've got an ODBC DBD driver I've used for several weeks now.  I'm still
> struggling to code the apr 1.3 version of it, but if you (or anyone)
> would like to look over the apr 1.2 version - help yourself to
> http://www.tomdonovan.net/download/dbd_odbc.zip
> Maybe it will help you to write your apr_dbd_ibmdb2 driver.

Thanks, I will have a look at it. Well I guess that I won't have to change very
much of it to use it for DB2, because as you said, DB2 CLI is almost the same as
the ODBC API. It could even be possible that you don't have to change anything
at all.
See the unified ODBC driver for PHP. Before the native driver for DB2 was
written, the unified ODBC driver was used to access DB2 natively.

Regards,
   Helmut

Re: DBD framework, APR, caching

[Paul Querna <pq...@apache.org>]

Helmut Tessarek wrote:
> On 30.03.2007 05:24, Tom Donovan wrote:
>> One problem with your patch is that it wouldn't distinguish between a
>> 32-character password (plain-text passwords work on Windows) and an md5
>> hash.
> 
> This is correct, but plain text passwords are only supported on Windows because
> of the lack of the crypt functionality on Windows.
> So it would be unfair not to allow other algorithms for UNIX, but I think I have
> another solution to this.
> Another possibility woulde be either:
> 1) only do my check for non Windows platforms
> or (which would be best for both worlds)
> 2) do the check, and if it does not validate, use plaintext on Windows
> 
> I have attached the new patch (for 2).
> 
> In this case my patch does not change anything, except that it also validates
> 32-char md5 hashes on all systems.
> 
>> I think it would be better to use a prefix, like {MD5}.  Not perfect,
>> but the {SHA1} prefix has already set a precedent for this in apr.  If
>> the database contains only the 32-char hash, you could use an SQL stmt
>> like this:
>>
>>  "SELECT '{MD5}' || Password AS Password FROM Users WHERE UserName = ?"
> 
> When using a prefix, then you would have to change either the rows in the table
> or you would have to use a statement as you have suggested.
> If you change the statement then only 32-char md5 hashes can be used for
> authentication.
> The good thing when using apr_password_validate is that you can use all the
> different hashes in one table.

IMO, these are the wrong approaches, changing APR to support this, that is.

I would highly prefer we just add a 'password format' command to
mod_authnz_dbd.  Just like mod_authn_dbi had:
http://mod-auth.sourceforge.net/docs/mod_authn_dbi/#authndbipasswordformat

-Paul