Call for Co-Maintainers and Developers

I'm interested in simpletest, documentation, and advanced help. I'm also interested in patterns and features export functionality. I Use Active directory and manage a part of that so can run unit tests on that. Can help wherever with coding.

I am developing a new site that requires ldap and I installed your module. As soon as I enabled the module it disabled the whole site... white screen, no code. I did not do any configuring anything before enabling and I had 2 test users already in my db (not in ldap). I physically deleted the directory and everything works as it should. I tried to add the ldap directory again and drupal thinks ldap is still an active module and my screen goes white with no code again. How can I disable/reset the module? How can I configure the module when I cannot get to any administration portions of the site when the module is active? Thanx in advance for any help you can provide.

Thank you for downloading and giving it a try. The module is currently not stable. When we have a version that has some working functionality we will make an alpha release.

If you need ldap functionality now, use the ldap_integration project.

When it is ready for testing, would you be willing to be a tester?

I am interested in testing.. guess what.. I tested this module and found many bugs..

I am a drupal developer too.. and personally modified ldap provisioning and written ldap group creation and maintenance module for my organization.

i tested your module for both php 5.2 and php5.3 ver.. this module gives more problem in php5.3.. such as

this one..

Warning: Parameter 1 to ldap_api_servers_admin_form() expected to be a reference, value given in drupal_retrieve_form() (line 594 of /var/www/drupal7/includes/form.inc).

to resolve this i have to remove & in file ldap_api.servers.inc

ldap_api_servers_admin_form(&$form_state, $op = NULL, $sid = NULL)

then the form would display.. but in php5.2 the form will display without removing &

this is a common problem in drupal 6 ver also if its using php5.3.

and after submitting the ldap configuration i get this error..
Fatal error: Call to undefined function ldap_api_config_get() in /var/www/drupal7/sites/all/modules/ldap/ldap_api.servers.inc on line 284

i searched entire ldap directory for this function ldap_api_config_get but not found!.

still testing.. will post some more bugs..

The module is far from alpha. Thanks for giving it a try. The code in there is just a mix of what the contributors have. We are sorting out the structure in the wiki then will start writing the module.

Don't bother looking for bugs at this point, though we appreciate your enthusiasm.

Can you enter a note in http://drupal.org/node/807410 about your testing environment, particularly that you are testing with php 5.3 and whatever ldap type you are using.

Thanks, John

@retsamedoc - I'm interested in joining in on this project and being a co-maintainer. I've worked pretty extensively with the ldap_integration modules for the last 4 or 5 years (since d4.6). It would be great to finally be involved in a reworking of the project!

I'm in the process of applying for a cvs account now and getting the blessings of a maintainer will help that along!

-Chris

Sounds good to me. Where are you most interested in focusing? Also, make sure to get an account on the wiki. I have set a few days next week aside for coding on this and want to get a good start on laying out the classes, methods, properties, and the module structures.

After we somewhat agree on that, it will be easy to work in parallel.

Also, do you mind taking a look at http://drupal.org/node/809430 ? Its my thoughts on how to deal with authentication workflow for drupal 7. Any insight will be appreciated. I will likely start coding this workflow against a fake/temporary ldap class.

@john

I'm more of a d6 guy, and the project would probably be better served keeping my focus there. I don't think the d6-d7 auth workflow is much (if any) different, so we could probably coordinate an approach that works well for both. I'll throw some notes in on the post listed above a little later.

-Chris

retsamedoc also needs this for a d6 project and is going to backport whatever we do in d7 back to d6.

Would it make more sense to:
- make head d6
- simply put placeholders in for any functionality we want to put off until d7
?

My preference is to shoot for d7 so that other ldap modules can migrate to ldap when they update their modules from d7. But I don't think there will be much difference between d6 and d7 except in authentication workflow. So it may be more expeditious to do d6 first. Especially with things like features where we need the modules to exist and they may not in d7.

I any case the task at hand is still to outline the hooks, classes, etc. in the wiki. I'm trying to get back to that.

Hi, retsamedoc - I'm interested in joining in on this project and being a co-maintainer of this module.
I prefer ◦Basic (exportable) LDAP functions and some test work.
I have worked LDAP related work more than 2 years, have some basic idea about LDAP protocol.

Great! Are you interested in writing unit tests or testing in different ldap configurations? What ldap versions can you test on?

