Aaron Stone wrote:
On Sun, Jan 30, 2005, Paul J Stevens <[EMAIL PROTECTED]> said:
Aaron Stone wrote:
I don't mind at all. Let me know if you have any questions about my screwy
code in there. First suggestion: throw away the lists of lists of lists.
That was me not understanding how to do it any smarter.
Like how much smarter is your current understanding then?
The ldap api has three sets of functions for returning parts of results:
ldap_first/next_entry, ldap_first/next_attribute, ldap_first/next_value
I guess my solution maybe wasn't too far fetched, now that I think about
it:
list of entries -> each is a list of attributes -> each is a list of
values.
Maybe the main problem is that I think I'm using the field_t type in
places where there should be a malloc. Turns out field_t declares static
buffer.
So basically the nested list setup is viable, but allocation has to be audited. Roger that. But a quick
inspection doesn't show any glaring memory leaks.
Maybe I'll convert to a nested hashtable with appropriate accessors, but for
now, I'll leave it as is.
It's the alias management where some real plumbing is missing. So I won't
be unfamiliar with the ldap api for much longer I guess...
This is more about the schema than the api, really. Take a look in
auth_check_user_ext, you'll find this:
/* If checks < -1, we're looking for a specific DN, not a search. */
if (checks < -1) {
snprintf(query, AUTH_QUERY_SIZE, "%s", address);
j = __auth_get_one_entry(query, fields, &templist);
} else {
snprintf(query, AUTH_QUERY_SIZE, "(|(%s=%s)(%s=%s%s))",
_ldap_cfg.field_mail, address,
_ldap_cfg.field_mailalt, _ldap_cfg.mailaltprefix,
address);
/* we're just using a little counter variable,
* since we'll use it in the for loop later */
j = __auth_get_every_match(query, fields, &templist);
}
In some ways, this actually reflects that Active Directory uses a DN as
the target of a forward rather than an address. There's a different syntax
for outside forwards, which I'm not sure if I even handle at all (never
needed it on the AD system I wrote this for).
This can be handled by using the call ldap_is_ldap_url to determine if
it's a forwarding DN or might be an actual address.
Ok. noted.
Btw, I'm using dsn.c's logic as definitive regarding delivery policy, right?
Yes, I suppose, but there should be a reasonable abstraction away from
needing to worry about this? I guess I'm not sure what you're asking :-P
dsnuser_resolve determines the entry points for authXXX.s regarding delivery. That's where the actual logic is
defined, and what is expected from auth_check_user_ext.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
