Hi Dave,
I don't see any reason to add any additional security checks
That's correct. It's only that P/O has several additional security features that are not know available in the general OpenACS platform. Obviously these features result in custom code.
However, there is one main feature that you might consider in .LRN: "Profile-based permissions". For example if you want to grant "University Employees" permission to access all course material. Or to "Staff Professors".
"Profile based" permissions work really differently from "Object based permissions" (the only way to express security in OpenACS):
- Object based permission require a specific entry in a database table for every group-object relationship. Or an equivalent recursive lookup query. (This is a little bit like forward against backwards inference in artificial intelligence reasoners. Do you remember the 80'? 😊 )
- Profile based permissioin work without explicit reference to an object (there is no "object_id" in the permission tables). You can say: Every "Employee" should have access to all course material.
The "generic implementation school" (I'm not going to name its members in the OpenACS community... 😊 ) will argue: "You can implement all profile-based permission using object-based permissions". That is right. But granting object-based based permission for 100,000 documents to 10,000 users will create some 1G records in the denormalized permission cache or the equivalent number of recursive queries if the relationship is not denormalized.
If we run acs_permission__perission_p on 10 objects,
the results should be fast enough
That's OK and that's great. However, that means that you have to run acs_permission__perission_p at the "result page" and not in the "tsearch2_driver" in the service contract routine. (Because otherwise you would have to run the security check on _all_ results).
The HP printer guys just ran into that trap: They had to run the permission check on the entire result set of 10 million records, resulting in about 20-40 CPU seconds of a _seriously_ big Oracle server...
The situation in Project/Open is even a bit more complext, because we have different "container rules" for different object types. So we need to be flexible even in the main TSearch2 SQL query in order to eliminate entries as early as possible in the database execution path.
Bests,
Frank
