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
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
Helmut Tessarek wrote:
Password validation:
Many web applications use a 32-character hexadecimal md5 hash, since PHP returns
such a value for its md5 function. Unfortunately the apr_password_validate
function does not validate such a value. Since almost every authnz backend uses
this function,
On 24.03.2007 14:54, Tom Donovan wrote:
If procedures only require input parameters and return a result set
(like the example procedure GROUP_SP in mod_auth_ibmdb2) - they can be
invoked by apr_dbd_select with the SQL statement:
CALL GROUP_SP(?)
If this is the case then DBD does support
Joachim Zobel wrote:
Am Donnerstag, den 22.03.2007, 14:03 +0100 schrieb Helmut Tessarek:
Writing stored procedures is usually part of the DBA, but if the database server
is not on the same machine as the web server, stored procedures are most of the
time faster than SQL statements invoked from
Helmut Tessarek wrote:
Caching:
I've just changed my caching algorithm to use APR, so it must be fairly easy to
either add caching to the DBD framework or to write its own caching backend.
Regarding the modularity, an own autnz caching backend would be best.
So all other expensive providers
On Thu, 22 Mar 2007 11:23:18 +0200
Graham Leggett [EMAIL PROTECTED] wrote:
Helmut Tessarek wrote:
Caching:
I've just changed my caching algorithm to use APR, so it must be
fairly easy to either add caching to the DBD framework or to write
its own caching backend. Regarding the
On Wed, 21 Mar 2007 22:59:41 +0100
Helmut Tessarek [EMAIL PROTECTED] wrote:
Hi everybody,
Nick Kew suggested that I should post my findings and ideas regarding
the DBD framework, APR and caching.
Indeed. I think we stand to gain insights, and perhaps also code,
from discussing it here.
On Thu, March 22, 2007 2:10 pm, Nick Kew wrote:
IME the LDAP code tends to be rather inward-looking and isn't always
the easiest to re-use (and util_ldap_cache.h lacks the prototyping
and documentation of a public API). If you can find a round tuit for
making that jump from specific to
Hi,
Don't tinyurl references expire after a few days (or weeks or
something)? Mailinglists, by contrast, are archived. I understand
you may want to retain the flexibility to invalidate that link
yourself, but a mention of the top of your repository at
www.evermeet.cx/cvs/ surely wouldn't
Nick Kew wrote:
Is that the same issue as
http://issues.apache.org/bugzilla/show_bug.cgi?id=41925
No. The bug describes encryption but I was talking about validation.
Furthermore the bug shows off a completely other part of the API.
My working assumption with DBD is that creating stored
Am Donnerstag, den 22.03.2007, 14:03 +0100 schrieb Helmut Tessarek:
Writing stored procedures is usually part of the DBA, but if the database
server
is not on the same machine as the web server, stored procedures are most of
the
time faster than SQL statements invoked from the client.
The
Hi everybody,
Nick Kew suggested that I should post my findings and ideas regarding the DBD
framework, APR and caching.
Just a short paragraph on how this all came up:
I've written an authnz module for IBM DB2. The reason why I haven't used the DBD
framework was the lack of features that I have
13 matches
Mail list logo
