In this page I'm going to collect miscellaneous implementation notes, best practices etc.

Security Checks in Services

From an email by David Jones

In general security checks should follow this sort of pattern:

IFF has General Permission THEN allow
ELSE IFF has Limited Permission and is related to entity with X role THEN allow
ELSE IFF logged in user has partyId that equals entity.partyId THEN allow
ELSE reject

Not everything will have all of these conditions, but in general there should be general/admin permissions that are checked before the userLogin's partyId is checked. 

About ContentAssoc and CMS setup 

From an email by Al Byers

The logic that David Jones came up with is that you take the parent contentId and a mapKey and you go "to" the subcontent. It would not make sense the other way around, since you don't need the mapKey to go to a parent. So contentId is for the parent and contentIdTo is for the child.

MapKey  is basically so that a contentId can identify the subcontent that goes on a page and the various mapKeys (eg. MAIN, SUMMARY, HEADER, FOOTER, etc.) identify where they go on a page.

About permissions

Question by Adrian Crum 

I noticed that the Asset Maint component requires the OFBTOOLS base permission to use the component. So, I added that permission to a test user login. The Asset Maint component appears for that user login. When I try to perform any work, I get permissions errors because the Asset Maint component calls services in other components - which have their own sets of permissions.

Updating a maintenance produced this error message:

"Security Error: to run updateFixedAssetMaint you must have the ACCOUNTING_UPDATE or ACCOUNTING_ADMIN permission, or the limited ACCOUNTING_ROLE_UPDATE permission calling service updateFixedAssetMaint in updateFixedAssetMaintAndWorkEffort"

The ACCOUNTING_ROLE_UPDATE permission doesn't exist. I added it manually to the test user login. After logging out and back in, I still get the same error message. I added the ACCOUNTING_UPDATE permission to the user login, and I was able to update a maintenance. Problem is, that gives me permission to update other things in Accounting..

This is the same type of problem I ran into with Forums - the Forum feature calls Content Manager services which require Content Manager permissions.

I've suggested separating business logic from permissions checking logic in the past, but that got a mixed response. I could do that with the FixedAssetServices.xml file - move the embedded permissions checking to a separate service (using the new permissions checking capability).
 

Response by David Jones

 Just define where alternate permissions are acceptable and add those cases to the permission checking services.

The new permission-service stuff in the service engine (see the example entity for examples ) makes this easier.

You can extend the base permission service using ECA rules on the permission service used by the service you want to reuse. Just have it run your permission service after the main one IFF the main one results in an error (failed permission check), and make sure your ECA rule has it put its results in the context if your security scenario succeeds, and off you go...