504 views

 

Find ACLs, blocking the REST API updates | Troubleshooting



Overview


This provides a way to find out the ACLs blocking the updates made by REST call, when the same user updates the same record via UI.

To check via UI, enable Debug Security option in the SNOW instance, to find out what ACL is blocking to read/write/create/delete, etc any record when the respective update is made.

Unfortunately, when any record is read/inserted/updated via REST API, those Security Debug/ACL debug statements are not visible. Those updates are made via REST, somewhere not from the record page, but the ACL debug statements, passed or failed,  are seen only on the page of the record itself, which is only possible via UI and not via REST.

 

Steps to Troubleshoot


  1. From the Navigator, enable Debug Security.



  2. Navigate to the REST API Explorer module and add an additional header: X-WantSessionDebugMessages with value as true while making the REST call.

    Setting the header X-WantSessionDebugMessages to true in the REST request returns the session debug messages for the current session, which also includes the Security Debugs.

    Note: Enable Security Debugging or Session debugging before sending this header.

     


    This example demonstrates a Table API request made using REST API Explorer with Session Debug SQL enabled.



  3. Capture and copy the complete response in a text editor.

  4. Search for text result_false.gifx in the response. result_false.gifx is just the name of the Red (x) image icon, image file name which appears on UI when some table or field level ACL does not pass.


     

    Note: If there was not any result_false.gifx text in the response, this means that no ACL is failed. Therefore either there is no ACL to give access to the record (if by default its deny access) or it is not an ACL issue.
    If there is No ACL to give access to the record then create and test a new read/write/create/delete ACL (as per issue) for the REST update to go through. ServiceNow Documentation to Create an ACL rule: LINK



  5. Once the result_false.gifx text is located in the response, look for the href tag following it, which points to sys_security_acl record. As shown in the example below, the href points to sys_security_acl record with sys_id 35eceb66ff300200158bffffffffff1a.

    example href tag:  <a href=\"/sys_security_acl.do?sys_id=35eceb66ff300200158bffffffffff1a\" class=\"linked\" data-type=\"hyper_link\" target=\"_blank\" >




    Note: Once the result_false.gifx text is located in the response, but without any href tag pointing to sys_security_acl record, this means it is not an ACL issue. 



  6. Find all the ACLs which have the corresponding result_false.gifx text in the response. Navigate to them and review them individually to determine why they are not matching the conditions to pass when the request is made by the REST API user.

    For the above example, there is a read ACL on sn_si_incident table which didn't pass, via sys_id.


     

 

Article Information

Last Updated:2018-01-29 07:22:59
Published:2017-08-07