[SERVER-7727] Provide at least two extra free format fields to store user information Created: 20/Nov/12 Updated: 25/Jul/14 Resolved: 17/Sep/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Admin, Security |
| Affects Version/s: | 2.2.0 |
| Fix Version/s: | 2.5.3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Simon Harvey | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
RHEL 6 |
||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently the db.addUser command only accepts the user name and password as parameters. This makes it difficult to review users at a later date, e.g. when an entitlement review is performed. It's an even bigger problem if the user is a functional user as it cannot be easily tagged to an owning ID and no description can be entered against it. It should be possible to optionally enter at least two extra parameters to db.addUser to provide more information such as a description of the user, a master ID for it or the owning ID of it. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 17/Sep/13 ] | ||||||
|
The new user management commands support a "customData" field that can be an object with as many fields as you want, and we promise that the server will never inspect that field directly. | ||||||
| Comment by Andy Schwerin [ 28/Nov/12 ] | ||||||
|
The 2.3.x designation means we hope to get it into 2.3 (and hence 2.4), but that it is not a required feature for the 2.4 release. Given the low complexity of the change, I'm hopeful that we can get it in in time for 2.4.0. What I envision is that we would reserve the field name "extra" at the top level of documents in the system.users collections, to contain arbitrary data required by the customer. We would further change the shell's addUser method to accept an object describing the "extra" information. To use it, a caller would call db.addUser as follows:
Users authorized to access this collection would then be able to run queries like the following:
Does this match your goals? Keep in mind that in 2.4, the only users authorized to read system.users collections are those that are also authorized to write to them. If you wish to store information about users that can be read by users that lack the user administration privilege, you'll need to store that information in a separate collection. | ||||||
| Comment by Andy Schwerin [ 27/Nov/12 ] | ||||||
|
In 2.0, 2.2 and 2.4, a workaround is to perform an update operation on the appropriate document in the system.users collection, to add the desired extra fields. For example:
User accounts that have the rights to run addUser() on a database in 2.4 will continue to have the right to query and perform CRUD operations on documents in the system.users collections, which correspond to user information. These documents are usually called "user documents" and sometimes called "privilege documents" in JIRA tickets. |