Privacy on client-callable script includes (instance security hardening) explained

[Martin Ivanov]

TLDR: ServiceNow has introduced a mechanism to protect Client callable script includes. Skip to Conclusion for more info.

 

Intro

It’s been a while since I last wrote a client callable script include in my PDI.  Today I was implementing something for internal demo, and when I clicked Save, I was prompted to ‘Select a user role for Access Control on this Client Callable Script Include’. Wait, what?

Diagnosis

I selected admin, just for the trial and I got a message that a new ACL is created for this script include and role admin.

The newly created ACL was also shown in a related list, just below the script include:

It has operation ‘execute’ and type of ‘client_callable_script_include’.

Okay, what’s next – let me see what this thing is.

A bit of a code search using my favourite SNUtils and I found that this message is contained in ‘Save’ and ‘Submit’ UI actions, working on ‘sys_script_include’ table.

A little bit deeper dig led me to a property that’s being attached to the ‘g_scratchpad’ object (g_scratchpad.enable_acl_create_ux), which is being calculated based on the value of a system property: ‘glide.script.ccsi.enable_acl_create_ux’.

Conclusion

To recap, if your instance has this property and its value is set to true, then you will be prompted to create an ACL for every client callable script include.

Of course, I did search the documentation about that. The above-mentioned property is not described anywhere, but there is another one, which sets the public exposure of Client callable script includes: glide.script.ccsi.ispublic. This property can be created and set to false, in order to enable privacy control over all client-callable script includes accessed by public pages.

Important note is that you cannot add the property with a value of true, or change its value from false to true. If you attempt to do so, an error message appears.

If needed, you can change the privacy setting for an individual client-callable script include by adding the isPublic() function.

• The isPublic() setting takes precedence over the glide.script.ccsi.ispublic property.
• For example, if you set isPublic() to true in an individual script, it makes it public, which overrides the glide.script.ccsi.ispublic property that makes all other client-callable script includes private.

This has been introduced to harden the instance security, as stated by the documentation.

Please feel free to Like and Bookmark this article if you find it useful. Visit my profile to read other my articles.

Thank you!

Martin Ivanov

2022 Community Rising Star

[jorgegrc]

Thanks for the investigation! I ended up here while researching the same thing. ServiceNow has decided to introduce a new "Save" UI Action specifically for the sys_script_include table, and sadly it is read-only.

Currently this makes it impossible to add small modifications to it, such as marking it as 'Form button' to always display in the form without having to create a new one and copying over the same script, having to manually check on each upgrade if the script has been enhanced on their side.... 😅

[VerdaKosnett1]

It gets stuck here. No matter what role I enter it doesn't work.

[VerdaKosnett1]

To not get stuck when the script is new and client callable, don't select client callable when creating it. Once created, then change it to client callable. It takes it. Of course then you have to assign a role as to who can execute it if you want to be safe. This is a bug on the platform.

[Dan Covic2]

@VerdaKosnett1 this! In fact, you need to assign a role to the user if you want the user to be able to execute/call the script include. Otherwise, it doesn't work. I've tested this specifically for users who don't have a role assigned to them.

Basically, assign a role to a user without a role if you want to allow him/her to 'execute' a certain operation (i.e., getting his/her records by clicking on the Requests menu item in the Service Portal).

[Edgar10]

Hi @Martin Ivanov ,

Great Article very handful.I'm just curious how about i don't want to set the ACL for public but rather for  logged in Users  ? is this possible.

Regards,

Edgar