Why is it unable to access mashup after users group is removed from ComposerUsers group?

[eyli]

My Thingworx platform version is 8.4.0-b2013. I was trying to restrict access to Thingworx composer by removing users group from ComposerUsers group. But I was not able to access any mashup after that. How should I do?

[raluca_edu]

Hi,

You are trying to access mashup in runtime with the users removed from Composer users? What access rights and visibility have the mashup?

Thanks,

Raluca Edu

[eyli]

I added full privilege to that mashup for both visibility and run time. It works if I add this user back to ComposerUsers group. Seems user must be in ComposerUsers group to access the mashup run-time.

[raluca_edu]

Hi,

For accessing only a mashup in runtime, users should not be necessarily in Composer Group. Are there any errors in Application log? And it would be helpful also to attach screenshots to see the access rights.

Thank you,

Raluca Edu

[eyli]

I added this user "tester" to an organization and gave this organization visibility to a mashup "test". I also gave this user "tester" to full privilege to mashup "test" run-time. I attached the application log screen-shot.

[raluca_edu]

Hi,

Please follow the steps below with Administrator user:

• Login to Composer
• Go to System -> Resources
• Click on CollectionFunctions Resource
• Execute AddCollectionVisibilityPermission service with below parameters

1. collectionName - ThingPackages
2. principal - <Organization or Organizational Unit Name>
3. Organizational Units are declared as <Organization Name>:<Organizational Unit Name>
4. principalType - Organization / OrganizationalUnit

• For ThingWorx 8.4 and up the following must also be performed:
  • Login to Composer
  • Go to System -> Resources
  • Click on CollectionFunctions Resource
  • Execute AddCollectionRunTimePermission service with below parameters
    • collectionName - ThingPackages
    • type - ServiceInvoke
    • resource - * (all) / <Specific Property, Service or Event Name>
    • principal - <User or Group Name>
    • principalType - User / Group
    • Allow - True

Please let me know if you can access mashup after these steps.

Regards,

Raluca Edu

[eyli]

I ran both services as you suggested but the same application logs were generated

[rosharma]

actually it depends how user is accessing the mashup 

if user is accessing the mashup through formlogin page then i think there is no requirement for users group to be there in composerUser group . the explicit permissions (visibility, runtime) and collection permissions will come into picture here

And if user is trying to access the mashup by login to composer and copying the mashup url from view Mashup -then i believe users group or user been there in composerGroup comes into picture. because that url would be like /Thingworx/Runtime/index.html#master=xxxxxx&mashup=yyyyyy this format and that might have implicit access to composer

[eyli]

I did tried accessing the mashup via FormLogin and met this issue.

[eyli]

Does anyone has other ideas to fix this issue?

[rosharma]

hi,

i tried again reproducing this issue.

in both scenarios whether login through formlogin or by copying the url - users group or user has to be there in composerUsers group to access the mashup. removing users group or user from composerUser group don't allow user to access the mashup. ( as said earlier the url has implicit permissions to composer)

now even users group or user is there in composerUser group and still user is not able to access the mashup

then probably first verify if design time permissions are also provided to Mashups ( through collection ) considering the visibility and run time permissions are already there. 

[eyli]

So it means the functionality to limit specifics users from accessing the design time environment does not work because it also limits the run time access which is NOT what I wanted. This should be an anomaly as the help file says it should be able to deny deign time access from users.  It means the end user can access the design time environment which the system integrator / developer doesn't want.

Thanks for your help.

[rosharma]

NOT necessarily .

you can include users/user group in design time permissions to only view mashups 

if you deny (cross) design time permissions on create, update & delete for user/user groups and only put allow on Read -then it will allow users to only view the mashup. the mashup will not open in edit mode.

and if you put allow for all ( create, read, update & delete) then only mashup will open in edit mode.

this way you can restrict/limit users

[eyli]

What I wanted is the end user can not access the design time environment, the composer, but only the run-time.

[rosharma]

even if user is able to access the composer (because users group is there in composerUser Group) but you can restrict that user from viewing the entities.

you can restrict user by denying the visibility permissions on entities through collections.

in this way even if user is able to access the composer but won't be able to view the entities and that i think solves our purpose

[eyli]

The question is does the visibility apply for run time or design time or both? 

[rosharma]

generally visibility does applies for runtime . entity has to be visible to user so that it effects runtime operations. if it is not visible than runtime will also not work

design time will only come into picture when user needs to edit those entities. if requirement of user is not to edit that entity for any of the purpose like adding properties or writing services than no need for design time. 

the same user can work through that entity(like service executions /property updates and all) only through both visibility and runtime simultaneously without any need to have design time permissions.

and if user only wants entity to be visible (no runtime operations) then user can set only visibility permissions. but for runtime permissions to take place visibility is required

[eyli]

All right. Hopefully the feature to limit user from accessing the design time the composer could be added in next versions. Example: URL like "http:<IP>:<Port>/Thingworx/Composer/*" is dynied. URL like "http:<IP>:<Port>/Thingworx/Runtime/*" or "http:<IP>:<Port>/Thingworx/FormLogin/*" is allowed.

[Constantine · Accepted solution]

Hello @eyli,

I've just tried to reproduce this issue in my 8.5.1 and managed to make it work. I removed Users from ComposerUsers group and added the following permissions:

1. On the "Mashups" collection permissions > Design time > Read for all Users
2. The same on the "Style Themes"
3. Added some run-time permissions on PlatformSubsystem to allow my users to execute GetAllStateDefinitions, etc.

(obviously you might need to add more).

After doing that my user can see the mashups rendered correctly, but sees a "Not authorized" error when trying to access the Composer.

Regards,
Constantine

[eyli]

This does works. Thanks very much.