Member security risk?

Plone 5.1

I added a user with username '12345' (employ-ID), then added the user to group "Team1".
Then I deleted the user and added a new user with username '12345'.
This user is now part of group 'Team1' (and have all the rights 'Team1' had.

Please open a new issue on the issue tracker describing this.

It's a known issue but I cannot find any existing bug report.

You can go around this by using UUIDs as user-IDs. In the security control panel this can be enabled:

I always recommend using this setting.

Is it possible that it has been reported 'somewhere else' ?

If not, maybe https://github.com/plone/plone.app.users/issues is a better place to report it ?

@jensens will that convert all existing users and settings to using UUID or is there some extra manual upgrade step to do that?
I suspect for security we maybe need this as default.

I had tried this and I had a note that it caused the UUID to be used in place of the user name; however, I can't get it to replicate.
I understand the issue here and the value of using the UUID. However, whenever I see what is so obvious, I always ask: why isn't it the default setup of Plone OR why doesn't everyone do it?
Does anyone have any reason why this isn't a good idea?

Using UUID userids may not be compatible with external authentication systems. Specifically, if you're using LDAP/AD you need to slave the userid/username and not provide a Plone-generated UUID. However that's a nonstandard configuration anyway so it's not an argument to not switch to UUID userids by default.

Dexterity.membrane does use UUID userids by default. Given the weirdness of the standard user management being outside of content space, and the arcane and ancient code layers involved, I've often wondered why membrane is not the default user management mechanism in Plone. But that's a different topic...

hi, I wanted to follow up on two points: Dylan asked if selecting this after the site has been in use will create/convert users to UUID. Do you know?

Second, I know that you support using UUID. However, other than what was mentioned below (LDAP), is there any other issues to consider before going to UUID? Also, if it's the obvious choice, do you know why it isn't done by default?

I'd appreciate any help from you or others to understand this. these types of design decisions need to be made up front and, without experience, I simply don't know if I creating problems for myself later.

Comments from you or anyone else would be appreciated.

I assume that the user id is used as id of the user folder and thus becomes part of the url to such a folder. Thus, if you want readable urls to user folders, you likely would not use an uuid as user id.

a) If you use LDAP you map the attributes to use a username. So the setting in Plone is only effective when using the default user implementation.

b) If you do the switch only new users are getting a UUID assigned as username. Already existing users are not migrated as far as I know. But this is ok since new users with a UUID then are never getting an already used username.

Btw.: I would second a proposal to switch on UUID user ids as default for new sites but without an upgrade step to change the switch in existing sites - this may lead to confusion.

+1 as long as we make sure that user ids are only shown in secondary ways (such as a tooltip or in source) in the UI. I think that is already the case for the most part.

Methinks this requires some serious regression testing. I've recently audited much of the userid/username code and our stack suffers from an endemic confusion between userid (the immutable identifier of the user object) and username (the login name the user enters on the login screen).

In many places in our code base username is used as a user identifier. That only works because typically username == userid but that assumption obviously won't hold true when one switches to UUID userids.

Long story short, for ploneintranet and dx.membrane I was forced to settle on a solution pattern where username==userid and getUserName() != username. Go figure.


I would not count on this being a membrane-only issue.

As an example, just take a look at the plone.api.user interface contracts.

The major reason of this confusion is that we name it userid and username. For latter, we should use loginname. Thats what it is.

Hi, yes, you are right that the url for user folder has a string of numbers etc. in place of the user name.

However, if that is the only issue, then it makes sense for me to use it.

thanks for your help

this shows the real problem using UUID. if you use the variable to insert a user into a page, it inserts the UUID, not the person's name.

Why would it do this? should the code be different when working with UUID?

These are the user ids, so this is a correct display of the user reference, which should be id based. If you want to show a different attribute of the user, you'll have to resolve the user object via the id and then access the attribute (e.g. Fullname) on the user object.

do a user = plone.api.user.get(userid) and then user.getProperty('fullname')

Even plone.api names it different: userid is named username there. We are far from consistent.

That is not correct, plone.api.user.get() is the only method there that actually supports either userid or username. All the others support only username. The code example Jens provides is correct though, userid is the default argument there.