Loading...
 
Development

Development


Re:Core - Security

posts: 49 Uruguay

How security could be managed in an extensible way? The actual scheme have two approachs, security by feature (i.e. that user/group can access forums) and security by content (i.e. for wiki pages you can decide who can or can't access to a content, or do some things with it).

In the content objects approach of data, there is a "security scheme" field. For any object, you'll have a list of permissions regitered, i.e. can edit, can see, can attach objects, can delete, etc, list that could be common, or maybe specific for a content type (is different see, edit and fill a poll? well, then for the hipotetical poll object will be a "fill" security item).

In general, that scheme connects the available actions for an object, with people and groups. But there are permissions not related to content data, but in some way with other system data or system actions. That security scheme should be included in the structure that talk about those items.

How the permission should be represented? In the actual way to represent securiy, in general you have an 'feature_can_do_action' field and another for 'y' or 'n'. I was tempted to suggest that all features are by default off and have only 'feature_can_do_action' to mark that it is enabled, but that would give at least usability problems for inherited and attached objects. Is better to have things in the actual ways for an object when is specifically selected, and for others, that be applied system defaults or upper level objects permissions.

I think that using phpGACL or other alternatives will not change a lot this ideas, but whatever system is used, the basics that should do is to enable a dynamic set of permissions to be set for hierarchical objects in an implicit or explicit way.

There are also some implications in security if the implementation is as broad I suggest in TikiIntegration2. Lets think that users can define its "own" tiki, its own blogs, its own trackers, etc, sepparated from the system ones. Maybe we want that users could be able to do so, but in the other hand, we don't want that normal users create system objects like forums or things like that. That will be solved with "root" objects, one for the system, one for each user, one for each category, that can be set with system defaults, user groups defaults or security template schemes.

Upcoming Events

1)  Thu 23 Jan 2020 14:00 GMT-0000
Roundtable Meeting 2020 01

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.