apple / ccs-calendarserver

The Calendar and Contacts Server.
https://www.calendarserver.org
Apache License 2.0
486 stars 136 forks source link

Search via email address in cachingappleopendirectory fails #267

Closed macosforgebot closed 15 years ago

macosforgebot commented 15 years ago

ebach2@… originally submitted this as ticket:335


Using trunk/head, with users in opendirectory, ldap set to /127.0.0.1 instead of /Search, with iCal from 10.5.6, if I connect as user 'dave', and create an event inviting user 'sarah@…', iCal will auto-complete the name fine and pass the email address to DCS.

However, in the case where the cache misses (user sarah hasn't connected since the server was last started), it does an OD search for sarah@…, which fails to find the user (there is a user with that address in emailaddress, verified both with a DS dumping tool I wrote and in Directory.app). However, if I first make sure that user sarah has connected, then her info gets loaded into the cache, and she is properly invited to the event.

macosforgebot commented 15 years ago

ebach2@… originally submitted this as comment:1:⁠ticket:335


Adding debug log of event

macosforgebot commented 15 years ago

ebach2@… originally submitted this as _attachment:DCS_debug_log.txt:⁠ticket:335_


log messages of failure

macosforgebot commented 15 years ago

ebach2@… originally submitted this as comment:2:⁠ticket:335


Replying to ebach2@…:

Adding debug log of event

To follow up, in cachingappleopendirectory.OpenDirectoryService.queryDirectory(), it catches an exception from the query:

except opendirectory.ODError, ex:

if ex.message[1] == -14140 or ex.message[1] == -14200:

Unsupported attribute on record - don't fail

[I added this debug line]

self.log_debug("opendirectory.queryDirectory unsupported attribute on record - don't fail %s" % (ex.message[1],)) return

When I re-rerun everything, this logs: 2009-04-26 13:35:45-0700 [-] [caldav-8010] [-] [twistedcaldav.directory.cachingappleopendirectory.OpenDirectoryService#debug] opendirectory.queryDirectory unsupported attribute on record - don't fail -14200

macosforgebot commented 15 years ago

ebach2@… originally submitted this as comment:3:⁠ticket:335


To follow up, it also fails even when using /Search for the ldap node.

But within the dscl cli tool, the search for the email address succeeds:

search /Search dsAttrTypeNative:mail sarah@…

Users/sarah dsAttrTypeNative:mail = (

"sarah@…"

)

macosforgebot commented 15 years ago

ebach2@… originally submitted this as comment:4:⁠ticket:335

macosforgebot commented 15 years ago

ebach2@… originally submitted this as comment:5:⁠ticket:335


Replying to ebach2@…:

To follow up, it also fails even when using /Search for the ldap node.

But within the dscl cli tool, the search for the email address succeeds:

search /Search dsAttrTypeNative:mail sarah@…

Users/sarah dsAttrTypeNative:mail = (

"sarah@…"

)

I'm not sure why, but:

search /Search dsAttrTypeStandard:EMailAddress sarah@…

returns no entries (where searching for dsAttrTypeNative:mail returns the proper record)

But my DirectoryServices exploring app (which just does a dsGetRecordEntry, then iterates over all the attributes for the record), returns both dsAttrTypeNative:mail and dsAttrTypeStandard:EMailAddress entries, which the dscl tool doesn't display. And I've verified in DirectoryUtility.app that EMailAddress is mapped by the mail ldap attribute.

macosforgebot commented 15 years ago

ebach2@… originally submitted this as comment:6:⁠ticket:335


...

And doing read /Search/Users/Sarah shows both

dsAttrTypeNative:mail: sarah@… EMailAddress: sarah@…

and

search /Search EMailAddress sarah@… also returns no results

and the wiki seems to strip off the 'test.com' from everywhere that you would expect the email address to be in the search commands

macosforgebot commented 15 years ago

@m0rgen originally submitted this as comment:7:⁠ticket:335


Thanks for looking into this. What I found was that our pyopendirectory queries are coming back empty when we do a search on email address and ask for users, groups, resource, and locations. If we only look for users and groups, the query works. I have updated trunk with this workaround.

macosforgebot commented 15 years ago

@wsanchez originally submitted this as comment:8:⁠ticket:335


Should be all set now