Posts Tagged With: ACL

Finding user roles in #XPages

I’ve written a piece before on roles in XPages, but since that dealt with using the ACL to limit access to a page and not about the programmatic use of roles, I wanted to return to the issue.

Back in old Notes, if we wanted to hide something based if the user did not have a certain role in the ACL, we could use a pretty simple formula:

!@IsMember(“[roleNameHere]”; @UserRoles)

Remarkably, it’s not that much harder in XPages, but there are some important wrinkles to be concerned about. As noted previously and by Russ Maher on his blog, you must remember to use your brackets [] and also keep in mind the result you want (true or false). Remember that the XPages formulas are ‘rendered’ formulas, meaning you want to ‘true’ to display the result and ‘false’ to hide it, so you’d use:

@IsMember(“[roleNameHere]”, context.getUser().getRoles());

Here’s the more complete source code for the rendered formula:

<xp:this.rendered><![CDATA[${javascript:@IsMember("[Testing]", context.getUser().getRoles());}]]></xp:this.rendered>

Now, I’m not sure what impact of referencing the user roles that way has on performance, but since I now I’m using them in many rendered formulas all over my application, I decided to compute it once and then reuse it many times. I put a few extra lines into a control that’s on my main application layout control to drop it into a sessionscope variable. I suppose I might shave a millisecond off if I only computed that once per session, but I didn’t go that far.

<![CDATA[${javascript:var roles = context.getUser().getRoles();
sessionScope.userRoles = roles;}]]>

Then, in order to check to see if my user has one of three roles when rendering an item, I could use this code:

<xp:this.rendered><![CDATA[${javascript:var manager = @IsMember("[InventoryMgr]", sessionScope.userRoles);
var viewer = @IsMember("[InventoryViewer]", sessionScope.userRoles);
var grantsManager = @IsMember("[InvMgrGrants]", sessionScope.userRoles);
if ( manager || viewer || grantsManager ) { return true };
return false; }]]>

Now, I also found that sometimes I need to determine the user’s role in my Java code. That’s also not that hard, except that vectors are not quite arrays. If there is a single value, it’s not the same as a multiple value vector. I’m not sure if this is a Notes implementation issue or if it’s the way Java always handles vectors. That is, if it’s a single value, it puts our brackets [] around the value, but it does NOT for multiple values. So, when I was using the code written for us, it wasn’t always picking up the roles correctly. Once I simply told it to check both ways, our code worked more cleanly. (The reference to ExtLibUtil comes from the original code, so I didn’t modify it.)

public Vector getCurUserRoles() {
	try {
		curUserRoles = ExtLibUtil.getCurrentDatabase().queryAccessRoles(ExtLibUtil.getCurrentSession().getEffectiveUserName());
	} catch (NotesException e) {
		this.debug("getCurUserRoles ERROR: " + e.getMessage(), "error");
		curUserRoles = new Vector();
	return curUserRoles;

public boolean hasRole(String role, String uname) {
	try {
		Vector roles = this.getCurUserRoles();
		if (roles.contains(role))
			return true;
		if (roles.contains("["+role+"]"))
			return true;
		return false;
	} catch (Exception e) {
		this.debug("hasRole ERROR: " + e.getMessage(), "error");
		return false;

Note that the debugging uses Mark Leusink‘s DebugToolbar, which I highly recommend to everyone.

Categories: Java, Old Notes, Security, Xpages | Tags: , , , , , , | 2 Comments

Using XPage ACLs to limit access

Among the items I’d been working on for the presentation at the DCLUG earlier this month was an evaluator’s page.

Now before I get into the code snippet, let me lay out a bit more of the design concept to put this in context. Users would anonymously create grant requests via browser, then internal users would assign evaluators with their Notes clients, and those evaluators would login via browser to fill out their assessments of the requests. So, I needed to come up with a way to force the logins and inhibit anyone who wasn’t authorized from seeing the evaluators work lists or assessments.

Notes does this wonderfully well, but as I’m breaking new ground with XPages, I had to search around for clues on how to do it. After a while, I did finally find something on my go-to source, Stack Overflow. (Thanks to Matt White and AndrewGra!)

          <xp:aclEntry type="ANONYMOUS" right="READER"></xp:aclEntry>
          <xp:aclEntry type="DEFAULT" right="EDITOR"></xp:aclEntry>

While this is nice, it also opened me to wondering about all the other options of the aclEntry control. There are 5 parameters to be considered. The two required parameters are intriguing.

type – string – Defines type of entry, valid values are USER, GROUP, ROLE, ORGUNIT, ORGROLE, DEFAULT, ANONYMOUS

While both ORGUNIT and ORGROLE are deprecated, the other 5 are quite familiar. If you set type to either DEFAULT or ANONYMOUS, you don’t supply any of the name values, since these are effectively “unnamed” access types. For USER, GROUP and ROLE, you must supply name values.

right – string – Defines rights for this entry, valid values are NOACCESS, READER, EDITOR

On an XPage, you really are only concerned about end-user access, so it’s either none, reading or editing. Distinguishing between Author and Editor depends on the ACL and whether their are Author names fields on the source documents, so not something one wants the XPage monkeying around in anyway.

Since neither DEFAULT nor ANONYMOUS requires any name information, the next two parameters are optional.

fullName – string – Defines users full name e.g. John Smith

name – string – Defines entry name

There’s a real lack of clarity here as to what goes where, in particular, what to do about ROLES. Is it a name or a fullName. Do you use brackets [ ] or just the text? So, I fiddled around. I’d almost figured out how to implement ROLES myself when I searched just a bit more and found Russ Maher’s guidance. Basically, put brackets around the name value and straight text for the fullName. Here’s my ACL to limit the XPage to only those users with the Evaluator role.

			<xp:aclEntry type="ANONYMOUS" right="NOACCESS"></xp:aclEntry>
			<xp:aclEntry type="DEFAULT" right="NOACCESS"></xp:aclEntry>
			<xp:aclEntry fullName="Evaluator" right="EDITOR" type="ROLE" name="[Evaluator]">

The final parameter is also optional.

loaded – boolean – Specifies whether or not the tag instance should be created when the page is loading. Value defaults to ‘true’.

This one is obviously for people far more clever than I. I suppose that if you want the ACL to only take effect after some other event that trips the loaded flag to true or something. I’m not real sure. It is inherited from if that helps you figure it out.

Just as form access and creation controls are very sneaky, these are as well. Since the properties don’t show up in the nice little properties box for the XPage and you have to hunt into either the source or the All Properties tab (under data), they are sure to create some trouble-shooting issues, especially when you’re new to XPages. So, I’d recommend you make sure to put these at the top of your XPages and I would be careful about using them on custom controls, unless you do everything in your custom controls, simply because of the lack of visibility.

Hope that helps someone looking for help with security in their XPages. I’m pretty happy with how easy it turned out to be to code it.

Categories: Security, Xpages | Tags: , , , , , , , , , | 4 Comments

Blog at

%d bloggers like this: