Loading...
 
Skip to main content

Architecture / Installation


Need advice on a security model, please.

Hi folks,

I would like to configure a system such that Customer users can View documents in both the "User Tips" and "Staff Info" sections of the wiki, but only be able to Edit documents in the "User Tips" section. I'm using TW 1.9.8 and sadly my brain isn't able to figure out how to make this happen!

So far I have:

  • Moved all the perms from Anonymous into Registered.
  • Realised that EVERY user that has authenticated is considered a member of "Registered". This is no good because they can now edit any page that isn't locked with a category.
  • Moved all the perms from Registered (which includes all the perms from Anonymous) into a new group called Trusted.


So at this point, no user has any access unless we specifically issue it via a group or category. Nice and secure.

  • Created a new group called Customers. Customers group has no permission yet.
  • Created a Category called Customers and assigned View Category access for Customers to the group Customers
  • Assigned a couple of pages to the Customers category
  • Created a test user and put it in Customers group.


This is what I've found...

  • The test user can View the pages in the Customers category - good!
  • The test user can not Edit the pages in the Customers category - good!
  • The test user can not View other pages/objects - good!
  • I can't find an Edit Category permission to give to the Customers - not so good.
  • If I assign the Admin Category perm to the Customers group for the Customers category... nothing happens. - not so good.

I think this is happening because the user has no basic edit permission given by the group he's in.

The implication is that in order to allow a user the ability to edit documents in one particular category that it can view, it can automatically edit any document in any category that it can view.

Have I missed something? Can anyone suggest how I can allow Customers access to edit some of the stuff they can view without being able to edit it all? I have another need for Staff users to be able to edit anything they please but I'm sure that'll be simple once I have the Customer dilemma sorted.

Thanks,
Sean

I think Tiki's permission model is hierarchical. When you grant tiki_p_edit to the Customer group, you are giving edit permission to all default (i.e., uncategorized) wiki pages expect those that you specifically deny).

You may have to assign permissions on a page-by-page basis. How many pages do you have?

Or you could create categories for everything — making sure that you have no uncategorized pages (since Customers, or anyone with tiki_p_edit) would be able to edit the uncategorized pages.

HTH,

-Rick
Now Available: TikiWiki for Dummies SmartiesQuestion — A beginner's guide to using ))TikiWiki((.

> I think Tiki's permission model is hierarchical. When you grant tiki_p_edit to the Customer group, you are giving edit permission to all default (i.e., uncategorized) wiki pages expect those that you specifically deny).

That's my understanding, too.

> You may have to assign permissions on a page-by-page basis. How many pages do you have?

I have no particular number at this stage but having to do each one individually isn't scalable thus isn't desirable.

> Or you could create categories for everything — making sure that you have no uncategorized pages (since Customers, or anyone with tiki_p_edit) would be able to edit the uncategorized pages.

Well I was planning on using categories for each section, that's not a big problem. What I think I'll run into though, is that if I give tiki_p_edit to anyone, it entitles them to edit anything they can view. That is the problem. it would mean that I can't have one group of pages read-only to a particular user and another group editable to the same user.

In other words, the only permission on a category is "Can see this category". To give edit, I need to give it at the group level and thus you can edit anything you can see.

Your model can work, but you'll need to assign your groups based on category — not per-customer.

Try this...

  1. Give Registered users tiki_p_view only. (Remove the tiki_p_edit.)
  2. For each category (FOO), create two groups: FOO_EDIT and FOO_VIEW
  3. For each *_EDIT group, assign tiki_p_edit.


So you'll now have a structure similar to:

CATEGORYGROUPS
FooFoo_EditFoo_View
BarBar_EditBar_View
AlphaAlpha_EditAlpha_View

etc.

For each category, assign VIEW permission to its *_VIEW and *_EDIT group. (I assume that if you can edit something you can, by default, view it.)

Now, for each customer, you simply assign them to the appropriate Group. For example:

  • If customer A can read all categories but edit only Foo:
    • Foo_Edit
    • Bar_View
    • Alpha_View
  • If customer B can edit Foo but read only Bar:
    • Foo_Edit
    • Bar_View
  • If customer C can edit View and Bar but only view Foo:
    • Foo_View
    • Bar_Edit
    • Alpha_Edit

etc.

In this model, there's no "customer" group. You simply assign each username to a group, based on categories.

HTH,

-Rick
Now Available: TikiWiki for Dummies SmartiesQuestion — A beginner's guide to using ))TikiWiki((.

That idea has potential. I shall give it a go.
Thank you for your insight.

Tested with 2 categories Test and Test2 with edit and view groups for each. User was put into both View groups and as soon as I put it into one of the edit groups, the user can edit pages in both categories.

This confirms the previous conjecture that if anything gives you the tiki_p_edit flag, you can now edit anything that you can view.

Dang 😑