On 19.02.2013, at 08:55, Andreas Ergenzinger <[email protected]> wrote:
> > On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon <[email protected]> > wrote: >>> I configure CN as the display name attribute. But display >>> names are not unique. So it's not possible to find the right user. > >> >> It's true that display names are not unique. But would it help to number >> them? You would end up with >> John Doe >> John Doe (2) >> John Doe (3) >> >> → i see the problem, but forcing unqiueness for display names does not >> look like a solution for me >> >> A way would be to add an (optional) second attribute that may be >> displayed in brackets, e.g. displayName + mail >> John Doe ([email protected]) >> John Doe ([email protected]) >> >> I am open for ideas and suggestions on this. > > I can understand the desire to keeps things simple and general by not > enforcing uniqueness of display names, but your own example illustrates the > need for human-readable, unique identifiers. If all users data is coming from > the same source, e.g. a single LDAP server, then it is possible to guarantee > uniqueness by selecting an appropriate attribute. In such a scenario, the > email address is probably the best choice for the display name. > > The problems start once you combine different user bases with duplicate > attributes values, or once you permit users to change their display names, > because either one can lead to name clashes. Editable display names are > especially problematic from a security standpoint, since some users may > intentionally try to change their display name, in the hope of being > mistakenly granted access to private data. I used to think that just checking > for existing display names would be enough to prevent problems, but users may > try to grab the default display name (e.g. the email address) of a potential > user who does not have an OC account, yet, creating trouble down the road. > > So, for highest security, display names should be globally unique and > unchangeable. > > If that is not the case, then we have to rely on the suggested displayName + > mail, which effectively creates a third user identifier, let's call this the > unique display name (UDN). Due to the mentioned security issues, the UDN > should be used pretty much everywhere instead of the simple display name, > which makes the non-unique display name superfluous. > > Considering the display name just as the editable part of the UDN, without > ever using it on its own, would require extensive code changes but seems like > a reasonable compromise. > > BTW thank you Arthur for answering my other mail. > > Cheers > Andreas > An admin can disable the option for users to change the display name. I depends on the user scenario if this is useful and save or not. In case you use a directory like LDAP then we rely on a properly configured useraccounts in it including unique and understandable display names. The scenario of different LDAP servers is interesting but I'm not sure if it is in the scope of ownCloud to resolve naming collisions in his case. This can and should be solved in the LDAP configuration. Frank _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
