Editing LDAP profile data

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Editing LDAP profile data

"Jörg Bernau"
Dear Developpers,
 
is there a way to edit LDAP profile data in the users profile? (password (!!!), phone numbers, addresses, photo ...) If not are there any efforts in that direction? Otherwise again if not is there an interest if I did that?
 
Thanks in advice...

Joerg

_______________________________________________
Devel mailing list
[hidden email]
http://mailman.owncloud.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

Arthur Schiwon (Blizzz)
On Wednesday 28 Oct 2015 10:06:02 Jörg Bernau wrote:
> Dear Developpers,
>  
> is there a way to edit LDAP profile data in the users profile? (password
> (!!!), phone numbers, addresses, photo ...) If not are there any efforts in
> that direction? Otherwise again if not is there an interest if I did that?
> Thanks in advice...

No, we do not write to LDAP at the moment, and this feature is also not
planned.

You can add this preferably in an app of your own, taking advantage of the
existing LDAP backend (e.g. using the configurations).

At this moment I tend not to have it in the LDAP backend itself, mostly
because it is complex enough and I shy away from maintaining more features
than necessary. However, I am open for needed interfaces or so in here if you
follow the approach with an another app.

Cheers
Arthur

>
> Joerg

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

XMPP: [hidden email]

www.owncloud.com - Your Data, Your Cloud, Your Way!

ownCloud GmbH, GF: Markus Rex, Holger Dyroff, Frank Karlitschek
Schloßäckerstrasse 26a, 90443 Nürnberg, HRB 28050 (AG Nürnberg)
_______________________________________________
Devel mailing list
[hidden email]
http://mailman.owncloud.org/mailman/listinfo/devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

user3254
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?

Thanks a lot.


Regards,
Lucy
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

Arthur Schiwon (Blizzz)
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?

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.

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?

Cheers
Arthur



>
> Thanks a lot.
>
>
> Regards,
> Lucy
>
>
>
> --
> View this message in context:
> http://owncloud.10557.n7.nabble.com/Editing-LDAP-profile-data-tp15999p16748.html
> Sent from the Developers mailing list archive at Nabble.com.
> _______________________________________________ Devel mailing list
> [hidden email]
> http://mailman.owncloud.org/mailman/listinfo/devel


_______________________________________________
Devel mailing list
[hidden email]
http://mailman.owncloud.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

user3254
Hi Arthur,

Thanks a lot for the reply.


>
> On Tue, 1 Mar 2016 03:06:49 -0700 (MST)
> user3254 <lulahlulah@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. 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:

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? 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? 

>
> 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


> 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 :)


Best regards,
Lucy
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

user3254
Dear Arthur,

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?

Thanks!

2016-03-11 16:14 GMT+08:00 Morris Jobke <notifications@github.com>:
>
> Hi Arthur,
>
> Thanks a lot for the reply.
>
>
> >
> > On Tue, 1 Mar 2016 03:06:49 -0700 (MST)
> > user3254 <lulahlulah@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. 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:
>
> 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? 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?  
>
> >
> > 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
>
>
> > 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 :)
>
>
> Best regards,
> Lucy
>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

Arthur Schiwon (Blizzz)
In reply to this post by user3254
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.

> /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.

> * 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
> 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.

Cheers
Arthur

>
>
> Best regards,
> Lucy
>
>
>
> --
> View this message in context:
> http://owncloud.10557.n7.nabble.com/Editing-LDAP-profile-data-tp15999p16871.html
> Sent from the Developers mailing list archive at Nabble.com.
> _______________________________________________ Devel mailing list
> [hidden email]
> http://mailman.owncloud.org/mailman/listinfo/devel


_______________________________________________
Devel mailing list
[hidden email]
http://mailman.owncloud.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: Editing LDAP profile data

user3254
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