The exportables work seems like it would be near the end though we are making a point of avoiding auto increment ids for objects in the configuration to make exportables easier. Please keep an eye toward exportables in the issue queue.

Hi,

I'm interested in developing / co-maintaining this module.

My preference goes to drupal 7 development of the basic API, authentication, authorization and profile modules (in that order), and afterwards the integration with other modules such as Views / OG.
I can also write tests, though I think it's difficult as there is no access to an ldap server from the testbots. We can off course run the tests on local installations.

Hi,

I am interested in developing / co-maintaining this module.

I am currently getting up to speed on Drupal 7 and have done some work in both Drupal 6 modules and LDAP before.

Thanks
Robert

What is the development status of the module? Just had a quick run with 7.x version and it seems in prealpha stage.
Anyone taking care of the 7.x branch? I can send patches...

I believe the developers are in the summer doldrums, but I can only speak for myself. Our plan is to focus on the drupal 6 version, then get migrate to version 7 and include update code. Should be relatively simlple since the code base is structured as an api. My energy should pick up on this shortly.

I'm interested in helping with the actual authentication and authorization frameworks. The thought of a true enterprise-class user management system within Drupal would be great. I'm working on a module to abstract the authorization framework within Drupal to work with whatever modules want to implement it - allowing for multiple authorization frameworks without re-writing the base Drupal code.

I'd also be interested in developing something similar for the user authentication piece. There is no reason every single authentication module has to hand write the fallback to core Drupal login every time.

The authorization framework idea sounds interesting. Are you working in drupal 6 or 7 on you authorization framework module and can you give a quick overview of it? On the second point, drupal 7 takes authentication abstraction much farther with additional functions and hooks.

I'll have to look into D7's user authentication abstraction some more. My work is so far all for clients on D6. My mine gripe with the D6 authentication system is the real inability to have multiple login methods without coding for each. The authentication should be pluggable like PAM on Linux (my thoughts at least).

My Entitlements module is designed as a way for additional modules to map arbitrary third-party input into Drupal objects. The current implementation is mapping entitlement codes to OG memberships. It is generic enough that I plan to add glue work for roles as well. Obviously, the options continue...

If I could work with an up-and-coming project like this, I think it would really help me flush out the ideas and API.

I am interested in developing / co-maintaining this module.

I've administered several Drupal 6 sites in the past, and currently. I have used ldap for many years as a log in scheme.

I'm interested in helping with the development of this suite (I'm primarily interested in the Authentication, Authorization and Views integration). We use AD at our institute and have been using the ldap integration module for the past year and would be behind supporting this. I don't know as of yet what my time commitment would be (would be verifying with the institute), but I'm putting it out there primarily as, at the very least, I'll support with testing and patches whenever it enters a dev/alpha state.

i'm looking to use this for my client groups, single signon to webmail, hosting/dns/virtual map, and account login/management intranet. testing and contrib expected. will checkout pre-alpha this coming week.
thanks for getting the ball rolling.

So how do you plan to user the ldap module in a single sign-on solution? Is the user going to authenticate to drupal with LDAP, drupal authentication, etc. and then drupal act as a single sign-on provider in some way?

Or is drupal going to manage the accounts and the LDAP server be the authentication handler for the single sign-on app?

I think of CAS, pubcookie, kerberos, etc as single sign-on providers (and consumers). I think of ldap, openid, etc. and pluggable authentication handlers for a single sign-on solution.

