extended user management

Quote from: Jurrian at Mar 02, 2010, 12:47 AM

hmm I couldn’t find a way to disable the group security, but when it is not there it’s not that strange

Can someone tell me if it is planned that this will be changed in the official release of revo?

Thanks in advance

Jurrian, I’m afraid I can’t make any sense out of this question. You can disable group security by deleting groups, removing users from the groups, or deleting the rules that tie user groups and document groups together. You can also go to tools | configuration | User tab, and set "Use access permissions:" to no. That turns off all group-based security.

If you have 20+ users and 50+ documents, though, and any user can have access to any possible combination of documents, there will be no simple security solution in any CMS. You might want to rethink your security strategy. Maybe it would be better to base the groups on function rather than having a low, medium, and high access group. In order to make security manageable, you need a security strategy with no (or very few) exceptions.

You can easily kick users out of documents with a snippet that evaluates a file or chunk with a list of document ID / User ID pairs. The problem is that unless you use user groups and document groups, snippets like Wayfinder and Ditto will show things to users who shouldn’t see them.

I hoped there was a function in revo that only disabled group security and gave me the ability to look to users instead of groups. but i can only disable the complete security thingie, and that’s not wanted for sure.

I understand what you mean by rethinking the security strategy, but my problem is that this is part of my final study assigment, and my supervisor definetely wants to be able to make exception for each user.

I also found out that this is not able in any of the available cms. Since modx is the most extendable, I thought it would be easiest to create something that would work for this.

I guess I’ll have another conversation with my supervisor to see if we can change the user exceptions so that we won’t have that many exceptions.

Ah, I should have guessed it was a school assignment.

Maybe your instructor just wants you to point out the problems with the general strategy?

If not, it’s a good assignment to show how difficult security is in the real world where users are always asking for exceptions to the security policy.

Really, the only safe and reliable solution in the current versions of MODx would be to create a new web group and document group for just that user and document and tie them together. This could be done in PHP with a web form that only you could access. In fact, you could select the user from a drop-down list and the document from another dropdown list if you want to get fancy. The quick and dirty method would be to just enter the User ID and the Document ID in two separate fields.

It’s a real problem to program exceptions in any other way because once the user has been rejected by the group security rules, it’s too late to make the exception.

I haven’t had the time to discuss it with my instructor, but from previous discussions I know he wants to keep full control, he doesn’t want to be forced to give people acces to documents, when they don’t neccesarily need them.

For myself I thought I’d develop a module that extended the current user management, by adding a table exceptions. With that table, I am able to create a ACL per document by using the current database. In the table exceptions I will create entry’s that link a user id and a document id, with the possibility that when the docid is negative, the user group has acces but the user not, and with a positive entry the user group does not have acces but the user does.

The other option is to just take the consequences of beeing in control with creating a user group for each user, though this is propably going to be a pain in the ass.

Your option is also a nice idea, and I’ll definetely go for the nice method if I’ll be implementing this:)

Remember that all the standard MODx snippets won’t honor your exceptions table unless you rewrite their code. So Wayfinder will show restricted documents in menus and won’t show ones allowed by exceptions. Ditto and getResources will do the same thing when displaying content. So using a resource group for each user might be less of a PITA after all.

that is indeed one of the arguments thats counting for giving each user a user group, but it is not a really clean option. I think the most important point is how many users there will be.