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



Feature Request: Connector Profile Access Control

posted on August 11, 2022 Show version history


As time goes on we've found ourselves using more Connector profiles, but one area where it seems to fall short is controlling who can see what profiles in an easily-maintained way.

Currently, we have a network folder where the main profiles are stored, and we use a login script to add any additional profiles to the local path for members of specific AD groups.

However, what I'd much prefer is a way to control who can access specific profiles without having to rely on device-specific changes (i.e., mapping users to different folders or adding profiles to a specific machine).

The biggest complication is that we have a lot of overlap with some profiles common to most/all users and others specific to certain tasks.

Two possible solutions may be:

1. Add a configuration option for "include subfolders"

This isn't necessarily the "best" solution, but it seems like a smaller ask that could be accomplished sooner than the more in-depth solutions.

If we could set "load profiles from" path to also include subfolders, that would allow us to create access controlled subfolders so we could in theory map everyone to the same network folder, but still organize the files and use AD groups to control which profiles are loaded for each user without having to manage files individually.


2. Allow profiles to be hosted on a server, like QF

This seems like a more robust solution, and it has been requested before, but I know it would have a lot more development overhead (i.e., time).

Create a "Connector Profile" server that can be mapped to the application instead of just a network path. I would imagine this including some kind of access controls so we could decide which users/groups have access to each profile published to the server.

Feature Request - Connector Server - Laserfiche Answers


There may be something else I haven't considered yet, but the general idea is to allow one-time configuration on the PC and remove the need to manage any local profiles or special settings for individual files.



Another option might be to introduce a customizable config file we could use to list off the folder(s) from which Connector will retrieve profiles.

For example, instead of mapping to a folder on a network drive, we map to a config file stored in a network location (or even locally), and that file (XML or something) contains a list of the folders Connector will check for profiles.

I imagine this being something like the IE Mode site list we use for Edge, where we can maintain lists in a single location to manage all users' settings.

One potential advantage to this is that it wouldn't require monitoring of subfolders because we could explicitly list all the folders we want to be checked.

Another advantage is that it is a little more flexible. For example, we could set access controls so users only see profiles from folders they can access, but we could also map different users to different config files if we really wanted to, and the config files could all be managed from one place if desired.

3 0
replied on August 15, 2022

Hi Jason,


Is it an option to configure permission on the folder or profiles in the network drive? I think Laserfiche Connector is a client application, so if the user running Laserfiche Connector doesn't have access to the profiles in the network drive, the profile will not be loaded.



0 0
replied on August 16, 2022

Hi Huazhen,

Yes, Connector does run with the user's permissions, so I believe it is possible to limit profiles by limiting the user's access.

However, because Connector doesn't check subfolders, folder security is effectively the same as just not mapping to the folder.

Setting security on the individual files should work, however, it is not very manageable since all the files would still have to be in a single folder and it would require setting/maintaining permissions on the individual files.

There's just a lot more that can be missed/overlooked when using file-specific security as opposed to named subfolders, so we went a different way.

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

Sign in to reply to this post.