Web Services: Non-Admin unable to query "sys_user" table

MattGlew · ‎02-28-2014

This is an odd one; it only seems to be possible to query the sys_user table if one is a member of the admin role.

The non-admin I'm testing with has the 'soap' role, and has read + write access to all fields in the sys_user table (confirmed by logging onto the instance in a browser etc.), however they return no results when attempting to query the table using web services. No error is thrown, they simply get no results (same for other non-admin accounts). The exact same code when run using an admin's credentials successfully retrieves records.

I don't have any query business rules in effect for non-interactive sessions, so am stumped!

Can anyone offer any advice / suggestions etc.?

Matt

MattGlew · ‎03-03-2014

Solved; my test WS user was first added as a member of a custom security role. This role was later added to the soap security role. For some reason this sequence of events (adding users to roles / roles to roles) meant that my actual test user hadn't been delegated soap access.

As soon as I added a test user directly to the soap role I got results... So removed group from the custom role, re-added it and got lots of info messages about adding users to roles. Bingo.

This was SO frustrating! ServiceNow is horrifically optimistic - it just doesn't "do" error messages!! I can't believe that without a SOAP role I didn't get an error when attempting to query a table!! I just got served an empty recordset, as though everything was fine! Grrrr....

View solution in original post

eican · ‎02-28-2014

There could be a business rule blocking non interactive sessions from doing so.

prdelong · ‎03-02-2014

Have you tried enabling security debugging when you logged in as the WS user?

MattGlew · ‎03-03-2014

Thanks for your comments - my WS user is able to see/read all sys_user records in ServiceNow "proper" (i.e. logged into full UI in browser).

If I temporarily set the property "glide.soap.strict_security" to false (Enforce strict security on incoming SOAP requests), then the WS user is able to successfully query the sys_user table. So it would seem there's an ACL issue, rather than a business rule being at fault? I've ensured there are read ACLs for "sys_user" and "sys_user.*", but no luck.

N.B. This work is being conducted in my DEV instance, which has recently been upgraded to Calgary. If I try this in my TEST instance, which is still on Aspen; the issue does NOT occur. So... Calgary problem, or instance problem, hmmm... If only I didn't have so much "stuff" in DEV I'd get it overwritten with a clone from TEST.

eican · ‎03-03-2014

It still could be a business rule issue.

Within a business rule you can check if a user session is interactive or not.

gs.getSession().isInteractive()