Create and Delete Thing Permission Issue

[dr1]

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

[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

[dr1]

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)

[dr1]

Design Time (Same for Run Time and Run Time instance)

and Visibility for the organization that contains my user

Best Regards,

Dominik

[Constantine · Accepted solution]

Please try to add a design-time permission to create things to System user on the Things collection level.

/ Constantine

[dr1]

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

[Constantine]

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

[dr1]

Thank you, I will most probably make use of this!

[dr1]

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

[Constantine]

---

@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:

• For all "external" services (which have to be available from outside of the server, e.g. all those used in mashups or exposed as external HTTP APIs) we carefully configure permissions based on user groups
  • In more complex applications we use the "matrix" approach, with two sets of groups -- Func* and Role*, for example FuncCreateDevice, FuncDeleteDevice, etc. and RoleFieldEngineer, RoleSystemAdmin, etc. -- this allows us to configure access for different user roles by simply including them into one another. In this case permissions to separate services are given to those Func* groups only.
• For all "internal" services (and things) we grant full access to System user, so that it can execute any services -- it allows us to simplify configuration, because when you have hundreds of things, thing templates and shapes, each with a dozen of services, this quickly gets out of control, so you should think of streamlining it as early as possible.
• To quickly distinguish between those two types of services and simplify maintenance we prefix the 2nd type with "Private", e.g. "PrivateCreateThing", etc.

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