Proper Role Permissions for Executing Queries via REST

Good afternoon - I am in the process of writing a AngularJS front-end for some CoS functions that my integration team uses for auditing, analyzing and various other purposes. I have re-tooled the functions to return JSON results that AngularJS can then interpret and display. Many kudos to the AngularJS series on this site for giving me a jump start.

One of these functions uses %SQL.Statement to prepare a class query on %Dictionary.CompiledClassQuery, Summary. This works perfectly if I give the web app making the call %All privileges but obviously I don't want to do that. I cannot determine the appropriate privilege(s) needed to execute this query otherwise however. My REST call simply returns ERROR 5540 - UserUnknownUserisnotprivilegedfortheoperation.

I have attempted to the give the Web App's unique Role EXECUTE privileges to %Dictionary.CompiledClassQuery_Summary and several other things without success.

 

Would someone please be able to point me in the right direction?

Thank you!

Craig Regester

  • 0
  • 0
  • 242
  • 5
  • 1

Answers

 ERROR 5540 - User "UnknownUser" is not privileged for the operation.
This tells me that you don't login with a managed user with enough privileges.

So you could have a dedicated user just for this purpose.
OR
give "Unknown User" enough rights
OR
make use of a Privileged Application to assign temporary required Resources (my guess "%Developer") 

more on this and pp.
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.PortalHelpPag...

 

 

 

Thanks for your answer, Robert. I had considered the option of using a 'Privileged Application' and after your post, have started down that path but that still leaves open my original question...

How do I determine what resource/privilege is required to execute this query?  %Developer does not work. 

Is there documentation I'm missing in the API reference or elsewhere that indicates the necessary permissions needed to make certain calls? I only wish to grant the minimum necessary but right now, only %All makes it work. Is there some sort of debug I can use to see what role it's running a $SYSTEM.Security.Check on when it tries to execute this query?

I'm sorry.

I'm not aware of ANY documentation on required privileges by any Query.
I understand quite well your intention but especially <Protect> is hard to trap double hard inside a Class Query
With privileged app you limit the scope and get control over access parameters. 
 

Thanks Robert, I understand. I ended up solving this another way anyway... I realized I did not have my REST Dispatch Web App sharing the same cookies path as my main web app so even though I was logging in with authorized credentials that should have no problem running this query, when I tried to execute it via REST I passed into another 'cookie domain' and lost the authorization header.

Once I fixed that setting, it works just fine for the users it should and I don't have to grant Unknown User elevated privileges, which is ideal.

 

Thanks again!

Comments

Just encountered the similar situation when following the exercise of building a RESTful web service in the Learning Service... if I ran the simple GET which requires running a dynamic SQL at the back, it gave me empty results if I did it with UnknownUser, while something returned for SuperUser.

Then I tried adding all possible roles except %ALL to that web application as "Application Roles" (automatically added to the current role set). Yet still the Dynamic SQL wouldn't return me anything. Again, I tried adding the last %ALL to confirm that working with it, and it did.

It seems to me there are something other than those available roles required to be granted or added, in order to run dynamic SQL in a RESTful web service. Just realise this post was written about 18 months ago, and wonder if someone could shed me light on it.

I think I know the reason. For the table I was giving SQL queries against in that RESTful web service, it corresponded to a particular DB and the resource and role representing it was %DB_XXX. However, even if I added this %DB_XXX to the list of Application Roles of that CSP path, the UnknownUser still didn't have the sufficient right to access that table, because %DB_XXX didn't include the rights to specific SQL tables.

If later I created a new role, copying from %DB_XXX, and in addition to it I gave the CRUD rights to my target tables, then added this new role to the list of Application Roles of my CSP path, the dynamic SQL could be run and return results even with UnknownUser.