|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||||
See:
Description
| Interface Summary | |
|---|---|
| IDeleteHelper | Handles delete, undelete, and permanent delete. |
| ILockHelper | Helper class that stores, retrieves, and removes lock tokens. |
| IOwnerLookupHelper | Provides a pluggable way to lookup the owner of a RepositoryFile. |
| IPathConversionHelper | Converts between absolute and relative paths. |
| ITransformer<T extends IRepositoryFileData> | A pluggable method for reading and writing IRepositoryFileData implementations. |
| Class Summary | |
|---|---|
| DefaultDeleteHelper | Default implementation of IDeleteHelper. |
| DefaultOwnerLookupHelper | Default IOwnerLookupHelper implementation. |
| DefaultPathConversionHelper | Default IPathConversionHelper implementation. |
| JcrRepositoryFileDao | CRUD operations against JCR. |
| JcrRepositoryFileUtils | Class of static methods where the real JCR work takes place. |
| PentahoJcrConstants | Pentaho JCR constants. |
Reading and writing of files is separated from reading and writing of ACLs because the former can be accomplished using the pure JCR API. The latter sometimes (and does in this implementation) requires access to repository-specific (e.g. Jackrabbit) APIs. Moving to eXo or Alfresco would only entail changing the ACL read/write code.
It is not trivial to implement custom privileges (e.g. EXECUTE) in Jackrabbit. See JCR-2446. EXECUTE is a somewhat poor example in that Jackrabbit would never enforce EXECUTE on a file. Jackrabbit cannot know what a user will do with a node. However, Jackrabbit could enforce EXECUTE on a folder. In Unix, EXECUTE on a folder governs folder traversal. But going back to EXECUTE on a file, even though Jackrabbit won't enforce EXECUTE on a file, it should be able to read and write the EXECUTE privilege to access control entries. As of today, custom privilege registration is not trivial.
Node ownership is an access control issue. In other words, getting the owner should be governed by the READ_ACCESS_CONTROL privilege. Similarly, setting the owner should be governed by the MODIFY_ACCESS_CONTROL privilege. To enforce this privilege, you must go through the access control API. A custom property on a node that represents the owner could be read with merely the READ privilege. Similary, that property could be written with merely the MODIFY_PROPERTIES privilege. Therefore, using a custom property is insufficient.
To put it another way, certain operations (e.g. access control reading and writing) do not use the standard JCR Item/Node/Property API, even though Jackrabbit implements ACLs as properties. This is because Jackrabbit implements them as "protected properties." The specification requires the reading and writing of protected properties to go through a "feature-specific API" (e.g. AccessControlManager.setPolicy). See section 16.3.12 in JSR-283 "Interaction with Protected Properties."
In addition to node ownership, Jackrabbit's ACL type was extended to provide an explicit "inherit" flag. If set to true, entries are inherited from the first ancestor whose "inherit" flag is false. This explicit flag is considered more desirable than a convention such as, "any ACL with no ACEs should inherit."
The implementation is intentionally unaware of any folder paths. For example, it doesn't know what a tenant root folder is. For one, this keeps pathing (which should be customizable) out of the core.
In this implementation, all locks are open-scoped. That's because sessions are short-lived. Therefore it is necessary to persist lock tokens for retrieval from subsequent sessions. See section 8.4.7 of the JSR-170.
JCR locking was extended to add "message" (aka "comment") and "date" properties in addition to the standard "lock owner."
JCR versioning was extended to add "message" (aka "comment") and "author" properties.
All Pentaho file and folder nodes can have localizable properties. Examples are title and description.
In web applications, many times a user is already authenticated by the time he accesses the Jackrabbit repository. In this case, we don't care about checking the password. In fact, sometimes the user's password is not available to the web application. (This can happen if the web application participates in a SSO system.) In a pre-authentication scenario, we simply check that a token in the JCR Credentials exists and matches a set of known tokens. If there is a match, that implies a trust relationship between the web application and the Jackrabbit repository. There is one token per application.
The current user and tenant is controlled by the IPentahoSession instance in the PentahoSessionHolder. Usually this is updated when a new user logs in. This implementation sometimes changes the current IPentahoSession instance temporarily to do superuser activities like creating the root folder.
In this implementation, recycle bin behavior is configurable.
Some methods exist to allow privileged users to run reports on all tenants or a particular tenant or to perform maintenance on all tenants or a particular tenant. These methods should (1) require authorization and (2) not require a tenant ID. (The user executing the privileged method might be in a different tenant than the tenant on which he/she wants to operate.) Proposal: prefix all admin methods with "admin."
Remember that the repository is accessed with the user's credentials and is subject to his/her privileges. Here are some options that were considered for handling storage structures such as lock tokens:
PROBLEMS WITH THIS APPROACH: The ability to read a lock token leads to the ability to write a file without owning the lock.
PROBLEMS WITH THIS APPROACH: In the case of lock tokens, the lock token is given to the user during the lock operation. The user would need to store the lock token temporarily so that the admin user could come after and move the token to the protected structure.
PROBLEMS WITH THIS APPROACH: No ability to export data. Transactions across multiple resources.
|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||||