Hi all,

I need a view that shows data directly from a LDAP search. I've created a 'dirty' proof of concept and it seems to work.

I know and agree that now the priority is for an stable release of LDAP module and news features like this have lower priority. What I'd want to know is if you're interested in integrating (in the future) this feature in LDAP module (maybe ldap_views submodule?) and how to do it. I'll do it but I need some help for integrating with LDAP module.

The approach is:
- to have a configuration page to define ldap connections (different from authentication?) and ldap queries (dn + filter) and [TODO]
- In views::add we'll have an entry for each ldap query created in previous step [TODO]
- In views definition we can select a generic LDAP column (LDAP Attribute) for each column mapping it to an attribute from LDAP search [DONE]

Ideas are welcome....


#16 ldap_views-7.x-2.x.tar_.gz15.08 KBslerby
#12 ldap.tar_.gz23.97 KBslerby
#2 ldap.tar_.gz24.05 KBslerby
Members fund testing for the Drupal project. Drupal Association Learn more


johnbarclay’s picture

I think view integration would fit in this module well. I would say put the effort into the query configuration interface such that it is reusable and generally keep things simple for starters. My thoughts on a long term approach follow:

I would think a structure like this:

module: ldap_data

  • Single interface for generating and testing an ldap query, filter, and returned attributes that leverages instances of ldap_server. (now)
  • Integration components that leverage these queries and perhaps some prebuilt queries
    • feeds fetcher and parser (later)
    • view integration (now)
    • other data integation (I'm not sure what all is out there. maybe services module). (later)
    • I think ldap profile fits in this structure also. Its just that beyond the query and ldap filter, there would need to be some php drupal filters such as whether a user account existed, what drupal role they had, etc. (later)
  • Some shared utility functions that perhaps belong in ldap_api
  • A common data structure for an ldap query(now)

An ldap server instance is just meant to be a permutation of connection credentials, physical server, etc. So I think an existing ldap server or one just for a query would be fine without an additional interface.

So to get what you need, sounds like all you need to do is add a user interface for the query.

I think this approach can be completely UI free in the module by providing the UI in the views, feeds, etc. intefaces/modules; for the sake of usability. But it doesn't need to be.

My feeling is that if its structured well, it could avoid a zillion ldap data modules and save a lot of code. But modules with too much in them can be hard to deal with.


We could just make an ldap query builder and executer module that could be leveraged by ldap_views, ldap_feeds, etc. It could have some caching options also. This would avoid a single overly complex module.

slerby’s picture

24.05 KB


Finally I have a first version of ldap_views. This is a **DEVELOPMENT VERSION**, so there are many things to correct/end and is open to any change. There are things to change/improve, too. I'm not an experimented Drupal developer, so there will be many things that must be drupalized.

I've created two (sub)modules: ldap_data and ldap_views

  • ldap_data: it uses a new table (ldap_data) with this fields:
    • did (data id): pk, varchar
    • name: a unique name
    • description
    • sid (fk --> ldap_servers.sid)
    • basedn: base dn for the LDAP request. Only used as a default basedn in views, but ca be rewriten in a view definition with contextual filters. Necessary for testing ldap_data? (testing is not implemented)
    • filter: LDAP filter for the LDAP request. Only used as a default filter in views, but ca be rewriten in a view definition. Necessary for testing ldap_data? (testing is not implemented)
    • attributes: the attribute list to request to the LDAP server
    • scope: scope of the search. The posible values are
      • LDAP_SCOPE_BASE => will use ldap_read for the data request
      • LDAP_SCOPE_ONELEVEL => will use ldap_list for the data request
      • LDAP_SCOPE_SUBTREE => will use ldap_search for the data request
  • ldap_views:

I've defined ldap_data like a new entity. I don't know if it's the best way to do it, but it seems an easy way to start.
If finally it stays as entity the 'attributes' field could be replaced with fields defined for the entity (?), but here we must to define a new entity type.
In that case we can consider the ldap_data as an entity type (like node types) and the entries recovered from the LDAP as 'nodes' (with an empty ldap_data table?).... I've had many doubts about it so
I've implemented the easiest solution, but isn't a closed question. Ideas are welcome.

I've not created an ldap_data data structure because it is automatically done by Drupal when you define an entity.

I've created the menu entries in the Structure menu. It isn't the best place, but it can be changed.

Steps for a new view:

  1. Create a new ldap_data definition
    1. Menu :: Structure :: LDAP Data Admin :: Add Search
    2. Fill the fields
      1. LDAP Server is a combo with the all rows defined in ldap_servers table
      2. LDAP Search scope defines the function to use for the request (base, one, subtree). I've not found a function for 'children' scope. The 'base' scope will bre rarelly used because it returns a unique entry, but can be usefull when requesting multivalued attributes (?).
      3. Select the attributes (one per row) to retrieve from LDAP (objecClass, DN and CN are automatically included)
      4. Select the base dn for the query: default value, it can be changed through 'Contextual filters'
      5. Optionally you can select a filter (leave empty or * for all attributes): default value, it can be changed through 'Filters'
  2. Create a new view
    1. In the 'Show' field select LDAP Search
    2. In the view definition open the Advanced :: Query settings section and select the ldap_data entry created in step 1
    3. In the Field section select the attributes to show in the query: the 'LDAP Attribute' is a generic field to select an attribute defined in step 1.2.3
    4. Optionally you can select a Sort criteria, Filter(s) and/or Contextual Filter(s)

This is only an approach and is open to any change. Ideas are welcome.

* Implement the test for a ldap_data definition
* Add/Improve watchdog support
* Documentation

johnbarclay’s picture


I have the equivelent of ldap_data in head in 7.x-2.x called ldap_query with the same basic functionality. It leverages an ldap server instance, and builds and stores a query. We should work these together. Do you have a strong preference for the ldap data name, or do you think ldap query captures the essence of this?

I expect to use this to build fetchers for the feeds module for moving ldap queries into nodes, user profiles, etc. Views is another use case.


Is this integration with the "Views" module? Or its own display of data? If its not views module integration, we should rename it ldap_display or something that won't confuse people.

slerby’s picture

ldap data ---> ldap query: no problem with the rename

ldap query: it wants to be integration with Views module. It manages the fields, filters and sort criteria and it has also a query plugin to request the data from ldap. Like I said I'm not an expert Drupal developer and perhaps it needs a reorganization.

What do you think (open question to anyone interested) about ldap_query as an entity? Like I said I think this could be an entity type so the entity's instances would be the ldap entries recovered from ldap server (with an empty drupal table for this data because we don't want to store them). In this way we could substitute the attributes field in ldap query with drupal fields like any other entity. We'd have a better integration with views selecting the ldap query like an entity bundle (like node types) and the fields like any other drupal field instead of a generic ldap attribute.

