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. _______________________________________________ Devel mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/devel
