Bug with Dummy Installation

[SirLouen]

I think I've spotted the issue I've been having for several month and this is an issue I've been carrying for ages, but for some reason there have been periods of time where it worked and others (like the past 4 months), that it stopped working (and I have not had found the time to debug this adequately until now)

Context

I have 2 installations: One is my regular security installation, and the second is Dummy installation made by Securitas exclusively for invoicing purposes. I cannot get rid of the second one because it's an invoicing issue they cannot solve.

For the past 4 months, every time I set up the component it goes through the login step, then the 2FA step also works well, and it shows me the two installations correctly in the HA device page

But then it starts checking for capabilities of the Dummy Installation (which are none, because it's a dummy installation without anything but invoices) and after repeated failed checks, the Securitas Incapsula Firewall ends blocking my local IP with this:

This is the error log message

ERROR (MainThread)[
   "custom_components.securitas"
]"(""6: Unauthorized request for current capabilities.",
{
   "errors":[
      {
         "message":"6: Unauthorized request for current capabilities.",
         "name":"ApiError",
         "time_thrown":"2024-06-12T16:35:36.428Z",
         "data":{
            "res":"ERROR",
            "err":"6",
            "status":401
         },
         "path":[
            "xSCheckAlarm"
         ]
      }
   ],
   "data":{
      "xSCheckAlarm":"None"
   }
},
{
   "app":"{\"appVersion\": \"10.102.0\", \"origin\": \"native\"}",
   "User-Agent":"User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.124 Safari/537.36 Edg/102.0.1245.41",
   "X-APOLLO-OPERATION-ID":"APOLLY_LONG_HASH",
   "X-APOLLO-OPERATION-NAME":"CheckAlarm",
   "extension":"{\"mode\":\"full\"}",
   "numinst":"DUMMY_INSTALLATION_ID",
   "panel":"SDVECUW",
   "X-Capabilities":"VERY-LONG-CAPABILITIES-HASH",
   "auth":"{\"loginTimestamp\": 1718210131680, \"user\": \"11111111\", \"id\": \"OWA_______________11111111_______________11111111\", \"country\": \"ES\", \"lang\": \"es\", \"callby\": \"OWA_10\", \"hash\": \"LONG_HASH\"}"
},
{
   "operationName":"CheckAlarm",
   "variables":{
      "numinst":"DUMMY_INSTALLATION_ID",
      "panel":"SDVECUW"
   },
   "query":"query CheckAlarm($numinst: String!, $panel: String!) {\n  xSCheckAlarm(numinst: $numinst, panel: $panel) {\n    res\n    msg\n    referenceId\n  }\n}\n"
})

Workarounds

Maybe it's not worth patching this. I've found two workarounds:

1. (PREFERRED) Creating another user in the Securitas control panel, with just exclusive access to the non-dummy installation, and then using this user to login here. This way, it will work with just 1 installation as normal
2. The second option is disabling the installation within the HA device manager. The problem with this, is that you may end at least one time with the system blocked and you will have to wait like 15 or 30 minutes until it unlocks to use the component. I don't really recommend this option because you may end getting stuck even more than once.

Solutions

1. Patching this somehow, but I'm not sure that there is something specific with the Dummy Installation. I'm not 100% confident what makes so special this dummy installation, but I think it is the panel SDVECUW, maybe if this panel is present, ignoring requests from it, could be a solution. I've not even sure if this SDVECUW is a uniqueID for such panel
2. If patching is impossible, or an overkill, maybe documenting this scenario would be enough, I've read other issues in the tracker similar to this, maybe it's because of the same