Thingworx Mashup - Not Authorized for Read

[Sathishkumar_C]

For few mashups especially we used as popup, we are getting "Reason: 401 - Not Authorized for Read" in QA. But the same user role and permissions, we able to see that mashup in runtime as popup in Development Environment.

Its working after enable the "Design Time permission - READ" in QA.

My query is why its not appearing any permission related issues in Development? And, its appearing in QA even though the same permissions.

We are having an following thingworx instances in Development and QA environment.
Development Server - ThingWorx 9.1.9-b887
QA Server - ThingWorx 9.1.7-b776 

[VladimirN]

---

@Sathishkumar_C wrote:

... we are getting "Reason: 401 - Not Authorized for Read" ...

---

The only article mentioning this error is - "ThingWorx Analytics Things are not getting created in ThingWorx due to incorrect application key": https://www.ptc.com/en/support/article/cs271012 

[Sathishkumar_C]

Thanks for the information. Unfortunately, it's not useful in our case. We were not using thingworx analytics.  

[PaiChung]

Assigning Design Time - Read is the right way to solve this.

I've seen a few threads now on this, partly when users are removed from Composer users.

Not sure if the behavior is a difference between the versions, or if perhaps you have some collection permissions set in QA vs. Dev.

[Sathishkumar_C]

Yes. That user is not part of composer group. Its okay to assigning design time permission. But my doubt is the same level of permission and it is working fine with Dev environment.

[PaiChung]

I understand, and unfortunately that is something I can't explain, but you could log a ticket with support for that.

[nmutter]

check actual user permissions via "Access Report" feature on the mashup. Most likely you think the permissions are the same but sometime, somwhere something was done and so permissions may differ. Access report might give you a hint.

It is a real mess to find out permissions differences between instances!

[SK_10629157]

@PaiChung Isn't it a tedious work to define permissions on each OOTB mashup in the APP?. First it has to be dug out which all mashups are used and then give the permissions explicitly. Why there is not separation of permissions maintained between a composer and a normal app user. 

[PaiChung]

I do not disagree, I actually coded a tool a long time back to help with that, by now probably so old it likely doesn't work anymore.

But it scanned a mashup for service calls and then set permissions appropriately aside from 'generically needed' permissions.

I recommend you put in an improvement request for this.

[SK_10629157]

Yeah that could be done. Somewhere in the documentation, at least a disclaimer for the criticality of ComposerUser Group for OOTB apps would have helped. 
Anyway, If you don't mind to share the tool offline, it could help us with the present use case. May be I can improve on that and share back, if at all possible. 
Thanks

[PaiChung]

Sharing will be ... impossible? Looks like I did this in 2019! I'm not even sure what version of TWX that would've been.

The basic idea: I had an interface that could pick a mashup and then a user/user group

Code would pull the definition of the mashup and any contained mashups if defined

Then it would pull any services defined and their Thing/ThingTemplate

It would then apply the runtime/visibility permissions to those specific mashups/services either on Entity, Thing or ThingTemplate level

It also if necessary would grant the user / user group default runtime/design time/visibility permissions needed for anyone to have runtime abilities

Finally I remember there was one exception case which was for GetProperties where I need to give specific Read Property ability for the entity or ThingTemplate in question.

[SK_10629157]

Thanks for letting me know the steps, let's see if this could be done.