On Saturday, March 03, 2012 04:50:42 PM Jeroen van Meeuwen wrote: > On 2012-03-03 15:27, Michael Gapczynski wrote: > > On Saturday, March 03, 2012 12:20:02 PM Jeroen van Meeuwen wrote: > >> On 2012-02-29 19:46, Arthur Schiwon wrote: > >> > On Tuesday 28 February 2012 14:27:36 Aleksander Machniak wrote: > >> >> - Authenticating against LDAP does not create the owncloud > >> >> equivalent of > >> >> a user account, and therefore sharing with permissions is not > >> >> working, > >> > > >> > These are two different things. Sharing with permissions is not > >> > dependent on > >> > local accounts. Is there another reason for them? > >> > >> Correct me if I'm wrong, but I thought ownCloud saved the (user, > >> group) > >> permissions on files shared, amongst other things, in it's own > >> database. > >> > >> I'm seeing owncloud.oc_sharing be filled with a uid_owner (my LDAP > >> UID), and I'm seeing sharing only be possible with local database > >> user > >> accounts (not other LDAP accounts). > >> > >> I think it is easiest to acknowledge the users end up in the > >> database's > >> users table, with a proper user_id, and refer back to that user_id > >> in > >> other tables (such as sharing) instead of continuously referring to > >> a > >> 'uid' - because of renames of people. > >> > >> The same goes for groups, really, and ultimately you may want to > >> indicate the authentication and authorization database (type) these > >> users could have originally come from (i.e. the users and groups > >> tables > >> get an LDAP tree identifier added to them). > >> > >> If you wanted, you could then detect renames by adding yet another > >> column that holds the persistent, unique identifier for LDAP entries > >> (usually entryUUID, or nsUniqueID, or something custom). > >> > >> You would then search for the entry in LDAP, get its unique > >> identifier, > >> search your own tables for said identifier, either create a new > >> entry or > >> update an existing entry. > >> > >> Alternatively, some sort of API call could cause a synchronization > >> daemon (Kolab does this a lot, I'm working on the parts that make > >> this > >> happen for Roundcube at this very moment), to issue a rename, add or > >> delete. > > > > Sharing is already possible with LDAP users and other user backends. > > It seems though selecting users from our LDAP tree (in the sharing > dialog for a file) does not function as well as one might expect.
Is the sharing dropdown not populated with the LDAP users? This may be a user interface issue rather than a problem with the sharing backend. You could try manually inserting a item into the sharing table with the uid_shared_with set to a LDAP user. I also have some changes to the user interface for sharing on my todo list. A dropdown is not reasonable for large LDAP user directories. > > If I upload a file, and share it, the uid_owner is correctly attributed > to me, but all I succeed in sharing the file with is any of the local > user accounts. > > Could it be that, since we use the displayName attribute for LDAP > users, ownCloud is not digesting the selection? > > If you want, I can give you an account on our installation and you > could see for yourself. > > > There is no direct link between the database users table and the > > sharing table. > > > > I'm aware that our method of keeping track of users in the database > > is not > > good and can cause problems with renames. This applies to more than > > just > > sharing. This is on my todo list for the next release. > > If you need/want some help with this, feel free to drop me a line. > > Kind regards, > > Jeroen van Meeuwen _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
