Get user properties outside of %SYS namespace
I have a CSP page that is supposed to show some user info (Full name and some other properties retrieved from AD)
I am unable to get them outside of %SYS namespace using Security.Users class. Is there another mechanism to do that, or I am using Security.Users class incorrectly?
Comments
Class Security.Users is available only from %SYS, you can map it to your namespace, but I would not recommend to do it. I think, you can just have a method just for this exact thing, where you can switch to %SYS namespace, gather what's you need, and that's it. In this method you will need to use New $namespace command, so, when it will return back to your original namespace when returns. As a ClassMethod it would look like this
ClassMethod GetUserInfo(username, ByRef props) As %Status
{
New $Namespace
Set $Namespace = "%SYS"
Return ##class(Security.Users).Get(username, .props)
}Does this method require some additional priviliges for the current user? I am getting a CSP error that does not get logged when I attempt to call a function like this with a test user with limited rights. When I call this function from my own account in terminal, it works.
Your user must have access privileges to the %SYS namespace: SET $NAMESPACE
How safe is it to give random users access to %SYS? At this point I am thinking about abandoning the whole idea and just use some crutch to get user properties.
You don't need to grant rights to the users whose properties you want to get.
Access rights (resource %DB_CACHESYS:R) you need to give the user from which your GetUserInfo method will run.
But the method will be called from a CSP page, and accessing that page will be the application user.
I don't see a way to decouple the logic.
Then add a role with the appropriate permissions to your web application: Editing an Application: The Application Roles Tab Don't forget to restart the web app after that for the changes to take effect
Afaik for Application Roles to take place, user should re-login -- Roles are assigned on login. So -- no need to restart the web application, but user should log out and login again.
And yes, Application Roles is a great tool to minimize privileges that are given to the user directly
If you want to minimize the roles given to a user, use Privileged Routine Applications.
With them, only specific lines of code would have additional privileges, such as %DB_CACHESYS:R.
Try the following:
SAMPLES><FONT COLOR="#0000ff">set </FONT><FONT COLOR="#800000">sc</FONT><FONT COLOR="#000000">=</FONT><FONT COLOR="#0000ff">$$</FONT><FONT COLOR="#ff0000">GetSecurityUserInfo</FONT><FONT COLOR="#000000">^%SYS.SECURITY(</FONT><FONT COLOR="#0000ff">$username</FONT><FONT COLOR="#000000">,.</FONT><FONT COLOR="#800000">p</FONT><FONT COLOR="#000000">)</FONT>SAMPLES><FONT COLOR="#0000ff">zwrite </FONT><FONT COLOR="#800000">p</FONT> p("AccountNeverExpires")=.. p("AutheEnabled")=.. p("ChangePassword")=.. p("Comment")=.. p("CreateDateTime")=.. .. p("FullName")=.. p("Roles")=.. p("PhoneProvider")=.. p("Routine")=.. p("SuperUser")=..
Don't use this it is not documented or supported and may change in the future. Use the GetUserInfo example above.
Indeed, I can't find much about this, yet it works. Why would such thing exist then?
Don't use this it is not documented or supported. It is internal use only.
Topicstarter indicated Caché 2018.1, which is no longer being developed so not may change in the future (not counting security patches)
Whether you think internal calls are likely/unlikely to change, using undocumented and unsupported code is an unnecessary risk and not a best practice. If InterSystems finds you using these commands, you would be urged to replace them.
The %SYS namespace sources are open to study and often (but not always) serve as a coding etalon reference for application developers. This is a whole storehouse of knowledge for those who want to better understand certain mechanisms work of system classes.
If some of the commands found there are not documented, but effectively do useful work, then why can't they be used by application developers?
In addition, I do not rule out the fact that some of them are simply forgot to document.
What really needs to be hidden or potentially dangerous is already hidden in the deployed classes.
If you look at a modern version of Caché or IRIS you'll find that ^%SYS.SECURITY is hidden. I would be curious how long ago you found out about the method you are suggesting, as it has been hidden since at least 2016.
Full disclosure, I work at InterSystems, but I try not to say anything on the community that goes beyond the bounds of what a non-InterSystems community member would be able to say. If you want the official InterSystems word, I would recommend you reach out to the WRC / your account rep, but I can almost guarantee they'll echo Steve's and my response.
If you look at a modern version of Caché or IRIS you'll find that ^%SYS.SECURITY is hidden.What does the source code of ^%SYS.SECURITY have to do with it? The fact that it is hidden does not play any role here.
Take a look at the code %CSP.Portal.Home:%OnPreHTTP()
@Vic.Sun. your reaction is - to formulate it politely - a disappointment.
But no surprise to me.
By the way, InterSystems employees have already given examples of undocumented code here, which can be found independently in %SYS:
- https://community.intersystems.com/post/there-way-get-internal-private-property
- https://community.intersystems.com/post/what-best-way-serialize-objectlistarrayetc-string#comment-84976
Just to give my 5 cents on this: it's not great to suggest unsupported approaches to solve problems.
But for us it is always great feedback what features we could include the support for in the product.
@Vitaliy Serdtsev , thank you for your continuous willingness to help developers to solve their issues.
@Vic Sun your point is very fair - it's almost impossible to support unsupported usage and it can cause unpredictable problems.
Thank you all!
When I was Software Support Manager @ Digital Equipment Corp. in a former life
in the previous millennium we had 2 basic rules graved in stone:
- The (contracted) customer is right.
- IF NOT, Rule #1 has to be applied.
I won with my team the annual European customer survey competition
over several years in sequence.