You are viewing limited content. For full access, please sign in.

Question

Question

Status on fix for Access Denied known issue in Laserfiche 10.1

asked on July 26, 2016

Does anyone know the status of the following issue listed in Known Issues in the Laserfiche 10.1 Release notes?

  • In some cases, users viewing the records pane for a document will receive an "Access denied. [9013]" error if they have not been granted Browse rights for the document's parent folder or folders. (143201)

 

This is not just an issue in the Laserfiche client, the same error is returned from the SDK. We have about 50 customers that use our product to connect to Laserfiche through the SDK, and right now our only option seems to be to tell them not to upgrade to 10.1 until this is resolved.

Limiting access to folders is not some obscure piece of functionality that very few people use. It is a very common practice. If this was known before 10.1 was released, it should have been a show stopper that held up the release until it was fixed.

I realize that there is a workaround by granting browse rights on parent folders, then explicitly denying rights on all child folders other than the one where access is desired. This is not something that I am prepared to ask our mutual customers to do. It also violates a directive that I have heard many times from Laserfiche employees: Keep security simple, because complex security rules can have a negative impact on performance.

Can someone from Laserfiche please respond and tell me when we can expect a service pack to fix this problem?

0 0

Replies

replied on July 27, 2016

Just to clarify, the known issue you mention is regarding records management series and records folders, and comes up in a transparent records scenario. Are you seeing it on a more widespread basis? Or are your 50 customers set up using TRM and the SDK? 

0 0
replied on July 27, 2016

After further investigation, it turns out that this wasn't a problem that was introduced in 10.1. It was apparently a previous security problem that was fixed.

We were testing for correct restrictions on folders through the SDK, but the way that we were configuring access rights actually didn't make any sense. We were completely removing all access rights for a security group at a first-level folder in the repository, then granting access rights to one of the child folders. 

Prior to 10.1, we could call GetFolderInfo on the parent folder (where the user had no access rights) and get the FolderInfo class for the parent, then use the folder name from the FolderInfo to construct a query using LF:LOOKIN=<parent folder name>. Because the user had no access rights to the parent, we should not have been able to use GetFolderInfo, but it worked.

We were doing things wrong in our test environment, and after correcting our mistake everything works as expected. My only concern now is how many of our customers have made the same mistake and leveraged the same previous security bug.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.