It raises the question of how CAS, Pubcookie, etc might use the ldap modules api. Pubcookie populates user profiles with ldap data (http://drupal.org/project/pubcookie). CAS (http://drupal.org/project/cas) could do similar mapping. Then there are all the field mapping modules like feeds. There is also an openid profile field mapper.

Yeah. This is a problem for unit tests. I've looked around for a php mock ldap for unit testing, but haven't found one. Seems like a reasonably simple thing to do for know unit test requests. An outline of a java mock implementation is at: http://java.dzone.com/articles/mocking-out-ldapjndi-unit?utm_source=feed...(Javalobby+/+Java+Zone)

Do you think this approach would work for the testbots if the queries to the mock ldap were over port 80?

I would definately put this as a low priority at this point over functional and integration testing, but was thinking about it while raking leaves today.

Back to work on this module after a long break. I'm going to focus on the ldap authorization module. retsamedoc is back to work on this also. We are focusing on drupal 7 in head now.

John

I'm working on the ldap authorization module now and looking at integration with other modules. Can you read #966910: LDAP Project Drupal 7 Integration with og_ldap and maybe take a look at the initial code? I'm wondering if it fits at all the entitlements module? Feel free to call if thats easier (http://www.johnbarclay.com/)

oops. this was meant as a comment on #21 directed at erikwebb.

Had a good skype with erikwebb yesterday. He is developing entitlements, which is a kind of pluggable authorization consumer (og, etc.) which he hopes will work with various authorization providers (ldap, CAs, ...) He's still figuring out where he wants to go with the module, but we are in agreement on the following:

- ldap authorization for drupal roles should stay in the ldap project.
- the design of ldap authorization and entitlements hooks and functions can inform each other and hopefully entitlements will be the middle ground for ldap providing authorizations for og etc. (though modules like og_ldap will be needed until then or alongside of entitlements). see #21 also.
- he's interested in code on the ldap project (ldap api, ldap authentication, and ldap authorization) as he mentioned in #19

I am interested in LDAP integration, specifically with openldap. I have taken a look at this module in Drupal7, the latest stable version as of January 9, 2011. For the most part, it seems like everything works. However I understand this is alpha code and there are still a lot of changes to be made to make it stable.

What was tested:
1. I had to alter the code to allow the server test tool to work.
2. TLS is working.
3. Basic Authentication is working via LDAP

What was not tested:
Authorization feature. I am just interested in authentication for now and basic authorization will come later.

Good work.

Good work guys! It was a little bit of a challenge, but I finally got this to work with Drupal 7. Most of the problems I encountered were actually related to my PHP environment - mainly I did not have my ldap.conf setup properly - Once I added "TLS_REQCERT never" to ldap.conf - then things worked for me.

I put together a small php script to test LDAP access (i.e., ldap_connect() and ldap_bind()) - that helped me get my environment fixed up. It might be helpful in the package/readme to include a small test script - that way people realise its their environment and not this module that needs attention :-)

The only real issue I had with this module was 'duplicate e-mails' - I created user 1 with my e-mail account. Once I got the LDAP module working and configured for 'mixed mode' authentication - I logged in via LDAP authentication and got the 'Another user already exists in the system with the same email address' error message. I traced that message to ldap_authentication.inc - to get past this, I temporarily commented out the 'return FALSE' statement.

In 'mixed mode' - I can foresee the possibility of many 'duplicate e-mail' messages and perhaps there needs to be more discussion around the notion of supporting duplicate e-mail accounts ...

Anyway - I would be happy to help with this effort in any way that I can ... I can code, document, test, etc

Thanks

great. glad its working for you and yes, help is needed.

• a script to test ldap server stuff out would be great. It could be in the module download or attached to http://drupal.org/node/1023900
• the php ldap environment is the most difficult part. Please add any insights you have on the page http://drupal.org/node/1023900
• whatever configuration issues that can be identified within the drupal/php context, we'd like to have visible at /admin/config/people/ldap/help/status, /admin/config/people/ldap, /admin/config/people/ldap/servers etc and the test pages admin/config/people/ldap/servers/test/[server id] and /admin/config/people/ldap/authorization/test/[id] so if there is anything from your script we can add to these it would be great. If there is stuff in the script that can't be run from php layer, we should definately include it somewhere.
• the duplicate email issue is a drupal thing, not the ldap module. Drupal is just not set up to deal with multiple accounts with the same email address. Feel free to start a thread/issue on this, especially if you have a direction to go with this. If nothing else, the documentation and error message could be beefed up.

help needed

1. Since you just got the module working and put up a fight to do so, editing the documentation (http://drupal.org/node/997082) and feedback on the configuration forms is ideal. Once you get working on the module you will lose your "new user" perspective and it will be wasted.

Coding possibilities:

2. I'm working on ldap authorization next, and have no idea what the option "II.C. Derive drupal roles from entry" in the authorization form is used for or was used for in ldapgroups in drupal 6. If you can figure out what it is that would be great so we can add documentation and make it work correctly. Otherwise I'd just like to remove the option instead of leaving something in I don't understand and may not even be used by others.

3. Other issues that could use some coding help, easy to hard in order:

#1026078: hook_menu implementation needs corrections: poor tabs and breadcrumbs
#1029940: Clarifying service account encryption
#1023366: Switching to Encryption does not excrypt current passwords
#1023016: upgrade hook or migrate function for ldapauth and ldapgroups
#1016728: LDAP Authorization: Nested group recognition for authorization in group strategy IIB and IIC
#807388: LDAP User: Prepopulate Individual Users in LDAP Authentication

I've done quite a lot of modules, but never worked with LDAP. Where should I go to learn what I'd need to be of use to you folks?

Below are my priorities. Most of the work involves knowledge of drupal; the ldap side is pretty thin. So if you installed and gave the module at testing you would likely be able to jump into any of the tasks below.

- if you have experience with testing, writing simpletests for ldap_authentication and ldap_authorization. Much of the testing at http://drupal.org/node/1053818 could be done with simpletest. Good automated testing can take a lot of the work out of development and avoid a lot of needless user frustration.

- since you have og experience, an ldap_authorization plugin for mapping ldap to og groups might be a good task. Currently there is an LdapAuthorizationConsumerAbstract that the LdapAuthorizationConsumerDrupalRole class extends. For OG mapping, a module named ldap_authorization_og that was basically a clone of ldap_authorization_drupal_roles module would take care of it. Just alter of code for roles/og groups. Not sure what the maintainer of og ldap or ldap og is up to.

- if you are using ldap_authorization, a test grid like at http://drupal.org/node/1053818 for authorization would be handy.

some small tasks:
#1089866: LDAP Servers: validate cns syntax
#1089854: LDAP Servers: Test should map ldap error number to meaningful remedies in configuration
#1023016: upgrade hook or migrate function for ldapauth and ldapgroups
#1023366: Switching to Encryption does not excrypt current passwords

some tasks not in the issue queue at all:
http://www.gliffy.com/publish/2315088/
exportables/feature testing general once over and testing
caching/performance general once over

subscribe

I'd like to get involved in this project, at least to the point of getting a stable 1.0 out the door, but I have to admit I have some reservations. My time is quite limited, and I spent several hours this afternoon just sifting through the issue queue.

There are numerous issues marked "needs review" but have no patches to review. That leads me to assume that the changes mentioned here have been committed to code, but as I already noted elsewhere, the commit messages don't contain issue numbers, so it's very difficult to review anything. It may be best to simply mark these issues "fixed" if the code is already committed.

OTOH, a couple of the "needs review issues" look like opened up feature discussions. I'd recommend marking some things postponed for the 2.x branch until the initial release is stable.

I can commit some time over the next couple of days to help get the issue queue straightened out and can probably contribute some patches to both existing open issues and a couple of problems I ran into while testing the module today. I can also help with some general code cleanup and make some recommendations based on my hanging out in #drupal-gitsupport on IRC for the past three weeks.

John and Zach, this is your project, and I don't want to come off as some pompous jerk coming in and complaining about how you're running things. I just want to help get 1.0 finished, and I think I can be more useful if I can start by helping organize and prioritize. d.o is open enough that I could just start doing that, but I'd rather communicate with one or both of you directly first. (I'll follow this up with direct contacts.)

I've got to be honest, though. My time is limited, and I will probably look into alternatives to LDAP such as the CAS module, too. I'll be working next week with the guy who built our identity management system to see if we can get SAML authentication working via CAS instead of using LDAP. If that doesn't work, then LDAP is absolutely mission critical for me, and I will have hours available to work on this as part of my day job.

The needs review is to whether the issue problem was fixed, not the code itself. I expect the people who had the problem to install the newer version and make sure it went away. I give people a time for feedback then close the issue. If you see any of the needs review ones, just test for that bug being fixed; once an alpha is out it will be easier to associate patches and issue queue items.

Most helpful would be ldap authentication testing, just going through the test grid from top to bottom. The test grid is in the documentation with the april 5th or 6th 7.x-1.x-dev.

I do recommend CAS or shibboleth over ldap for any web development for a number of reasons. It will cut down on your maintenance and put you in a more platform agnostic situation; both on the authentication provider side and the consuming web application.

Ok, gotcha.

The problem is that I've run into a couple of show-stoppers in the configuration screens before even getting to item 1 on the test grid, which is printed and sitting on my desk. Since I just started looking at this module yesterday, I'm not in a position to see if a bug marked "needs review" has been fixed if I can't clearly identify the problem or the commit that fixed it.

I looked at CAS, and it won't really work for me until #503414: CAS Attribute Token Support gets resolved. I'll file issues for the bugs I've found so far, then start testing once I can get it to talk to my LDAP server correctly.

This topic and all other general progess and feature discussion is in #1115704: Drupal 7 Status Updates so I'm closing this thread.