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. however, if this _is_ the right spot,
here's my question:
--
i'm trying to use dsOpenDirServiceProxy to auth a user against a
remote server. i have
not yet discovered how to use that api correctly. the apple
documentation confuses me by
saying some contradictory things. for example, in referring to: the
dsOpenDirServiceProxy
api, the documentation (in one place) states:
"... Must be called before any other Directory Services API calls ..."
all of which require an incoming tDirReference parameter. but that's
why we're calling
dsOpenDirServiceProxy in the first place - to _acquire_ a
tDirReference! you can't get a
tDirReference before you dsOpenDirServiceProxy successfully returns!
now, i can allocate
a _local_ dsOpenDirService and get one of these, but the fact that
the ds*Alloc* calls
take this tDirReference as a parameter make me believe that these are
allocated within,
and for use by a particular tDirReference object. but the
documentation doesn't help me
understand that in enough detail.
- 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.
- 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?
- is there another source of more authoritative documentation for the
ds apis?
if that all seems clear, i have specific questions on the
dsOpenDirServiceProxy API
itself, regarding one argument in particular: inAuthStepData.
inAuthStepData says it contains a username/password combination
packed into a
dsDataBufferAllocate-d buffer. the docs specifically state:
--
On input, a value of type tDataBufferPtr created by calling
dsDataBufferAllocate pointing
to a tDataBuffer structure that contains the data necessary for this
stepin the
authentication process. For the first step in the authentication
process, inAuthStepData
typically consists of four bytes specifying the length of a username,
followed by the
user name in UTF-8 encoding, followed by four bytes specifying the
length of the
password, followed by the password in UTF-8 encoding.
--
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?
- 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?
ok, that's a lot for one email. thanks very much!
bob
_______________________________________________
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
