REST_endpoint acl

[Tim34]

We have a REST_endpoint acl that is only allowing read operations on the Table API. We are able to accomplish this by using the scripting option in the ACL. However, we want to only allow comments to be made on the sc_req_item table (while making everything else read-only).

If I do this at the table or field acl level (and not REST_endpoint), I don't know how to tell if it's coming from the TABLE api or not. And if we do it at the REST_endpoint level, I don't know how to tell if the update to sc_req_item table is only modifying the comment field.

Do you know how we can accomplish this? 

[Jorn van Beek]

Unless you use a scripted API that adds a comment with 'update done by API' you will never be able to tell if an update is done by an user in the system of by an user using an API. Also note that ServiceNow uses their own APIs to update things. Example is when an user request something though the service catalog on the portal.

I can understand from a developer point of view it is interresting to know how an update was made, but not from an business point of view. From a business point of view it important to know who made the update not how.

In most cases I have worked with only Service Accounts used API to communicate data. In those cases the updates were made by those Service Accounts and would be rather easy to see if they came from API or not.

[Tim34]

Thanks for your reply Jorn. The thing about this is, we are using Service Accounts to make these updates. I should have mentioned this in my original description, but we are trying to make the "Table API" read-only, except for comments on RITMs. However, from the Import Set api, users can make updates to these tables. We need to be able to actually tell which REST API they are using as well, to only set these rules to the Table API. 

[Jorn van Beek]

Hoi Tim,

It sounds you want to do something that was not the 'intended' that way. Accourding to ServiceNow you should limit the permissions on the user (or in this case service accounts) to allow only write access to the comments on RITM.

In this case you would not need to limit the API itself therefore not changing its functionality, nor will run into possible issues during upgrades.

However I can understand that setting up only write access to comments on RITM via ACLs can be quite bothersome to do.

This is why I for most cases still prefer to create a custom API rather then using the Table API. Only in specific cases I will use the table API. The power you give to users (other systems) by giving them access to it is hugh and the work you need to put in to limit it to what is needed is often way more then just create a custom API.

[Pavel Zifcak1]

Hi @Tim34, could you please share how exactly did you manage to have a REST_endpoint acl that is only allowing read operations on the Table API by using the scripting option in the ACL?

We have some custom table (extended from ootb) for which we have created Custom REST API and we would like to prevent users from modifying data of that table via standard Table API, but we would like to let them the option to read.