[owncloud-devel] Editing LDAP profile data

user3254 lulahlulah at yahoo.com
Wed Mar 16 10:09:58 GMT 2016


Hi Arthur,

Really a big & huge thanks for sharing your thoughts on this.

Please find my replies inline.

> Hey, 
>
> please find the answers inline. I also include the question from the 
> second mail at the end. 
>
> On Fri, 11 Mar 2016 01:20:26 -0700 (MST) 
> user3254 <[hidden email]> wrote: 
>
>
> > Hi Arthur, 
> > 
> > Thanks a lot for the reply. 
> > 
> > 
> > > 
> > > On Tue, 1 Mar 2016 03:06:49 -0700 (MST) 
> > > user3254 <[hidden email]> wrote: 
> > > 
> > > Hey Lucy, 
> > >   
> > > > Hi Arthur, 
> > > > 
> > > > I'm going to write and possibly contribute an app which can write 
> > > > to LDAP and any modifications to user data in the MySQL database 
> > > > should also be done in LDAP. 
> > > > 
> > > > Could you please eloborate the interfaces you mentioned? Which 
> > > > methods need to be hooked in?   
> > > 
> > > Please keep the old mail quoted, so the context is not missing. If I 
> > > would not have it in my maildir it would have been tough to find 
> > > this again ;) 
> > > 
> > > Back then I was writing 
> > >   
> > > >>  However, I am open for needed interfaces or so in here if you 
> > > >> follow the approach with an another app.   
> > > 
> > > That said, there is currently nothing that would let you interact 
> > > with the LDAP backend. 
> > > 
> > > What we would need to do is to provide an public API in ownCloud 
> > > core. Probably the basic methods would be user centered 
> > > 
> > > * translate an ownCloud username to the LDAP DN: This allows you to 
> > >   work with a user record. 
> > > 
> > > * return the LDAP connection for the specified user (since more than 
> > >   one LDAP server can be configured): This allows you to talk to the 
> > >   LDAP server and you do not need to worry about establishing 
> > >   connections and stuff 
> > > 
> > > Or is there anything else needed by you?   
> > 
> > 
> > Wow, hm, I initially didn't think that a change in the ownCloud core 
> > is needed.
>
>
> Yeah, if done properly :) 
>
> > Actually in our project, only user name and password must 
> > be stored in LDAP, storing additional attributes would have been a 
> > bonus. And as our schedule doesn't really allow us to wait for an 
> > ownCloud 9.1 release, I'm now thinking whether I could just write an 
> > app that is cloned over from user_ldap using the same configs, 
> > connections etc. and hooks in to the following methods of \OC\User: 
>
> Sure you can fork it and use your replacement instead. 
>
> You need to patch in bug fixes. Might not be a big issue if you keep 
> your changes as patches (or just rebase from regularly), however code 
> might change and you'd need to adjust yours from time to time. 
>

I understand. Using the initially suggested approach (core change +
user_ldap change + app calling ldap_* methods) would surely reduce this
disadvantage. 

>
> > /preSetPassword/: save the password to LDAP. If any error in LDAP 
> > occurs, throw an exception and display a helpful message in ownCloud 
> > webUI. 
> > 
> > /preCreateUser/: create a user in LDAP with the specified password. 
> > If any error in LDAP occurs, throw an exception and display a helpful 
> > message in ownCloud webUI. 
> > 
> > /preDelete/:delete the corresponding user in LDAP. If any error in 
> > LDAP occurs, throw an exception and display a helpful message in 
> > ownCloud webUI. 
> > 
> > 
> > Important questions would arise: Firstly, *is it feasible?
>
>
> Feasible yes, but sustainability and maintainability not too much if 
> you need to pass it on to someone else. 
>

Then there's the question whether publishing such an app would actually be
of any benefit for the public :D  The issue with sustainability and
maintainability really bugs me, therefore I think I will try your initial
suggestion (core change + user_ldap change + app calling ldap_* methods)
whereas the app will still work as I described, using the same hooks, just
without the redundant codes and API calls instead. I might need to ask you
for help in case there are some hiccups, some questions can already be found
below :)

> > * Secondly, 
> > *how do you pass such a helpful message or error code to ownCloud 
> > webUI, for example in case of a LDAP password policy violation? And 
> > how to do that in the best way so that the app is not project 
> > specific, but can be used generically?* 
>
> If it's interactive you'll probably do some Ajax calls and receive the 
> the result from the server. I.e. you'll handle this with JS and we have 
> for instance an OC.Notification object that allows you to show such 
> hints. Look into core/js/js.js. 
>
> If this comes statically from a server, you'll just output it in HTML 
> templates. Taking the LDAP backend as example checkout the settings 
> with apps/user_ldap/settings.php and apps/user_ldap/templates/* 
>

I see, the app will probably follow the user_ldap approach.

>
> > > Those methods need to be specified in an interface within a new 
> > > folder lib/public/ldap/ 
> > > 
> > > There needs to be a default dummy implementation in core 
> > > (lib/private/…) that would just throw exceptions, and an real 
> > > implementation in apps/user_ldap/. Upon install/update it should 
> > > override the default implementation and set it back when disabling. 
> > >   
> > 
> > Uhm, exceptions not debug messages? But then, I'm not familiar with 
> > the core yet :D
>
>
> Exceptions. Otherwise, that dummy would need to return something 
> useful, which is barely possible. 
>

Oh, I better have a look at some examples first...

>
> > > The server (lib/private/server.php) would just receive a need method 
> > > and provide an instance of that implementation. 
> > > 
> > > This is less complicated than may sound :) 
> > > 
> > > When this is done, your future app would just retrieve the instance 
> > > via \OC::$server->getLDAPProvider() (maybe find a better name), 
> > > which allows you to receive the DN of the user and the LDAP 
> > > connection resource, allowing you to use all the PHP ldap_* methods 
> > > to interact with the server. 

Here are some questions, before I can start: 
- How does the server know to return the real implementation done by
user_ldap? 
- Which existing example would be most suitable for this approach to base my
code on?
- What ldap_* method should be provided? Or maybe I just implement the basic
method like createUser, setPassword and deleteUser first.
- Is the ldap_ suffix mandatory? As LDAPProvider might already suggest that
the methods are LDAP related.

> > > 
> > > What do you think?   
> > 
> > Well, it definitely sounds good. However if my proposal above is 
> > feasible, we would stick to that for time reasons. 
> > 
> > > 
> > > Cheers 
> > > Arthur 
> > >   
> > > >   
> > > 
> > >   
> > 
> > Your opinion is highly appreciated :)
>
>
> To come to the extra question: 
>
> > Sorry I forgot this question (which is actually covered by the 
> > question 
> > of feasibility): Will ownCloud use LDAP or database for authentication 
> > when the user exists in both? 
>
> Depends in the loading order. Note that neither ownClouds internal user 
> backend nor the LDAP backend would allow to have identical user names. 
> Login names are a different story, so the question is valid. 
>
> The credentials are passed to the backends until one succeeds. 
>

Yeah, but that would lead to the question of how the loading order is
determined :D  And do I guess correctly that it also means that when the
LDAP password was changed by an external client, the ownCloud user could
theoretically use two different passwords to login successfully?


> Cheers 
> Arthur 
>
>
> > 
> > 
> > Best regards, 
> > Lucy 
> > 
> > 
> > 


Regards,
Lucy



--
View this message in context: http://owncloud.10557.n7.nabble.com/Editing-LDAP-profile-data-tp15999p16919.html
Sent from the Developers mailing list archive at Nabble.com.


More information about the Devel mailing list