FORUM PLAN UPDATE
Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.



Dec 12, 2011, 5:48 AM
261 Posts

How to check if a user has access to a document containing a readers field

  • Category: Server Side JavaScript
  • Platform: Linux
  • Release: 8.5.3
  • Role: Developer
  • Tags: security
  • Replies: 3
Suppose I have a document with a readers field on it allowing access only for userA:
  • If I open an XPage with a view control on it bound to a view that contains that document I get the expected behavior: userA does see an entry for that document in the view and userB (who doesn't have access to the document) doesn't.
  • If I use an XPage containing a document datasource to open that document (using the documentId parameter in the URL) userA can view the information from that document. If userB opens the same URL he doesn't have access to the information on the document.
The problem I'm having is that I don't know how to check if the user has access to the document or not: the document object from the data source is always available and the isValid() method returns true for both users. The same goes if a make a database.getDocumentByUNID() call in SSJS: if the UNID exists in the database it always returns a document object, even if the user making the call doesn't have access to the document.

This behavior is different to that in LotusScript: a getDocumentByUNID() call throws an error (or returns nothing, I'm not sure...) if the user doesn't have access.
 
What I did found out is that if a user doesn't have access to a document getUniversalID() returns a blank string and getSize() returns 0.
 
Two questions: why does it work this way and what is the proper way to check if a user has access to a document (so I can handle it and show an error message)?
 
Thanks,
Mark

Dec 12, 2011, 2:40 PM
129 Posts
Re: How to check if a user has access to a document containing a readers field
I can't say that I have experienced this. You're not opening the database object with sessionAsSigner?
 
getSize is a good way to check if the user has access to the document btw. I used this for FTSearch, as it returned documents that users didn't have access to.
Dec 13, 2011, 2:58 AM
272 Posts
Re: How to check if a user has access to a document containing a readers field
In my opinion the "empty" document object is a workaround not to crash the XPages application. If you add a computeWithForm to your datasource, you will see what I mean: This will crash the whole app, and it is a little bit tricky to prevent this behaviour (and I have had a lot of fun to get this working)
 
To test if the document has a docUNID or using the size are good indicators if a document is readable or not. The noteID is empty also. If you check if it is a new note, it will return false. And if you try to use the getURL() from the NotesDocument, it will fail.
 
Just my 2 cents
Sven
 
Dec 13, 2011, 7:06 AM
261 Posts
Re: How to check if a user has access to a document containing a readers field
Thanks both for the reaction.
 
@Tommy: no I'm not using sessionAsSigner calls. If I did I would have normal access to the document and wouldn't have a problem. But I don't want to use a sessionAsSigner call. 
 
I noticed you're using isValid and isSize checks in your search demo (which I like a lot): I've implemented the method you described and try to keep the use of views to a minimum)
 
@Sven: that makes sense in a way, but I still find it not logical that the functions return a valid document and I have to check it size (or unid/ noteId) to figure out if the user has access.
 
Mark

FORUM PLAN UPDATE
Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.