09-01-2016 06:48 AM
Hi,
I just ran across an issue with one of our custom Unity API applications that does keyword modifications. I found the cause of this issue explained in the blog post "Modifying Keywords through the Unity API in OnBase 16" and saw the change that was being made to address this issue from within workflow with Unity Scripts but I'm trying to see what work around (if any) can be used for external API applications. The quick fix would be to grant the modify keyword permission but in doing so would also allow users to modify the keywords (any keywords on the doc type) from within any client as well since they also have access and needs to retrieve these documents from within the OnBase client(s). This custom application allows keyword modification in a controlled setting so they are only able to modify specific keywords. Just trying to get some other ideas/thoughs if someone else has ran into similiar issues.
Thanks
Anthony
09-01-2016 07:24 AM
We're not on OnBase 16 yet, but I've been following that thread with interest. I understand the security implications of the old behavior, but it seems like a significant breaking change.
For the current behavior, I can think of two solutions that I don't like:
I think a reasonable solution would be for Hyland to make two changes:
09-01-2016 08:41 AM
09-01-2016 08:52 AM
It looks like my first comment didn't make it... or now the second attempt to comment... so I'll try again...
I think I do understand Application Identities as currently implemented. They allow a layer of configuration to prevent outdated, malicious, or just uncontrolled use of the API.
But you don't have to setup their usage at all (so they don't break existing setups), and the current implementation doesn't enforce any different kinds of security after the connection is created.
I would suggest that a sensible way to close the previous security gap would be to allow external API a way to easily-but-intentionally override keyword modification privileges, *if and only if * the connection is made using an Application Identity, and maybe only if that Application Identity has a specific configuration choice to allow the override.
This would put individual installations in control, secure but configurable, compared to what I understand was implemented in 16, or the limited fix that I've heard about that will only affect some types of Unity scripts.
We will get in touch with Team M to be added to the SCR and make these suggestions. Thanks for suggesting that Tyler.
09-01-2016 07:25 AM
09-07-2016 10:25 PM
Just find the keyword that needed to be updated from application core
KeywordType keywordType = core.KeywordTypes.Find("Invoice #");
// Create keyword modifier object to hold keyword changes
KeywordModifier keywordModifier = unityDocument.CreateKeywordModifier();
//Create a New Keyword
Hyland.Unity.Keyword newKeyword;
newKeyword = keywordType.CreateKeyword("1234");
//Get keyword record
KeywordRecord keywordRecord = unityDocument.KeywordRecords.Find(keywordType);
if (keywordRecord != null)
{
Hyland.Unity.Keyword oldKeyword = keywordRecord.Keywords.Find(keywordType);
keywordModifier.UpdateKeyword(oldKeyword, newKeyword);
}
keywordModifier.ApplyChanges();
these steps to modify Keyword works for me in OnBase16.
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.