This part will cover various topics:
Here is the read security model I want:
Also, unless explicitly specified, the visibility of an image should be the same as its parent folder, as well as visibility of a comment should be the same as the commented entity. If there is no parent entity, the default visibility is authenticated.
Regarding write security, that’s much easier: * anonymous can’t write anything * authenticated users can only add comment * managers will add the remaining stuff
Now, let’s implement that!
Proper security in CubicWeb is done at the schema level, so you don’t have to bother with it in views: users will only see what they can see automatically.
In schema, you can grant access according to groups, or to some RQL expressions: users get access if the expression returns some results. To implement the read security defined earlier, groups are not enough, we’ll need some RQL expression. Here is the idea:
So the first thing to do is to modify my cube’s schema.py to define those relations:
from yams.constraints import StaticVocabularyConstraint
class visibility(RelationDefinition):
subject = ('Folder', 'File', 'Comment')
object = 'String'
constraints = [StaticVocabularyConstraint(('public', 'authenticated',
'restricted', 'parent'))]
default = 'parent'
cardinality = '11' # required
class may_be_read_by(RelationDefinition):
__permissions__ = {
'read': ('managers', 'users'),
'add': ('managers',),
'delete': ('managers',),
}
subject = ('Folder', 'File', 'Comment',)
object = 'CWUser'
We can note the following points:
Now, we should be able to define security rules in the schema, based on these new attribute and relation. Here is the code to add to schema.py:
from cubicweb.schema import ERQLExpression
VISIBILITY_PERMISSIONS = {
'read': ('managers',
ERQLExpression('X visibility "public"'),
ERQLExpression('X may_be_read_by U')),
'add': ('managers',),
'update': ('managers', 'owners',),
'delete': ('managers', 'owners'),
}
AUTH_ONLY_PERMISSIONS = {
'read': ('managers', 'users'),
'add': ('managers',),
'update': ('managers', 'owners',),
'delete': ('managers', 'owners'),
}
CLASSIFIERS_PERMISSIONS = {
'read': ('managers', 'users', 'guests'),
'add': ('managers',),
'update': ('managers', 'owners',),
'delete': ('managers', 'owners'),
}
from cubes.folder.schema import Folder
from cubes.file.schema import File
from cubes.comment.schema import Comment
from cubes.person.schema import Person
from cubes.zone.schema import Zone
from cubes.tag.schema import Tag
Folder.__permissions__ = VISIBILITY_PERMISSIONS
File.__permissions__ = VISIBILITY_PERMISSIONS
Comment.__permissions__ = VISIBILITY_PERMISSIONS.copy()
Comment.__permissions__['add'] = ('managers', 'users',)
Person.__permissions__ = AUTH_ONLY_PERMISSIONS
Zone.__permissions__ = CLASSIFIERS_PERMISSIONS
Tag.__permissions__ = CLASSIFIERS_PERMISSIONS
What’s important in there:
To fullfill the requirements, we have to implement:
Also, unless explicity specified, visibility of an image should be the same as
its parent folder, as well as visibility of a comment should be the same as the
commented entity.
This kind of active rule will be done using CubicWeb’s hook system. Hooks are triggered on database event such as addition of new entity or relation.
The tricky part of the requirement is in unless explicitly specified, notably because when the entity is added, we don’t know yet its ‘parent’ entity (e.g. Folder of an File, File commented by a Comment). To handle such things, CubicWeb provides Operation, which allow to schedule things to do at commit time.
In our case we will:
Here is the code in cube’s hooks.py:
from cubicweb.selectors import is_instance
from cubicweb.server import hook
class SetVisibilityOp(hook.DataOperationMixIn, hook.Operation):
def precommit_event(self):
for eid in self.get_data():
entity = self.session.entity_from_eid(eid)
if entity.visibility == 'parent':
entity.set_attributes(visibility=u'authenticated')
class SetVisibilityHook(hook.Hook):
__regid__ = 'sytweb.setvisibility'
__select__ = hook.Hook.__select__ & is_instance('Folder', 'File', 'Comment')
events = ('after_add_entity',)
def __call__(self):
SetVisibilityOp.get_instance(self._cw).add_data(self.entity.eid)
class SetParentVisibilityHook(hook.Hook):
__regid__ = 'sytweb.setparentvisibility'
__select__ = hook.Hook.__select__ & hook.match_rtype('filed_under', 'comments')
events = ('after_add_relation',)
def __call__(self):
parent = self._cw.entity_from_eid(self.eidto)
child = self._cw.entity_from_eid(self.eidfrom)
if child.visibility == 'parent':
child.set_attributes(visibility=parent.visibility)
Notice:
The parent visibility value is used to tell “propagate using parent security” because we want that attribute to be required, so we can’t use None value else we’ll get an error before we get any chance to propagate...
Now, we also want to propagate the may_be_read_by relation. Fortunately, CubicWeb provides some base hook classes for such things, so we only have to add the following code to hooks.py:
# relations where the "parent" entity is the subject
S_RELS = set()
# relations where the "parent" entity is the object
O_RELS = set(('filed_under', 'comments',))
class AddEntitySecurityPropagationHook(hook.PropagateSubjectRelationHook):
"""propagate permissions when new entity are added"""
__regid__ = 'sytweb.addentity_security_propagation'
__select__ = (hook.PropagateSubjectRelationHook.__select__
& hook.match_rtype_sets(S_RELS, O_RELS))
main_rtype = 'may_be_read_by'
subject_relations = S_RELS
object_relations = O_RELS
class AddPermissionSecurityPropagationHook(hook.PropagateSubjectRelationAddHook):
"""propagate permissions when new entity are added"""
__regid__ = 'sytweb.addperm_security_propagation'
__select__ = (hook.PropagateSubjectRelationAddHook.__select__
& hook.match_rtype('may_be_read_by',))
subject_relations = S_RELS
object_relations = O_RELS
class DelPermissionSecurityPropagationHook(hook.PropagateSubjectRelationDelHook):
__regid__ = 'sytweb.delperm_security_propagation'
__select__ = (hook.PropagateSubjectRelationDelHook.__select__
& hook.match_rtype('may_be_read_by',))
subject_relations = S_RELS
object_relations = O_RELS
Security is tricky. Writing some tests for it is a very good idea. You should even write them first, as Test Driven Development recommends!
Here is a small test case that will check the basis of our security model, in test/unittest_sytweb.py:
from cubicweb.devtools.testlib import CubicWebTC
from cubicweb import Binary
class SecurityTC(CubicWebTC):
def test_visibility_propagation(self):
# create a user for later security checks
toto = self.create_user('toto')
# init some data using the default manager connection
req = self.request()
folder = req.create_entity('Folder',
name=u'restricted',
visibility=u'restricted')
photo1 = req.create_entity('File',
data_name=u'photo1.jpg',
data=Binary('xxx'),
filed_under=folder)
self.commit()
photo1.clear_all_caches() # good practice, avoid request cache effects
# visibility propagation
self.assertEquals(photo1.visibility, 'restricted')
# unless explicitly specified
photo2 = req.create_entity('File',
data_name=u'photo2.jpg',
data=Binary('xxx'),
visibility=u'public',
filed_under=folder)
self.commit()
self.assertEquals(photo2.visibility, 'public')
# test security
self.login('toto')
req = self.request()
self.assertEquals(len(req.execute('File X')), 1) # only the public one
self.assertEquals(len(req.execute('Folder X')), 0) # restricted...
# may_be_read_by propagation
self.restore_connection()
folder.set_relations(may_be_read_by=toto)
self.commit()
photo1.clear_all_caches()
self.failUnless(photo1.may_be_read_by)
# test security with permissions
self.login('toto')
req = self.request()
self.assertEquals(len(req.execute('File X')), 2) # now toto has access to photo2
self.assertEquals(len(req.execute('Folder X')), 1) # and to restricted folder
if __name__ == '__main__':
from logilab.common.testlib import unittest_main
unittest_main()
It’s not complete, but show most things you’ll want to do in tests: adding some content, creating users and connecting as them in the test, etc...
To run it type:
$ pytest unittest_sytweb.py
======================== unittest_sytweb.py ========================
-> creating tables [....................]
-> inserting default user and default groups.
-> storing the schema in the database [....................]
-> database for instance data initialized.
.
----------------------------------------------------------------------
Ran 1 test in 22.547s
OK
The first execution is taking time, since it creates a sqlite database for the test instance. The second one will be much quicker:
$ pytest unittest_sytweb.py
======================== unittest_sytweb.py ========================
.
----------------------------------------------------------------------
Ran 1 test in 2.662s
OK
If you do some changes in your schema, you’ll have to force regeneration of that database. You do that by removing the tmpdb files before running the test:
$ rm data/tmpdb*
Note
pytest is a very convenient utility used to control test execution. It is available from the logilab-common package.
Prior to those changes, I created an instance, feeded it with some data, so I don’t want to create a new one, but to migrate the existing one. Let’s see how to do that.
Migration commands should be put in the cube’s migration directory, in a file named file:<X.Y.Z>_Any.py (‘Any’ being there mostly for historical reason).
Here I’ll create a migration/0.2.0_Any.py file containing the following instructions:
add_relation_type('may_be_read_by')
add_relation_type('visibility')
sync_schema_props_perms()
Then I update the version number in cube’s __pkginfo__.py to 0.2.0. And that’s it! Those instructions will:
To migrate my instance I simply type:
cubicweb-ctl upgrade sytweb
You’ll then be asked some questions to do the migration step by step. You should say YES when it asks if a backup of your database should be done, so you can get back to initial state if anything goes wrong...