How to ACL to block URL access?

ericgilmore
Tera Guru

So there is a custom app with a custom app table. ACL's are setup to allow access to modules, list, form. But if someone gets the URL to a record on this table, they can go to the record (form) and it loads an empty page with empty section tabs.

Why won't this just do what the list does and display the usual "Security constraints prevent access to requested page" and not an empty page with empty sections on the page?

I've been testing this with users that don't have the admin or the (custom table) roles.

There exist already acl's for;

(1)

Type: [record]

Operation: [read]

Name: [x_custom_table][ --none-- ]

Requires role: [x_custom_table.role]

(2)

Type: [record]

Operation: [read]

Name: [x_custom_table][ * ]

Requires role: [x_custom_table.role]

How can this non-roled user even get to the, albeit blank, form without the required role, using a direct URL to the record?

 

1 ACCEPTED SOLUTION

ericgilmore
Tera Guru

After testing various ACL configurations to attempt to curb this, I was never able to block a user's access to a page if they were given the direct URL. Yes, the ACL's did blank out the page leaving only section tabs, which were also blank, but I could see the corn-fusion this might cause.

I ended up just using a client script (onLoad) that hides the sections if the user does not have the needed "x_custom_table.role", and displays the standard "Security constraints prevent access to requested page" to give users a tiny bit of info about what's going on.

 

-cheers

View solution in original post

2 REPLIES 2

Allen Andreas
Administrator
Administrator

Hi,

I can understand your position on this.

The URL though contains the params to the data, not the data itself (obviously). So the fact that they have the URL with the params is what gets them to the page for the ACLs to then be evaluated.

I believe because you're also using an table.* "read" ACL, that prevents the columns and such to load (there's a debate amongst everyone if the ACLs are evaluated as fields/columns first, then table...or table first, then fields/column).

However, you may have just stumbled upon a good way to test that by this situation.

If you remove the table.* "read" ACL, so not stating anything permission wise as to the fields/columns, even though they can't "read" the records from the table perspective, does the "security prevents rows" or whatever notice you expect...now show?

Yes, it's default deny...but I think because you may have explicitly used a table.* ACL, it enforces at that level, which if there's no columns, etc. to show, then no permission error shows, etc. That's my theory anyway.

If so, then that may be why nothing shows at all because you've removed access at both levels (fields/columns AND table).

Please mark reply as Helpful/Correct, if applicable. Thanks!

 


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

ericgilmore
Tera Guru

After testing various ACL configurations to attempt to curb this, I was never able to block a user's access to a page if they were given the direct URL. Yes, the ACL's did blank out the page leaving only section tabs, which were also blank, but I could see the corn-fusion this might cause.

I ended up just using a client script (onLoad) that hides the sections if the user does not have the needed "x_custom_table.role", and displays the standard "Security constraints prevent access to requested page" to give users a tiny bit of info about what's going on.

 

-cheers