Today I started debugging why the ldap fields are not populating in version DSpace 3.1. and why the email address get assigned the netid with the letters "null" appended.
Inserting debug lines and recompiling the LDAPAuthentication module I have found that the routine ldap.getDNOfUser in the SpeakerToLDAP is not being executed. This routine contains the code to assign ldap variables such as phone, first name, last name are not populating the ldap instance variables. ldap.getDNOfUser was previously called ldapAuthenticate. The routine is only executed when a user is an admin user or if the config allows anonymous search. LDAP servers mostly use a challenge response system where information for a person is supplied from a netid (user name) and a correct password. That is; you can get you own information but no-one else's. The ldapAuthenticate used to verify if the user was legitimate but now replaced with "getDNOfUser" it no longer seems to do that. I think this is a bug rather than a feature and hopefully we can get it corrected. For the time being we cannot update to this new version. On Mon, 2013-07-29 at 00:59 +0200, helix84 wrote: > On Sat, Jul 27, 2013 at 12:51 AM, Keir Vaughan-Taylor <[email protected]> > wrote: > > Okay thanks for that. > > I have written an LDAPAuthentication module that does do the mapping to > > group by LDAP field and we have been using it for some years. > > > > When I saw the group feature and (misunderstood its workings) I thought > > great! Every time a new version of DSpace comes out I have to step > > through the new LDAP code and merge my code into the new changes in the > > LDAPAuthenictation module which is time consuming and never works the > > first time. > > > > I have in the past sent the code to the DSpace development group but I > > understand there is a lot going on and it was forgotten. If anyone in > > the development team is interested I would be glad to supply the code > > again and hopefully they would include it in future releases and save > > me this regular task. > > You're right about that keeping customizations up-to-date with latest > code can be a bother. In fact, this is the main reason why most people > become DSpace contributors (and later commiters) - to move the > maintenance burden away from yourself or your institution and simply > receive them as part of the upstream DSpace package. > > I'm sorry to hear that your contribution was ignored in the past. It's > a manpower problem - there are too few people reviewing patches. While > this is primarily the responsibility of commiters (there are quite few > of us, too), you can help by testing patches other people sent to Jira > and submitting your review to Jira comments. Asking us to put reviewed > changes into DSpace is much better than waiting for us to review them. > > I'll be happy to review this particular feature you're proposing. What > was the old Jira issue number? If you're going to port it to the > latest code (git master branch), please make sure it is configurable > in the same way as the new login.groupmap.* feature. They do the same > thing, so they should look the same to the user. I suggest calling it > login.groupmap-attr.*. We'll have the 4.0 feature freeze coming up in > a few weeks, so please submit it as soon as possible. > > > Regards, > ~~helix84 > > Compulsory reading: DSpace Mailing List Etiquette > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
