[owncloud-devel] Editing LDAP profile data
blizzz at owncloud.com
Wed Mar 16 00:43:04 GMT 2016
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 <lulahlulah at yahoo.com> wrote:
> Hi Arthur,
> Thanks a lot for the reply.
> > On Tue, 1 Mar 2016 03:06:49 -0700 (MST)
> > user3254 <lulahlulah at yahoo.com> 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.
> /preSetPassword/: save the password to LDAP. If any error in LDAP
> occurs, throw an exception and display a helpful message in ownCloud
> /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.
> * 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/*
> > 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.
> > 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.
> > 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
> 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.
> Best regards,
> View this message in context:
> Sent from the Developers mailing list archive at Nabble.com.
> _______________________________________________ Devel mailing list
> Devel at owncloud.org
More information about the Devel