hi, apologies if this isn't the right place to post a directory
services question. if
not, pleasepoint me to the proper spot. i might have missed the
proper list in the
giant-list-of-apple-dev-lists.
I think darwin-dev might be a marginally better bet.
and yet, some of the parameters to dsOpenDirServiceProxy need to be
allocated via:
all of which require an incoming tDirReference parameter.
Well, they don't actually do anything with the tDirReference these
days, since all the custom allocator stuff has been removed.
- do you have any example code? i'm using the CryptNoMore example as
a baseline, but it
only does local auth. i'm attempting to extend it, but i'm really
just guessing, since
the docs are incomplete.
I used to have some, but I'm not sure if I've lost it over the years.
I might have a look for it, but I can't do so immediately.
- can i allocate blocks of memory using the tDirReference returned by
a dsOpenDirService
and pass those on to other directory services apis that might use
different
tDirReference?
Yes. In fact, I believe you can just pass a NULL tDirReference (or is
it a 0? I forget whether they're pointers or not. I'm seeming to
remember that they're not, they're keys into some big lookup table and
it's all horrendous...)
- is there another source of more authoritative documentation for the
ds apis?
The source ;-)
two questions on that:
- is the four-byte length of the username represented as a 32-bit
integer, unsigned int,
etc? and what's the endianness?
Unsigned 32-bit integer, host endian.
- the api says that this data 'typically' consists of packed uname
length, uname, pw
length, pw data elements. are there other 'atypical' formulations of
this structure, and
if so, what are they, and why might i use them?
Well, it depends on the authentication method you're using - in theory
dsOpenDirProxy uses the same sort of authentication process as
dsDoDirNodeAuth, but I can't think of any situations where that's
particularly useful.
-- Finlay
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
