Controlling Application - a_controlling_app 用户总是得到READ权限

  症状:  遇到一种情况，发现用户只能得到READ权限(该用户不是super user)
   
   content server授予用户权限时会进行下列检查:

   1. content server 首先检查SysObject的a_controlling_app属性
   2. 如果它是空的，用户将得到基于ACL的权限。
   3. 如果它有值，将会与apiconfig或者sessionconifg里application_code属性值相比较
   4. 如果相同，权限会基于ACL
   5. 如果不同，用户将会得到docbase_config的属性default_app_permit定义的权限. 默认的权限是READ. 所以，如果用户使用其它application来读取这个SysObject, 他将会得到READ权限. 请注意，用户只会得到default_app_permit 或者 ACL定义的最严格的权限

Controlling Application - a_controlling_app

This might not be dirty little secrets, but I was recently stumped for a while trying to debug a problem in a custom application built by someone else. Let me describe the symptoms first:

1. ACL assigned to object gave me (group) DELETE permissions on the object
2. The attributes for the object were displayed as read-only
3. When viewing the permissions on the object, Webtop said that I only had READ permissions
4. When the extended privilege was set to superuser, I was able to edit the attributes – therefore, the data dictionary was set to read-only

After some investigation, I noticed that the a_controlling_app attribute was set to some custom value. I have seen this value being set before for Webpublisher and DCM application. I remember thatthis attribute allowed you to map control of an object with a specific application. In other words, you cant modify an object instance unless you are using the application that is specified in thea_controlling_app attribute.That makes sense, but where is the mapping defined?

Well, I had to go back to Content Server Fundamentals to find the answer:

“To identify to the system which objects it can modify, an application sets the application_code attribute in either the apiconfig or sessionconfig object when the application is started. (Setting the attribute in the apiconfig, rather than the session config, provides performance benefits.) The application_code attribute is a repeating attribute. On start-up, an application can set application_code to multiple application codes if users are allowed to modify objects controlled by multiple applications through that particular application.”

The issue here was that the client was using Records Management Administrator (RMA) to try to update the content (not the application defined by thea_controlling_app attribute). But why the READ permissions?

Again going back to Fundamentals, the content server will perform the following checks to grant the user his/her proper privilege:

1. The content server checks the a_controlling_app attribute of the SysObject.
2. If the attribute is blank, the user will be granted access based on the ACL; given that Docbase security is turned on.
3. If the attribute contains a value, it will be compared with the values in theapplication_code attribute of apiconfig or sessionconfig objects.
4. If there is a match, the ACL on the object will control the access.
5. If no matching code is found, the user will be granted access as defined in thedefault_app_permit attribute of the docbase_config.The default value of this attribute is READ. So, if the user uses a different application to access the SysObject, he will get READ access.Please, note that the user will get the most restrictive access to the object whichever is more:default_app_permit or ACL

Ah hah, now the secret is known. To solve this problem, I can either

1) set the a_controlling_app attribute to null (or dmc_rm) or

2) set default_app_permit to something higher – DELETE.

I recommend Option 1.  Option 2 sort of defeats the idea of having a controlling application.

 

[转自http://johnnygee.wordpress.com/2007/11/19/controlling-application-dirty-little-secrets/]