I've included dn, cn and objectClass like 'native' ldap fields. Any other one to include?

The latest version of ldap 7.x-2.x in http://drupal.org/node/806060/release is from april 9th. Is there a newer version? Can you publish it in http://drupal.org/project/ldap like a new branch or where can I get it from?

johnbarclay’s picture

Do you mean the (1) dap_query configuration of the query or the (2) resulting ldap entries. For 2 I definately agree. For 1 I'm not sure if it justifies the overhead of an entity with all the fields.

Here is the head for ldap 2:
git clone --branch 7.x-2.x http://git.drupal.org/project/ldap.git

You can find these commands at:

slerby’s picture


I think data from ldap could be an entity, like nodes. In that case ldap_query would be the node_type because ldap_query defines the attributes (=fields) recovered from ldap server. In that case we could use drupal fields instead of defining attributes for recovering from ldap server. It offers a better integration with views (and with drupal in general). So I dont know if this is your 2) scenario.

johnbarclay’s picture

yes this is 2. The entity would be something like ldap_query_result and the results would be instances of that entity class.

slerby’s picture

Ok, I agree.

I've been reading the ldap_query module in branch 2. I miss the scope field to select between ldap_search, ldap_read and ldap_list for data retrieving from ldap server.

terminus’s picture

I need functionality like this for Drupal 6. How easy would the module be to backport? Otherwise, any other suggestions to show a list of users' profile information from their LDAP entry?

slerby’s picture

ldap_views is build under views 7.x-3.x. Views 6.x-3.x is in dev version. I don't know how different should be for views 6.x-2.x because I've done nothing like this for Views 2. The main process is in excute() function in ldap_views_plugin_query_ldap.inc file (this plugin doesn't exist in Views 2).

The handlers manage the fields to show, filters and arguments.

johnbarclay’s picture

The scope can be added. I'm focused on the 7.x-1.x branch now, then will get the 2 merged. I'll apply any patches against 7.x-2.x-dev before I merge, so patches against it will apply cleanly.

slerby’s picture

23.97 KB

This is the updated last version with minor changes. The ldap_data module will be replaced with ldap_query when published.

johnbarclay’s picture

The 2.x branch is now current with the 1.x branch. This should make this easier to finish and generate the patch. Let me know if you need commit rights and when you want stuff put into git.

Also, any feedback on http://groups.drupal.org/node/159604 would be appreciated. There is a general thread at #1115704: Drupal 7 Status Updates for things not relating to individual features, bugs, or support requests where.

johnbarclay’s picture

I read through your code. I think the choice of the entity really worked out nice, and kept the amount of code way down. I wish I would have used it for the ldap server data.

Also, There is new field type in drupal 7 we should probably leverage for our did, sid, etc. Its called machine_name (http://api.drupal.org/api/drupal/developer--topics--forms_api_reference....).

I also added some token code in ldap_servers that may be useful in the views module. Not really sure. A summary is at: http://drupal.org/node/1245736 and the token functions are in the second half of the ldap_servers/ldap_servers.functions.inc file.

slerby’s picture

I'll be on holidays until 30th and we have other modules to work on for our client, but I'll check it.


slerby’s picture

15.08 KB

This is the ldap_views (sub)module changed to use the ldap_query (sub)module.

Please report any issue, problem or query and I'll try to solve it.


johnbarclay’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev

Great!. I've been quite busy and have not found time to work on the "data" side of ldap. I'm doing a chipin/sponsorship push so I can put a couple weeks into this in early December.

I want to move ldap feeds, ldap query, and ldap views into the 7.1 branch and make them part of the 7.x-1.0RC. I feel these provide the foundations of data integration which the 7.2x branch can build on.

If the funding becomes available do you want to work on the query, feeds, views stuff? Does your company want any recognition of the ldap views work you did?

I'm checking ldap views in to ldap 7.1 head along with ldap query from 7.2 head.

johnbarclay’s picture

Status: Active » Closed (fixed)

I'm closing this since its in the 7.x-1.x branch. Additional ldap_views features, bugs, etc. should be separate issues. General discussion can go in #1115704: Drupal 7 Status Updates