Get a first look at what's coming. The Developer Passport Australia Release Preview kicks off March 12. Dive in! 

Issue with Security Attribute 'UserIsAuthenticated'

d_ladou
Tera Expert

Hi,

Is anyone else having issues with ACLs using the 'UserIsAuthenticated' security attribute?
Both ACLs I have tested in our instances that use this ACL are evaluating false despite users being authenticated.

Ex: ACL sys_journal_field/read
Decision Type: Deny Unless
Security Attribute: UserIsAuthenticated
Condition: LoggedIn=true^ORAllowUnauthRolelessAcl=true

Despite a user being logged in and accessing this table's list, this specific ACL is returning false. If I disable it, they can see the records they have access to.


I have the same issue with an ACL on the sys_template table where the operation is write, but otherwise the decision type and conditions are the same:
Deny Unless; Security Attribute: UserIsAuthenticated.

The user cannot write to fields they used to be able to write to.

As far as I can tell, this issue started with one of the Yokohama upgrades.

System info:
Build name: Yokohama
Build date: 11-06-2025_2131
Build tag: glide-yokohama-12-18-2024__patch7-hotfix2b-10-21-2025

Has anyone else experienced something like this?

2 REPLIES 2

OleksiyK
Tera Expert

Hi, are you sure the problem is that security attribute? There are tons of OOTB ACLs with "Decision Type: Deny Unless" that work as expected.

 

I just noticed some pretty strange behavior, did some googling and came across this post. I hope my observations help you.

 

Are you familiar with "Debug all security" mode?

 

I used it, and then I noticed the ACL with "Decision Type: Deny Unless" is getting other green color ticks (olive) than ACLs that clearly evaluate to true. The overall decision was then "RC = false".

 

Furthermore, the same ACL with "Decision Type: Deny Unless" evaluated once to true and once to false, depending on the "CONTEXT = ...", although the ACL itself is not context dependent (no filter, no roles, no script)!

 

But in my case there was another sibling ACL which was context dependent.

 

So my observations are,

if there are multiple sibling ACLs and one of them is with "Decision Type: Deny Unless", and this specific ACL evaluates to true but none of others does, then this ACL gets these strange greenish color ticks but no other ACL gets any tick at all (blank circles), and overall decision is then "RC = false".

 

ACL+.png

 

ACL.png

 

It looks like the ACL with "Decision Type: Deny Unless" was only evaluated, and it alone caused "RC = false" , but in fact the other ACL(s) caused it!

Instead of using debug security it is better to use the new Access Analyzer. This better for the system as you can pinpoint what table, user, and even field if necessary instead of running for everything as you navigate to the record.