ACL: Commentaries on the script code breaks ACLs

[felipe_barbosa]

Recently I got involved on rebuilding the ACLs of our current SNOW instances, and I came across several small issues with the ACLs, for example, I created a new one to test a possibility, then, when debuging the security I noticed that my new ACL wasn ´t being considered in the debug results, it only displayed the old set of ACL rules:

PATH = record/sc_task/read RULE = ((((hasRole() AND script=getScTaskReadAnswer(); function getScTaskReadAnswer() { ...) { return true; } else {...; //comments... } ...) AND script=var ra = false; if (root_rule.substring(0,7)=='var__m_') { var wa = gs.getUser().hasRole('workflow_admin'); var wc = gs.getUser().hasRole('workflow_creator'); var fn = gs.getUser().hasRole('normalizer'); if (wa || wc || fn) ra = true; } ra; ) OR (hasRole() AND script=...;)))) RC = false

I didn ´t understand why my new rule was not there, I tried to do a cache.do, tried to wait a bit and see if it got included, and nothing. Then I copied the PATH string and pasted it in my javascript editor to check what was the issue, and I realized that the reminder of the string was as a commentary because, well, I had a commentary in the script.

I took the comment out and boom! It started to work as expected, and I had the new ACL rule listed on the security debug results. I am not sure if this is a bug, a know issue, but anyway, if you're having issues with ACLs consider looking into the script code and check if there is code comments, if so, remove it and you should be fine.

Cheers!

Felipe

[alan_lowrance]

I found something peculiar as well... in my instance the ACL scripts aren't running at all except for myself when I'm logged in as admin.   Both when I impersonate a non-roled user or directly log in as a non-roled user, the gs.log on Line 1 of the ACL script never displays in the log and when debugging Security it evaluates the script as true even though it shouldn't.

[mike_donathan]

I don't know if this is still an on-going issue, but if what I'm seeing above is one line of code, you're going to have issues with the double-slash comment format. Everything after the "//" is going to be interpreted as comments. If you want to, you can try using /*Comments...*/ in-line. That should allow the rest of the conditions to evaluate normally.

[alan_lowrance]

Great solution Mike, but what I was noting happens even when no comments are in the box.   I just submitted it to HI.   More info about the bug I think I found:

To test this I just put false; or answer = false; as the first and only line in the script.

Debugging Security Rules Result: ACL Script returned true.

So I put a gs.log at the top to prove that script runs when myself or another roled user views the form bound by the ACL.   The gs.log was written to the log so the script did run, but debugger says ACL script true.

If a non-roled user views the form, gs.log doesn't write to the log so the script doesn't even run, but the debugger says ACL script true.

Please note that putting false; or answer = false; as the ACL Script on any other non-journal field or table seems to work fine and the script gets evaluated correctly.   There is an open Problem ticket (fix slated for Geneva) regarding the journal calculation so that might also fix this problem as well.

[mike_donathan]

Alan, since I'm not seeing the ACL(s) in question right in front of me, I'm going to make an assumption or three. You might be seeing a case of where the ACL script section just isn't being hit. The script section of ACLs is executed last (from what I understand). There's a graphic in section 3.2 on the ServiceNow wiki about the order of operations for ACLs that I've always interpreted that the script box only evaluates if the role check and the condition check BOTH evaluate to TRUE, then the script runs. In your case, where you have a non-roled user, the ACL may be running, failing the role check, and that's why the gs.log in the script section isn't dropping into the log.

Another thing you can try is turning on the debugging. I've not used it a ton, to be honest, but it might be worth a shot. There's a good amount of how-to's on the wiki concerning debugging ACLs.

Debugging ACLs

If you feel comfortable, you can always post a screencap of your ACL, or re-create one in a demo instance, and we can take a look at it together.