Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
Domesday/Directory Design: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
However, as the web interface will update access control data as users change their privacy options, we are going to need access control on the dynamic access control attributes! In other words, users can change the access control for their own data, but not the access control for other people's data. | However, as the web interface will update access control data as users change their privacy options, we are going to need access control on the dynamic access control attributes! In other words, users can change the access control for their own data, but not the access control for other people's data. | ||
===Access Control=== | |||
Access control is based on the tagging system. Each user has a number of tags, and there are a handful (say 3-6; not dozens) of privacy levels. A user can move any individual item of data about themselves from one privacy level to another. | |||
The access control complexities come from the facts that: | |||
* Each item of user data (attribute) can have different access control (although you could group them into sets, as there are only a handful of levels) | |||
* Users can individually control the access to their own data items, rather than it being defined centrally or by an administrator | |||
* Public tags have their own access control for adding and removing them | |||
* Each user has their own private set of tags on other users, which are effectively in their own namespace | |||
Gerv suggests: access control has to be dynamic. | |||
===Attributes=== | ===Attributes=== | ||
| Line 40: | Line 53: | ||
But I expect the number of reads will dwarf the number of writes. Hence using a directory. | But I expect the number of reads will dwarf the number of writes. Hence using a directory. | ||
=== | ===More Ideas=== | ||
Gerv | Gerv speculates: might it work if we had several entries for each user, one for each privacy level, under a common root named after that level? You would move attributes between entries based on the privacy level the user assigned. Then when another user did a search, we would just search inside the subtrees which matched the privacy bits that user had. Would that be more performant than having individual access control for each attribute? | ||
The difficulty is that inetOrgPerson has a few mandatory fields... we may need a placeholder "not present" value to use. | |||
Of course, this might be premature optimization... | |||