widget impersonation (impersonate in code)

nic_2017 · ‎10-04-2017

It's my understading that this used to work: gs.getSession().impersonate("usernameORsysid")

I have an error message in a widget, is not working anymore.

I googled it, I took a look at the documentation ... nothing.

How do I impersonate a user in script in Istambul?

Thank you,

Nick.

gyedwab · ‎10-05-2017

Hello Nicolae,

Actually, this is a use case where I wouldn't recommend the impersonate(), especially not to impersonate an admin, because that might be exploitable.

Instead, there's a read ACL on the 'incident' table you can use as a model, which uses this script:

current.opened_by == gs.getUserID() || current.caller_id == gs.getUserID() || current.watch_list.indexOf(gs.getUserID()) > -1;

This is what allows users to see their own incidents but not any other incidents (unless, of course, they have the 'itil' role, which is handled in a different ACL.

Just adjust it to whatever field you're using on this table to identify their own HR time off request.

View solution in original post

Dave Smith1 · ‎10-06-2017

But I don't want to do this ... one of the smart guys my go in the main SN interface and type "tablename.list" and have access to the entire table. Can I modify the ACLs and dynamically give to a user access JUST to his/her own rows?

Yes. Take a look at the ACLs that govern read access for the incident records. You'll see that there's two rules:

if itil role = view all records (support staff can see all incidents)
no role = restrict visibility down to those records where the user is the raiser, caller, or on behalf of (i.e.: view only YOUR incidents).

This is the kinda thing you want, right?

So ... I have a table with a role and no module (I don't want the users to see the application in CMS - that's the main SN interface

... one of the smart guys my go in the main SN interface and type "tablename.list" and have access to the entire table.

That's correct. Modules simply provide a navigation to a table, with a specific view (certain columns and presentations) plus specific rows (filter). Restricting access to the underlying data should be done at ACL or BR level:

ACLs implement security controls
BRs act as record interceptors and server-based filters that can't be circumvented at client level.

ACLs are preferable since they're closest to the data, but BRs remove that annoying "...rows restricted by security constraints" message (which I consider weak security due to information disclosure)