Caller ID Superfecta

That would be interesting. I wonder if a review of that module might provide us with what we need to fit it into our existing framework / style for data sources? Thoughts?

I think this would be a super good source. I was thinking about this last week because I would like to do lookups against my Kerio mail server. It supports LDAP for the contacts. I guess MS Exchange could be a source as well through LDAP?!

I can have look at it but I am not so familiar with LDAP

By all means - take a look at it. LDAP is a pretty simple protocol as I recall. I'm willing to bet it wont be a nightmare to get this source ready.

The following code fragment came from here:
http://forums.devshed.com/showpost.php?p=860612&postcount=14

It is posted here as general researchinto accessing ldap via php.

 1 // connect
 2 $ad=ldap_connect("ldap://my.domain.com")
 3 or die ("Couldn't connect to my.domain.com");
 4 
 5 //Set protocol version
 6 ldap_set_option($ad, LDAP_OPT_PROTOCOL_VERSION, 3)
 7 or die ("Could not set ldap protocol");
 8 
 9 // Set this option for AD on Windows Server 2003 per PHP manual
10 ldap_set_option($ad, LDAP_OPT_REFERRALS, 0)
11 or die ("Could not set option referrals");
12 
13 // bind
14 // per our sysadmin, anonymous binds are not allowed.
15 // but apparently, no error is generated.
16 $bd=ldap_bind($ad,"AD_user_name","AD_user_password")
17 or die ("Couldn't bind to my.domain.com");
18 
19 // search
20 $dn = "OU=User Accounts,OU=User Accounts and Groups,DC=my,DC=domain,DC=com";
21 echo "Searching for (department = Chemistry) ...";
22 
23 $rs=ldap_search($ad,$dn,"department=CHEMISTRY")
24 or die ("Failed to search"); 
25 // var_dump($rs);
26 // var_dump(ldap_error($ad));
27 // var_dump(ldap_errno($ad));

It may be useful in our efforts to create an ldap datasource..

Another linkof interest:

http://www.devshed.com/c/a/PHP/Using-PHP-With-LDAP-part-1/

I had some time to look into this and have made some progress.

I have created an OpenLDAP service on a test machine and can query it from the command line.

The LDAP telephonenumbermatch schema is almost intelligent and can ignore spaces and dashes in numbers, so that 0121-333-1111 is the same as 01213331111.

The issue is when you have +44-121-333-1111 then this does not match 0121-333-1111.

Would an acceptable approach be to force the CID match rule in the scheme to match your LDAP convention e.g 0+44|44ZXXXXXXXXX

The approach is to strip the +44 or the leading 0 for UK numbers and use a wildcard at the start of the number.
The LDAP filter would then be:

(|(mobile=*1213331234)(telephoneNumber=*1213331234))

# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: (|(mobile=*1213331234)(telephoneNumber=*1213331234))
# requesting: cn telephoneNumber mobile 
#

# ldap1, people, example.com
dn: uid=ldap1,ou=people,dc=example,dc=com
cn: Bilbo Baggins
mobile: +44 7976 666666
telephoneNumber: 0121 333 1234

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Added source in r457.
Needs further testing.

To get around country codes and other formatting issues it relies on the CID match rule to set the CID to match the format the LDAP server has stored the numbers in.

My CID Rule is

44|ZXXXXXXXXX
01|1+XXXXXXXXX
02|2+.
07|7+.
08|8+.

LDAP server name parsing is now more robust with r463.
The source is ready for testing.

Lookups check mobile,office and home telephone numbers with a wildcard match.
At the moment the CID rule is relied upon to strip country code or leading zero for the number lookup.

I have tested locally against an LDAP server and getting fast results from the OpenLDAP server.
Code is there to accomodate SSL connects to ldaps, but I cannot test that in my environment.

At present, the DC string is derived from host name supplied e.g. "ldap.example.com" becomes "dc=ldap,dc=example,dc=com".
I am wondering if we should have an optional override for a different DC ?

Real world testing is required before this can escape into the wild.

My office has just been amalgamated with a much larger business that is married to Exchange/Outlook. I will be losing my simple elegant MySQL contact list in the process and am hoping that maybe I can still get CNAM from the new Exchange Server. The problem is, I don't know the first thing about Exchange, certainly not enough to discuss with the IT guys at the head office. Is this the lookup source I need to make this work?

lgaetz wrote:

Is this the lookup source I need to make this work?

Yes :-)

You will need to find the context. This can be done with the following

ldapsearch -h 192.168.100.74 -x -b '' -s base '(objectclass=*)' 'namingContexts' 

# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts 
#

#
dn:
namingContexts: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Added r495 to allow for case if the user does not know the OU to search.
Leaving OU blank will search the whole tree.

Is there a non-standard dependancy for this lookup, with debug I am getting:
"LDAP functions not available"

lgaetz wrote:

Is there a non-standard dependancy for this lookup, with debug I am getting: "LDAP functions not available"

That is why I check for the functions.

You can resolve the dependency with

yum install php-ldap

If non-standard dependancies are necessary, it needs to be documented somewhere where users will see it. I thinking in the mouseover help somewhere.

Sorry, I completely forgot that it was required. I will update the hover text and debug text to reflect the dependency.
I would assume that if the server is in an environment that uses ldap they would have installed it... but a warning/reminder won't hurt.

lgaetz wrote:

If non-standard dependancies are necessary, it needs to be documented somewhere where users will see it. I thinking in the mouseover help somewhere.

Added in r496 to help text and debug text.

No apology necessary. Your assumption may be good for most, but I'm an exchange newbie and I'm sure I won't be the only one. Exchange is huge, and I wonder why there is no demand for this lookup source.