[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: assertedValue in match functions

> All matching routines should be passed an assertion value.
> That value can be empty (zero-length) for some syntaxes, but
> it must always be present.

OK, then I guess I need to trace why I was getting { undef, NULL }
values.  BTW, the "idassert" code is now in back-ldap; I'll be
testing it a bit more tonight, and document it accordingly.

It does:
  - bind to the remote server with proxyAuthzDN identity and, optionally:
    - proxyAuthz as the local user
    - proxyAuthz as NULL
    - proxyAuthz as some fixed identity
    - don't proxyAuthz, i.e. preserve the proxyAuthzDN identity

optionally, the idassert feature can be activated based on some local
authorization that resembles (acutally, it exploits the same code) the
regular authzFrom procedure, i.e. the proxy can be configured with a list
of ID matching rules that select what identities (including anonymous) can
exploit the feature.  The code is enabled by default if LDAP_DEVEL is


> At 11:17 AM 5/13/2004, Pierangelo Masarati wrote:
>>I've recently had problems with uniqueMemberMatch being passed a null
>> assertedValue (i.e. bv_val = NULL and bv_len undefined) which was
>> causing the server to core dump.  I'm not sure if it's my fault or not,
>> because I was mucking with slap_sasl_* code and I might have poked
>> something bad in, but my question is: is it correct that *Match()
>> functions do not check for NULL assertedValues on input?  Should this
>> be impossible or what?  In that particular function there was a test (
>> asserted.bv_len > 0 ), which I turned into ( !BER_BVISNULL( asserted )
>> ) to solve my problem, but I note that otehr *Match() functions do not
>> check args.
>>Pierangelo Masarati
>>    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:
>> +390382476497

Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497