Select Page

Remember you can use XPage ACL Entries to control page access

by | Aug 6, 2012 | Uncategorized | 9 comments

I’ve been pretty busy lately trying to meet deadlines but while I am creating a local replica I wanted to remind folks that, just like other applications, XPage applications have certain “screens” that should be restricted only to certain users.  Typically these pages are used for system configuration or administration functions.

One way to prevent unauthorized access to the XYZ Administrators-Only XPage is simply not to show links to that page to the “wrong” users.  Simple enough to do using database ACL Roles but in the end it is not really very secure since someone can simply type in the XPage URL and open that “double-secret probation” XPage.

A better way is to remember that XPages have their own ACL settings that refine the database ACL.

Just go to the properties, add an acl entry, enter a fullname for the entry, enter the name of the Role, Group or individual, select whether they can edit or just read the XPage and finally indicate the type of entry it is.

The example below only allows users in the Administrator ( roles are indicated using [] )  role to access the page.

When an unauthorized someone attempts to access the restricted XPage, they get this kind of login page message:
If you really want to get into it you can even add ACL entries to individual panel controls so you can section off portions within the same XPage.
Of course these are not the only ways to effect this kind of “security” but just wanted to remind folks that XPage ACLs are easy to use and effective.
Did I mention these entries can also be dynamically loaded when the XPage loads?  Could be cool for testing your apps. <wink> <wink>

9 Comments

  1. Tim Tripcony
    Tim Tripcony on August 6, 2012 at 12:36 pm

    Do you know if they've fixed the Directory Assistance bug yet? I haven't had a chance to test it yet.

  2. Russell Maher
    Russell Maher on August 6, 2012 at 12:48 pm

    What bug? I've been using it fine with DA for years.

  3. Russell Maher
    Russell Maher on August 6, 2012 at 12:55 pm

    Found your post on the bug. I have never experienced any issues and every single one of my 6000+ monthly users is and always have been authenticated via DA.

    Apparently I was just lucky but I have found I am often lucky that way in that I don't seem to run into most of the bugs that crop up. Don't know why though.

  4. Abby Butts
    Abby Butts on August 6, 2012 at 2:25 pm

    Thanks for the tip! I do have panels that need to be restricted based on role and this looks like an easier way to manage it.

  6. John Munro
    John Munro on September 21, 2012 at 10:18 am

    Thanks Russell – really good, practical tip.

  7. Russell Maher
    Russell Maher on September 21, 2012 at 1:15 pm

    Thanks and you're welcome!

  8. Stephen Skurka
    Stephen Skurka on December 27, 2012 at 5:19 pm

    I'm glad I'm not the only one – had to hack around DA and ACL issues by using the beforePageLoad event. It's sorta funny that the hack was for an internal IBM system. If the DA bug gets fixed and Xpages allows dojo to be put in it's own namespace (another massive hack required for Xpages inside IBM), maybe developing Xpages for big corporate environments might become more of a winner.

  9. Anonymous
    Anonymous on December 31, 2012 at 6:55 am

    Hi, it all sounds very easy but I've been trying to do this for one of my apps but it doesn't quite work. For browser accessed pages, this has worked. But when I try to open the XPage in the client the results are different. I get a:

    Error 401
    You do not have sufficient authorization to perform this operation

    For the browser, I have assigned a role so that when an anonymous user hits the page, a formula checks if the anonymous user is in the role and assigns EDITOR or NOACCESS accordingly. Here it is:

    @If(
    @Contains( session.evaluate( '@UserRoles' ), "[AdminAccess]" ),
    "EDITOR",
    "NOACCESS"
    );

    In the client, I have a new role because I think the system knows who I am as I've obviously logged in. No matter, I set this new role to be EDITOR for my ID but the error described above appears.

    I'm doing this on a local database and so have made sure that "Enforce a consistent access control…" has been ticked.

    Any ideas?