Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
Hello Everyone,
I have a service, that uses the createThing and deleteThing Services.
I gave a freshly created user the rights to execute the service and also the createThing and deleteThing services. But I still get the error
"...Not authorized for Delete - See Script Error Log for more details."
I only found some very old posts regarding this issue, which didn't solve it for me.
Any ideas what to do here?
Thank you very much in advance!
Best Regards,
Dominik
Solved! Go to Solution.
Please try to add a design-time permission to create things to System user on the Things collection level.
/ Constantine
Hello Dominik,
So what does ScriptLog and ApplicationLog say?
You also need to set design-time permissions on those things that you are deleting, not just runtime. You can do it either on the thing template level, or on a whole Things collection.
Regards,
Constantine
Hello Constantine,
thank you for your reply!
Unfortunately the Logs don't give usefull hints
Application Log:
Execution error in service script [createNodeInFolder] :: Not authorized for Create
Script Log:
Error in: projectOverviewRepo.createNodeInFolder javascript service
Here is a snipped from the code of the service:
var params = {
name: name /* STRING */,
description: undefined /* STRING */,
thingTemplateName: "projectRepositoryTemplate" /* THINGTEMPLATENAME */,
tags: undefined /* TAGS */
};
// no return
Resources["EntityServices"].CreateThing(params);
Things[name].EnableThing();
Things[name].RestartThing();
These are the permission configurations for "EntityServices" (Resrouces)
These are the permissions from the ThingTemplate that I want to create a Thing from
Run Time (same config for Run Time and Run Time Instance)
Design Time (same for Run Time and Run Time Instance)
Design Time (Same for Run Time and Run Time instance)
and Visibility for the organization that contains my user
Best Regards,
Dominik
Please try to add a design-time permission to create things to System user on the Things collection level.
/ Constantine
I never worked with Things collections
Could you please elaborate on how to do this configuration?
Edit: Just found out about it. I am going to try this out and let you know how it worked
Just a word of caution -- you need to be careful with those Collection permissions if you export your sources to source control. Being part of the system configuration they are not exported, so you would need to either remember to redo them manually after you import your sources, or (if you deploy frequently) do something like this:
Resources["CollectionFunctions"].AddCollectionDesignTimePermission(
{principal: 'System', principalType: 'User', collectionName: 'Things', type: 'Create', allow: true});
Resources["CollectionFunctions"].AddCollectionDesignTimePermission(
{principal: 'System', principalType: 'User', collectionName: 'Things', type: 'Read', allow: true});
Resources["CollectionFunctions"].AddCollectionDesignTimePermission(
{principal: 'System', principalType: 'User', collectionName: 'Things', type: 'Update', allow: true});
Resources["CollectionFunctions"].AddCollectionDesignTimePermission(
{principal: 'System', principalType: 'User', collectionName: 'Things', type: 'Delete', allow: true});
I usually call this service "SystemUtilities.PostImport" and execute after each import.
/ Constantine
Thank you, I will most probably make use of this!
Adding design-time permission for the System user solved my problem.
I assume the System user stands for "Services" that need to execute other Services?
Anyway, thank you very much for your help
@dr1 wrote:
I assume the System user stands for "Services" that need to execute other Services?
That's correct.
My usual approach to setting permissions is like this:
The true problem with permissions is keeping them up to date, as you evolve your codebase. It's relatively easy to get it right the first time (for example, by mechanically following the approach I mentioned above), but then it quickly gets out of control, because developers usually don't have the natural habbit of updating permissions every time they touch the code, and ThingWorx doesn't provide any compile-time checks for that either. It's a rather tricky problem, and I've seen it being an issue on a number of projects. The way we solved it internally is by implementing a tool, which automates those checks for us (it ensures that our private/public separation is up-to-date by getting the list of "public" services from mashups and comparing it with the complete list of services in the platform). It's not a silver bullet, but helps to reduce testing effort and allows us to deeply refactor our applications without fear that all permissions configs will get messed up.
/ Constantine