Personalized login to access control plugin gives access to all doors

MIP
, ,
1

Hi, I am checking into an issue with an Access Control plugin integration. The problem is that people are logging into the access control system via the plugin using their access control system credentials (using the secondary login feature) but they are able to see all doors. They should only see the doors that they have permissions to see. This used to work correctly on older versions of MIP such as 2020 R1. We are seeing the problem on newer MIP versions such as 2024 R1. Can you identify any changes that happened with newer releases of MIP that could have caused this issue? Is this problem more widespread and if so what is the fix?

Thanks,

-Lou Keeble

2

Hello Lou,

We haven’t done changes to that part of the AC framework in recent times, so I am surprised it has stopped working for you.

I tested the personalized login with 24 R1 and our Demo system plugin, and it showed only the doors that the AC System user had permission to see. It seems to me that there is an issue with the specific integration that you are using.

How did you encounter this problem? Did you upgrade an already existing setup, or did you install a new version of XProtect to test the Access Control integration?

3

Thanks for the reply Georgi. The issue is happening with an existing customer installation. I think they upgraded MIP to 24 R1 but kept the existing plugin. I’ve also done some checking myself using a test system and can report some additional information:

  1. I tried to get the existing access control plugin working using a fresh installation of MIP 24 R1. I found that the plugin got stuck while it was being added/configured in the Management Console. I saw in the MIP logs it loads ACCommandType, ACServer, ACUnit and then just stops. The existing plugin was built a long time ago and it uses .NET framework 4.6. The plugin was able to connect to the access control system successfully based on the log files. The problem with hanging during plugin addition/registration is a different issue than what was seen by the customer. However in the customer’s case I think the plugin was already installed and MIP was upgraded. So it’s not exactly the same test.

  2. I decided to rebuild the plugin. I fetched the 24 R1 versions of VideoOS.Platform.dll and VideoOS.Platform.AccessControl.dll from the nuget website and tried to build the plugin against those. I ran into a build error because the plugin was building against .NET framework 4.6 but the newer VideoOS dll’s use .NET framework 4.7. To get around this I upgraded the plugin to use .NET framework 4.7 and then it built successfully. I was able to install and test the plugin using MIP 24 R1 and it worked correctly.

Is it to be expected that a plugin built using .NET 4.6 will not work correctly with later versions of MIP such as 24 R1?

I guess the next step will be to provide the rebuilt plugin to the customer to see if it fixes their problem. Does this make sense from your perspective or am I missing something?

Thanks for your help,

-Lou

4

Update:

I have been able to successfully install and configure the original plugin built with .NET framework 4.6 using the Management Console. The plugin is now working correctly with no permission errors using MIP 24 R1. I am not sure why previously there was a hang while the plugin was being added/configured (see item 1 in my message above). This time I restarted the event server, maybe that helped.

So at this point I am not able to reproduce the customer’s problem. I will need to investigate further what is going on with their system. I’ll post more if/when I get more information and if I need further help.

Thanks for your help so far,

-Lou