Igor Brezac wrote:
Yeah, I'm sure it will. I wish I could do it in one query though.. How often does the ptloader get called on? Will the pts cache here help at all? What exactly does the pts cache do? ( I realize that it probably caches authorizaton info, but is it always consulted first, before asking the ptloader to look up the information again?)I see. I did not realize you were going to retrieve groups with another search filter. This should work.
I don't see this in ldap.c. The identifier group:xxx gets passed into pts as the identifier and rejected by the canonicalizer because of the colon. So the canonicalized identifer is null throughout the rest of the code. I don't see a test for group: anywhere ( or in afskrb.c either ). So assuming that we just want to make sure that the group name is valid, and that the canonicalizer should be fixed to recognize group:xxx syntax, what then am I suppose to do with it? Returning NULL seems to Do Bad Things, and I don't see an entry for canonicalized group in the auth_state struct..Thats what I thought as well. I have already written the code the does
the user group membership check in ldap.c, but when I went to test it
via cyradm - I created a folder, and tried to set a group:xxx ACL and at
that exact point the identifier group:xxx was passed into the pts and I
don't know what to do with it (do we check to see if its a valid group??
I didn't see what to do in the original ldap.c code, afskrb.c, or any
other file. Perhaps I'm thick, but I just wanted to make sure there
wasn't anything else I was missing before going on).
You do not need to do anything with this. The identifier is passed to pts for canonicalization, the group is not validated.
Thanks, Tim
