Use Script Debugger while impersonating another user with certain privileges

[Bernhard Saile]

Hello.

I am using Script Debugger to step through some server side scripts in our instance.

As a developer (a user with "script_debugger" role and other privileges allowing navigation to source code like Script Includes), I am able to:

• Navigate to the code I want to check and set breakpoints.
• Open Script Debugger tool and stop execution at my defined breakpoints.

Now I want to impersonate several users with specific (sometimes complex) role constellation. I have several problems:

• My Script Debugger session from before the impersonation is still open, but does not stop at the breakpoints (I think because it is associated to my developer user).
• Adding the "script_debugger" role to the impersonated user temporarily allows me to open a new Script Debugger, but no breakpoints I set as developer user are available. It is a completely new debugger session.
• Also, the impersonated user does not have access to the actual source code (e.g. Script Includes) and so is not able to set new breakpoints for the new session.

Of course I could manipulate my developer user by assigning roles and adding him to certain groups that match the situation of the impersonated users, but this not really feasible.

In a nutshell, what I would like to do is this:

• As developer, define breakpoints in a certain server side script.
• Impersonate a user with a specific role / group setup.
• Debug the code that executes differently based on the roles / group setup the impersonated user has.

How do you approach such a scenario? Thanks in advance!

[Bert_c1 · Accepted solution]

Hi Bernhard,

In your first bullet, you indicate a specific server side script. given the limitations of using the Debugger while impersonating a user, I would add 'gs.info();' lines to the script to show interesting variable values at points in the script. Then impersonate the user and test. After the test, view the 'Script Log Statements' and see the results of the debug.

[Bert_c1 · Accepted solution]

Hi Bernhard,

In your first bullet, you indicate a specific server side script. given the limitations of using the Debugger while impersonating a user, I would add 'gs.info();' lines to the script to show interesting variable values at points in the script. Then impersonate the user and test. After the test, view the 'Script Log Statements' and see the results of the debug.

[Bernhard Saile · Accepted solution]

Hi Bert.

You wrote "given the limitations of using the Debugger while impersonating a user, I would add 'gs.info();' lines".

That confirms to me that in my scenario the only thing I can do is "poor man's debugging": fill the code with gs.info statements. I don't like it, since it means actively changing the code and adding records to the current update set.

But anyway, if that's the way it is, I have to live with it.

[Chris D]

This is a huge bummer. How has ServiceNow still not come up with a way to debug while impersonating? I thought this was the case from past attempts but I decided to look it up and am once again disappointed. Apparently there is (or at least used to be) for Security/ACL debugging (not even noted in documentation anymore) but it doesn't extend beyond that I guess...

It should be pretty obvious that some things simply cannot be reproduced as admins - and like you said, it's infeasible to have add script_debugger AND other roles to other users simply to debug.

[Tauqueer]

Please Try giving the impersonated user role as "script_debugger" and follow the steps provided in the doc 

https://docs.servicenow.com/bundle/washingtondc-api-reference/page/script/debugging/concept/imperson...