Integration broken. Login API was changed.

[guerrerotook]

Securitas Direct changed the login API in the web application and now the integration is broken.

Working on this.

[Javvaz]

Thanks for the information. I can confim it. I appreciate your work and look forward to hearing from you soon.

[albertruizalonso]

I was going crazy! Mistakes with the integration of "Securitas" It doesn't work right now. When I enter the "Securitas" website, I also had a password error, forcing me to change it. I guess that must be the same problem¿?😫😫

[alnavasa]

+1

[guerrerotook]

Solved on latest release. https://github.com/guerrerotook/securitas-direct-new-api/releases/tag/V1.3.0.0

[Javvaz]

Thanks for the new version.

I am checking and it seems it has still some issue in order to operarte with Securitas Web API. Even though it is able to loggin, it seems it has some issue when you try to operate with: disarm, armed total, ... I got always the same warning messages when I try to execute any operation: 2022-06-17 09:04:54 ERROR (MainThread) [custom_components.securitas.securitas_direct_new_api.apimanager] Tu Alarma está gestionando una solicitud anterior. Por favor, espera 90 segundos antes de realizar otra petición (5 min si es una petición de imagen). However if I try to operate from Website they work. Let me know how I can help you if you need further information.

Thanks in advance and regards. Javier

[Javvaz]

I am doing another test with check_alarm_panel paramenter false. I will let you know the result.

Regards Javier.

[albertruizalonso]

You're right, This night, I tried it and it apparently disconnected properly in the home assistant panel, but really, it was connected. Imagine the fright when it started ring at 2 am...🤣🤣🤣🤣 Still, thank you very much. Really, you're a crack! @guerrerotook

[Javvaz]

First, thanks again for your altruist work.

I just finished my test with check_alarm_panel false. Now the issue is each time alarm operation execution is lanched, home assitant alarm status doesn't change. So I have added a script in order to check the alarm status afterward any alamar operation waiting 5 seconds before checking (to avoid a possible saturation). On that way it seems working, however it is very unstable and takes much time each execution.

I guess there will be another way to solve this in the code.

Let me know if you need further information or if you want me to do another test.

Regards Javier.

[Javvaz]

Deeping more in my reshearch.

After doing several tests with the paramenter check_alarm_panel with value false, I reached a conclusion.

The issue is that each time an alarm operation is executed from Home Assistant, it doesn't updatethe status alarm afterward execution.

I had understood that paramenter check_alarm_panel was only involved when you carried out directly some operation from the Securitas alarm panel (key, remote control, and so on), but doesn't when the operation was direclty lanched from Home Assistant. Please, let me know if I am wrong.

From the other hand, in order to solve the issue when you operate directly on the Securitas panel, I have added a script that check in Securitas side and update side the actully alarm status in Home Assistant each 5 minutes.

I hope having been usefull.

Regards. Javier.

[guerrerotook]

Let me take a look at this today. Thanks everyone for the comments and feedback.

[guerrerotook]

Let me take a look at this today. Thanks everyone for the comments and feedback.

[javiermartingonzalez]

Same here than Javier. Sometimes, HA not updating status after alarm change.

Checking Verisure app, 95% of times it's updated there so it automatically updates in HA in about 10 minutes. The other 5%, Verisure is not getting last status (showing disconnected when is recently connected), so I need to press Check status on Verisure app and then 10 minutes later, HA is updated.

@Javvaz Can you share the script with us to trigger that forcing get status without accessing Verisure app?

[s3v]

I had no success in using release V1.3.0.0 for logging in to the french graphql endpoint https://customers.securitasdirect.fr/owa-api/graphql. Maybe not all countries are using the same version on the graphql end.

I noticed that the ApiManager._generate_id() is returning timestamps that are too long versus those that they use on the FR endpoint. But even after modifying those to a maximum of 14 characters (eg id ending on _______20226172028859), i keep getting a commanderror as below:

CommandError: 400, message='Invalid header value char', url=URL('https://customers.securitasdirect.fr/owa-api/graphql')

After adding an "auth" and an "installation" header value of {} in the login request, the request passes successfully again. I'm not sure if you are seeing the same behavior on your graphql endpoint?

Edit: it seems that they are also expecting those on the ApiManager.check_general_status() request.

[Javvaz]

Dear @javiermartingonzalez

It is very simple. You only need to create an automation like below (please, remember to update "<Securitas alarm entity name>" by your Security alarm entity name):

That automation will be execute each 5 minutes and the home assitant alarm status will be update from the Securitas status value.

On the other hand, for sure if you would like to execute that action in other automations or scripts, you could create a script with the automation action and call it from wherever you want.

Regards Javier.

[guerrerotook]

Thanks for the new version.

I am checking and it seems it has still some issue in order to operarte with Securitas Web API. Even though it is able to loggin, it seems it has some issue when you try to operate with: disarm, armed total, ... I got always the same warning messages when I try to execute any operation: 2022-06-17 09:04:54 ERROR (MainThread) [custom_components.securitas.securitas_direct_new_api.apimanager] Tu Alarma está gestionando una solicitud anterior. Por favor, espera 90 segundos antes de realizar otra petición (5 min si es una petición de imagen). However if I try to operate from Website they work. Let me know how I can help you if you need further information.

Thanks in advance and regards. Javier

About this issue, regarless if you do that on the web app, mobile app or throught the API the result is the same. When the error is in Spanish (Tu Alarma está gestionando una solicitud anterior. Por favor, espera 90 segundos antes de realizar otra petición (5 min si es una petición de imagen), that means that your alarm still processing a previous request and it can't make any new requests. That is something that something it happens depending on the network coverage of the central panel of your alarm. the only thing that we can do is wait.

[guerrerotook]

About this topic, there are two separate ways of checking the status of the alarm in the code.

• Check Genral Status, goes to the server and ask securitas direct was is the last server alarm status that they have on record. That is a quick, fast and non invasive request to the alarm control panel. (you need to set check_alarm to false)
• Check Alarm: this method will goes to your alarm control panel and check the status of your alarm, showing in your users auditing and making use of the resources of the panel. Takes much more time, and during that time you can't arm or disarm you alarm.

So I add this flag in the configuration that basically only check the status of the alarm (first method) because it's fast and you don't need to make a request every 20 minutes.

Coming back to your script, you can set the check_alarm flag in the configuration to true and it will check your alarm panel directly every 20 minutes.

[guerrerotook]

I had no success in using release V1.3.0.0 for logging in to the french graphql endpoint https://customers.securitasdirect.fr/owa-api/graphql. Maybe not all countries are using the same version on the graphql end.

I noticed that the ApiManager._generate_id() is returning timestamps that are too long versus those that they use on the FR endpoint. But even after modifying those to a maximum of 14 characters (eg id ending on _______20226172028859), i keep getting a commanderror as below:

CommandError: 400, message='Invalid header value char', url=URL('https://customers.securitasdirect.fr/owa-api/graphql')

After adding an "auth" and an "installation" header value of {} in the login request, the request passes successfully again. I'm not sure if you are seeing the same behavior on your graphql endpoint?

Edit: it seems that they are also expecting those on the ApiManager.check_general_status() request.

Thanks for the comment @s3v, you raised a very important issue that maybe not all the country are using the same version of the graph api on the backend. I'm using the service from Spain and you from France. I think that I need to rethink how I can handle all of these multiple version of the server side API so I can have these operations depending on the configuration of your country.

Given said that, I can debug the API from my side because I have access to the API in Spain, but I'm going to need your help in order to do the same for the Frend and other API versions as well.

[Javvaz]

Thanks for the information and your work. I appreciate it.

The issue now with setting check_alarm to false is the home assistant alarm status doesn't inmediatelly change after executing any alarm operation. However that is something was working fine in the previous version.

Regards. Javier.

[guerrerotook]

Thanks for the information and your work. I appreciate it.

The issue now with setting check_alarm to false is the home assistant alarm status doesn't inmediatelly change after executing any alarm operation. However that is something was working fine in the previous version.

Regards. Javier.

That is really weird, because when I do a arm or disarm operation on the API, afterwards it always returns the next status for the alarm. Like in my case, when you arm or disarm, you can see Arming flashing in the UI and the whatever status you can set the alarm to.

My recomendation would be that you increase the logger detail for the component and see how it goes.

logger:
  default: error
  logs:
    custom_components.securitas: debug

[Javvaz]

To be honest I am not sure what is happening.

WIth check_alarm_panel true I always get the same messages "Tu Alarma está gestionando una solicitud anterior. Por favor, espera 90 segundos antes de realizar otra petición (5 min si es una petición de imagen)", however if I execute the same operation in Securitas Website works fine.

With check_alarm_panel false. Everything works fine except the home asistant alarm status is not update each time I execute any operation, I have to force the update through out the script.

I wonder if it is related to that I have the Securitas Verisure alarm previous to the last one.

Thanks for your help.

Javier.

[Javvaz]

Dear @guerrerotook

Thanks again for your work and collaboration.

I just checked my Securitas account in the Securitas Website and now they are applying the 2FA, so when you are authenticating in the WebSite they ask you the phone number in order to send you a code before asking you the same one.

Now your integration is failing with the below message: 2022-06-21 17:49:53 ERROR (MainThread) [custom_components.securitas.securitas_direct_new_api.apimanager] Unauthorized

I checked with true and false in the check_alarm_panel parameter with the same error (it was clear that was not involved in that, but ... I tried it just in case)

I am not sure how you are thinking to solve it.

Regards.

[guerrerotook]

Dear @guerrerotook Luis Guerrero Guirado FTE

Thanks again for your work and collaboration.

I just checked my Securitas account in the Securitas Website and now they are applying the 2FA, so when you are authenticating in the WebSite they ask you the phone number in order to send you a code before asking you the same one.

Now your integration is failing with the below message: 2022-06-21 17:49:53 ERROR (MainThread) [custom_components.securitas.securitas_direct_new_api.apimanager] Unauthorized

I checked with true and false in the check_alarm_panel parameter with the same error (it was clear that was not involved in that, but ... I tried it just in case)

I am not sure how you are thinking to solve it.

Regards.

That is a tought one, because I need to see how the handle the second factor of authentication to integrate that in the code. But for my account still not asking for it.

[jcorreaes]

Same issue here. I had 2FA activated yesterday on the web access (not in the app yet). The integration is not working anymore. I'm afraid no way to deactivate it. They ask for a 6 digit pin sent to your mobile phone. It's not going to be easy to handle.

I'm from Spain, so @guerrerotook have you tried from Securitas app or webapp?

[javiermartingonzalez]

Same here, in Spain and 2FA in web from today. Mobile app not asking for it.

[manolodh]

Desde hace 2 días ha dejado de funcionarme la integración, me aparece como "no disponible". Actualicé a tu última versión hace 5 días e iba bien, pero desde el día 21 por la tarde dejó de funcionar. El error que me da es el siguiente: Este error se originó a partir de una integración personalizada.

Logger: custom_components.securitas.securitas_direct_new_api.apimanager Source: custom_components/securitas/securitas_direct_new_api/apimanager.py:106 Integration: Securitas Direct (documentation, issues) First occurred: 22 de junio de 2022, 17:55:30 (1 occurrences) Last logged: 22 de junio de 2022, 17:55:30

Unauthorized

[otistarda]

Desde hace 2 días ha dejado de funcionarme la integración, me aparece como "no disponible". Actualicé a tu última versión hace 5 días e iba bien, pero desde el día 21 por la tarde dejó de funcionar. El error que me da es el siguiente: Este error se originó a partir de una integración personalizada.

Logger: custom_components.securitas.securitas_direct_new_api.apimanager Source: custom_components/securitas/securitas_direct_new_api/apimanager.py:106 Integration: Securitas Direct (documentation, issues) First occurred: 22 de junio de 2022, 17:55:30 (1 occurrences) Last logged: 22 de junio de 2022, 17:55:30

Unauthorized

A mi me paso exactamente lo mismo desde el dia que indicas, hoy he desinstalado toda la integracion e reiniciado he vuelto a instalarla desde cero y ahora esta funcionando, puedes probar.

[DNKROZ]

A mi me paso exactamente lo mismo desde el dia que indicas, hoy he desinstalado toda la integracion e reiniciado he vuelto a instalarla desde cero y ahora esta funcionando, puedes probar.

Hoy intenté esto sin mucha esperanza pero curiosamente funcionó, la web me pide el doble factor, pero ahora la integración ha vuelto a funcionar tras borrarlo todo y volver a instalar... pero ni idea de por qué.

I tried this today not hoping for it to work but oddly enough, it worked!, website still asks me for 2FA, but the integration is working again after purging everything and reinstalling... don't have clue about why though.

[Fireful]

Desde hace 2 días ha dejado de funcionarme la integración, me aparece como "no disponible". Actualicé a tu última versión hace 5 días e iba bien, pero desde el día 21 por la tarde dejó de funcionar. El error que me da es el siguiente: Este error se originó a partir de una integración personalizada. Logger: custom_components.securitas.securitas_direct_new_api.apimanager Source: custom_components/securitas/securitas_direct_new_api/apimanager.py:106 Integration: Securitas Direct (documentation, issues) First occurred: 22 de junio de 2022, 17:55:30 (1 occurrences) Last logged: 22 de junio de 2022, 17:55:30 Unauthorized

A mi me paso exactamente lo mismo desde el dia que indicas, hoy he desinstalado toda la integracion e reiniciado he vuelto a instalarla desde cero y ahora esta funcionando, puedes probar.

A mi me pasó lo mismo y he intentado esto mismo de reinstalar. He desinstalado la que tenía, reiniciado, y cuando voy a instalar, sólo me aparece la integración de "Securitas Direct" (Antes también aparecía una llamada "Securitas") y cuando intento instalarla, me pide usuario y contraseña y me da error "Unknown error occurred"

[otistarda]

Desde hace 2 días ha dejado de funcionarme la integración, me aparece como "no disponible". Actualicé a tu última versión hace 5 días e iba bien, pero desde el día 21 por la tarde dejó de funcionar. El error que me da es el siguiente: Este error se originó a partir de una integración personalizada. Registrador: custom_components.securitas.securitas_direct_new_api.apimanager Fuente: custom_components/securitas/securitas_direct_new_api/apimanager.py:106 Integración: Securitas Direct (documentación, problemas) Ocurrió por primera vez: 22 de junio de 2022, 17:55:30 (1 ocurrencias) Última logueado: 22 de junio de 2022, 17:55:30 No autorizado

A mi me paso exactamente lo mismo desde el dia que indica, hoy he desinstalado toda la integracion y reiniciado he vuelto a instalarla desde cero y ahora esta funcionando, puedes probar.

A mi me pasó lo mismo y él intentó esto mismo de reinstalar. He desinstalado la que tenía, reiniciado, y cuando voy a instalar, sólo me aparece la integración de "Securitas Direct" (Antes también aparecía una llamada "Securitas") y cuando intento instalarla, me pide usuario y contraseña y me da error "Unknown Se produjo un error"

Eso me paso a mi tambien, asegurate de que no quede nada, desinstalala de HACS y si tienes Shamba asegurate que en la carpeta custom components tampoco haya nada de securitas, reinicia antes de instalar e intentalo de nuevo y por supuesto asegurate que usuario y contraseña sea la de tu alarma. Suerte.

[javiermartingonzalez]

Yo ni he reinstalado, ayer no funcionaba... y hoy de repente está funcionando.

A ver hasta cuándo dura, web sigue pidiendo 2FA

[guerrerotook]

Madre mía que cantidad de casos raros que estamos teniendo co la API. En otra issue menciona que hay que refrescar el token cada 5 minutos y no cada 20 como lo tengo ahora mismo. He pedido que me digan lo que han modificado para intentar hacer que esta cosa funcione.

Muchas gracias a todos por los comentarios!

[Javvaz]

Ahora falla otra vez incluso con intervalo de 5 minutos a la hora de refresecar el token.

Gracias por tu trabajo y saludos.

[otistarda]

I don't know what they've done but I'm afraid it's a HA thing throughout the day Securitas, ZHA and Sonoff Lan have stopped working What a mess

[jsole]

A mi también me está fallando desde hace unas horas... ¿@guerrerotook has conseguido averiguar que están cambiando?

Un saludo y gracias por todo!

[javiermartingonzalez]

It seems to be something with HA new release. It was working but after updating, Securitas and Switchbot stop working

[otistarda]

Se sabe algo nuevo de Securitas?

[guerrerotook]

Yo estoy mirando la integración con el código fuente de la última versión. Dadme un poco de tiempo.

[rlcobos2]

I don't know what they've done but I'm afraid it's a HA thing throughout the day Securitas, ZHA and Sonoff Lan have stopped working What a mess

Sorry to the group, because offtopic response.

@otistarda, i have the same problems,

      ZHA ( at the end unique real solution was delete zigbee.db and reassign each device to the network ), hard job, but, at least it's solved and i can forgot it.

      Sonoff ( suppouse you are using alexxit integration like me ), they have a new update fixing the problem

      Securitas direct. Still waiting to @guerrerotook availability to fix this new change in securitas part.

Sorry for the offtopic.

[guerrerotook]

Hello everyone,

An update of the second factor of authentication. I started the job of integrating this here, https://github.com/guerrerotook/securitas-direct-new-api/tree/otp_challange

I made progress and I'm able to list the customer phone, select one phone and then receive the SMS and validate that the config flow works. From there we can have a funcional system.

There are some edges that need to be fixed, like, how to handle refresh tokens from the API instead of login again. (this will make the integration to ask for the code every hour, something that is not possible).

Bear with me on this, I'm working as fast as I can.

[otistarda]

Como vamos @guerrerotomo es solo un mensaje de animo :)

[guerrerotook]

Te respondo en español y en inglés después!

Español Pues por ahora la integración funciona con el tema de la autenticación de SMS y tengo el config flow configurado para que te vayan saliendo unas ventanas en el HA que te piden el móvil que tienes registrado y todo eso. Hasta ahí bien, pero el problema fundamental es que no se que API utilizan para refrescar el token.

Cuando te auténticas te dan un token para iniciar sesióny otra cosa llamada refreshToken, este segundo token se utiliza para volver a pedir un token sin tener que volver a iniciar sesión. Es lo que utilizan las aplicaciones móviles para iniciar sesión. El problema es que la version web de la aplicación no expone esa API y no se como se hace. Nuestra opción sería ver si podemos bajarnos el APK de la version de Android para ver que html/javascript se descarga en esa version e intentar solucionarlo. Pero siendo sinceros la cosa está complicada.

La unica alternativa es que, cada 30 minutos la integración dejaría de funcionar y te pediría iniciar sesión otra vez. Cosa que es imposible.

Si alguien sabe cómo bajarse el APK de la app y descompilarlo sería ideal.

English version. The current status of the ignoration is that we are able to login and request an SMS for the 2FA and it works. The integration with HA is also done and inside the config flow you are being presented with a UI where you can select your phone number and input the SMS code to authenticate.

Given said that, the issue right now is that as part of the login process there is two tokens, the authentication token, and the refresh token. The refresh token is being used to refresh the authentication token for mobile applications. But on the web version of the app this API and the javascript code are not being exposed. My only hope is to download the Android APK and see how the version for mobile includes this API and we can use it also to refresh the token.

The only possible alternative right now is to manually login every 30 minutes with the SMS challenge, something that is super annoying.

If someone knows how to download the APK and decompile would be fantastic.

[siom7]

Hello @guerrerotook ! Thanks for your time and your hard work. I think about Bluestack (Android emulator on Windows) to download Verisure Android APP but I don't know if it can help you it's just an idea and maybe you already try it.

[otistarda]

We'll keep an eye out, I'm sure you'll get it. Thanks for taking so much trouble.

[jsole]

Maybe you can use wireshark to listen to the connections the app is doing and get some information, at least the url it's calling. The info will be encrypted due to the https, but maybe you can get something interesting.

[joaoestevinho]

Hello @guerrerotook,

To begin with, thank you for having so much trouble with this.

I was looking into the web requests in the browser inspector and something caught my attention:

• There is this method call "mkValidateDevice" which first returns "Unauthorized" and only after the OTP is correctly sent will return the hash and refreshToken.
• The webapp always requires a new OTP on every login ands sends no arguments in mkValidateDevice except for the OTP in the security header of the 2nd call
• This method however can receive a few arguments going by the signature in the request:
  • $idDevice: String, $idDeviceIndigitall: String, $uuid: String, $deviceName: String, $deviceBrand: String, $deviceOsVersion: String, $deviceVersion: String

You may have already tried this, but I wonder if the "trusted device" is stored server-side, and if so, if we can make up some device by filling those fields with some randomly generated constant data it might return a valid session afterwards in the first mkValidateDevice efectively skipping the need for the OTP.

I did try to pull your branch to try it but was unable to get it running on my HA for some reason.

[pmcastro10]

Animo y gracias por tus esfuerzos... pedir ayuda con lo de la app a Securitas ni de broma, no?...

Saludos

[guerrerotook]

Hello @guerrerotook,

To begin with, thank you for having so much trouble with this.

I was looking into the web requests in the browser inspector and something caught my attention:

• There is this method call "mkValidateDevice" which first returns "Unauthorized" and only after the OTP is correctly sent will return the hash and refreshToken.

• The webapp always requires a new OTP on every login ands sends no arguments in mkValidateDevice except for the OTP in the security header of the 2nd call

• This method however can receive a few arguments going by the signature in the request:

  • $idDevice: String, $idDeviceIndigitall: String, $uuid: String, $deviceName: String, $deviceBrand: String, $deviceOsVersion: String, $deviceVersion: String

You may have already tried this, but I wonder if the "trusted device" is stored server-side, and if so, if we can make up some device by filling those fields with some randomly generated constant data it might return a valid session afterwards in the first mkValidateDevice efectively skipping the need for the OTP.

I did try to pull your branch to try it but was unable to get it running on my HA for some reason.

What you described is correct. The missing part was the RefreshLogin operation.

They don't send the code for the refresh operation in the javascript code for the web app.

[guerrerotook]

Goods news everyone, I found the refreshlogin operation and I started the integration.

https://github.com/guerrerotook/securitas-direct-new-api/commit/2ce56c002e8e9fc73317b20b70fe93dfd730ed60

For now the API throws an error 500 but I need to keep investivating if this thing works or not.

[jmatiasGH]

Ánimo Guerrerotook! Gracias por tus grandes esfuerzos y esta gran integración. No tengo mucho tiempo pero si puedo de alguna forma colaborar de algún modo, aunque sea haciendo pruebas me dices.

[guerrerotook]

Buenas noticias!! Ya he conseguido capturar el tráfico TLS de la app de android y ya tengo todo lo necesario. Además esta semana empiezo dos semanas de vacaciones y me voy a poner a tope con eso.

Voy a cambiar bastantes cosas y simular que es un dispositivo Android en vez de la web que es ahora.

Good news everyone, I successfully capture the TLS traffic in the Android app and now I have everything I need to continue. These next two weeks I will on vacations and I will have a lot of free time.

There are going to be a lot of changes in the code because I'm going to simulate that I'm a Android device instead of the web app.

[rlcobos2]

Thanks for your effort.

This is a nice project!!!

Ánimo!!!

[alnavasa]

Thanks a lot @guerrerotook , there's a lot of people that would benefit from your hard work! thanks!

[Lugib]

Buenas noticias!! Ya he conseguido capturar el tráfico TLS de la app de android y ya tengo todo lo necesario. Además esta semana empiezo dos semanas de vacaciones y me voy a poner a tope con eso.

Voy a cambiar bastantes cosas y simular que es un dispositivo Android en vez de la web que es ahora.

Good news everyone, I successfully capture the TLS traffic in the Android app and now I have everything I need to continue. These next two weeks I will on vacations and I will have a lot of free time.

There are going to be a lot of changes in the code because I'm going to simulate that I'm a Android device instead of the web app.

Great news! Buenas noticias compi! Hopefully new version will fix integration problems. If you need any tester let me know I can help :-)

Cheers! Saludos y Gracias!

[andr1u]

Thank you again!

I uninstalled the addon because was not working, reinstalling will not create the alarm entity again. Hope this fix like May's water! 😁

[vipial1]

Buenas noticias!! Ya he conseguido capturar el tráfico TLS de la app de android y ya tengo todo lo necesario. Además esta semana empiezo dos semanas de vacaciones y me voy a poner a tope con eso.

Voy a cambiar bastantes cosas y simular que es un dispositivo Android en vez de la web que es ahora.

Eso es genial! Asi quizás tambien se puede solicitar imágenes de los fotodetectores! Te puedo echar una mano si lo necesitas.

[Lugib]

Any news so far @guerrerotook ?

[guerrerotook]

Hey, progress report. I made all the code changes to incorporate all the necessary headers and secrets that the API required.

I'm making process with the API but because I have to test with my personal account I don't want to upset the API.

[soth78]

If u need a tester @guerrerotook, let me know!

[andr1u]

Hey, progress report. I made all the code changes to incorporate all the necessary headers and secrets that the API required.

I'm making process with the API but because I have to test with my personal account I don't want to upset the API.

Hi @guerrerotook, can we test the OTP branch?

[guerrerotook]

Hi @guerrerotook, can we test the OTP branch?

Not yet, I'm able to get the authentication token but struggled to setup the config flow in HA.

In the future I will ask you guys to test this branch before merging back to master.

[andr1u]

Hi @guerrerotook, can we test the OTP branch?

Not yet, I'm able to get the authentication token but struggled to setup the config flow in HA.

In the future I will ask you guys to test this branch before merging back to master.

OK. Thank you again for your work!

[vipial1]

Hi @guerrerotook, can we test the OTP branch?

Not yet, I'm able to get the authentication token but struggled to setup the config flow in HA.

In the future I will ask you guys to test this branch before merging back to master.

hey @guerrerotook Take a look to this: https://github.com/vipial1/securitas-direct-new-api/commit/531f476452a36b9efb742e78f341f7c524c55656

It is not nice, but working.

[guerrerotook]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

[otistarda]

Hola a todos, permítanme resumir mis esfuerzos hasta ahora con la nueva autenticación de dispositivos que Securitas comenzó a implementar recientemente. Como sabrá, ahora es obligatorio verificar el dispositivo al que está llamando la API para tener una sesión abierta. Eso es lo que hace que la integración HA no funcione, o que no funcione si tenemos que iniciar sesión cada 20 minutos con un código SMS.

¿Dónde estamos ahora?

Hay una nueva rama otp_challange que contiene todos mis esfuerzos para hacer que esto funcione. Hay una llamada a la API validate_device que, como dice el nombre, valida que el dispositivo está autorizado. Tengo el flujo de SMS trabajando en HA. Puede seleccionar uno de sus números de teléfono, recibir un SMS y luego volver a llamar a esta API. Pero por alguna razón esto no funciona como se esperaba. Deberíamos obtener esta respuesta en json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

Y luego haga otra solicitud para iniciar sesión y deberíamos obtener algo como eso:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

En el hash y el refreshToken deberíamos obtener un token web seguro.

Pero no, lo que obtenemos es un token hash en device_call que realiza la segunda llamada para iniciar sesión con la propiedad needDeviceAuthorization establecida en verdadero.

¿Cuál es el corazón de la cuestión?

En este momento hay una propiedad idDevice que identifica el dispositivo que se ve así:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

Pero no tengo idea de cómo crear una identificación como esta. No parece una cadena de base 64 codificada y parece un token cifrado. Eso es lo que nos impide validar con éxito el dispositivo.

¿Qué he probado?

Tengo este antiguo dispositivo Android en el que instalé un certificado CA de confianza para poder monitorear todo el tráfico en el dispositivo desde todas las aplicaciones. Con eso pude capturar completamente todo el tráfico de la aplicación securitas. Desinstalo la aplicación y la vuelvo a instalar un par de veces para ver cómo funciona el flujo. Una vez que se valida el dispositivo, incluso si desinstala la aplicación y la vuelve a instalar, no necesita validar nuevamente. Entonces, la operación del dispositivo de validación persiste de alguna manera en el tiempo.

¿Qué estoy preguntando?

Ayuda. No sé si alguien tiene más experiencia con este tipo de API o pone otra perspectiva que me puede funcionar. Ofrezco la posibilidad de compartir los logs sin mi información personal o ayudar a alguien a capturar el tráfico en sus dispositivos.

Gracias por tu esfuerzo, estoy seguro que al final lo conseguiras.

[DNKROZ]

Hello @guerrerotook , first and foremost thanks for all your work, appreciated.

As far as I understand (not my area of expertise) we don't have a way to generate a secure web token from scratch since this is something done by the app and we can only see the results of that but not the method used to generate it, but we can have (or maybe access) the stored device token since this should be stored locally or exchanged with the remote server during the validation process.

Maybe, as a workaround for the time being, we could include this device token during HA integration config flow as a user input value and use the token generated by our phone (or a cheap Android device) to be able to spoof that id info and disguise the custom integration as our own phone or device.

It's not ideal, this would be to be able to run all config flow from the custom integration (including SMS and device token generation) but should enable us to have "something" to work with.

Most probably you've already thought about this... but just my two cents :) If you need something from me (I have several Android phones with several Android versions) or some testing just ask.

Regards.

[vipial1]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

hmmmm, interesting. Have you checked the HTTP response headers? Sometimes you find there some interesting values. If you can share with me some logs (maybe wireshark trace?), I would take a look.

[jmatiasGH]

https://empleo.securitasdirect.es/vacancy-detail/r2021100571

Aquí a lo mejor encuentras alguna explicación.

El mar, 2 ago 2022 18:30, Luis Guerrero @.***> escribió:

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code. Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device https://github.com/guerrerotook/securitas-direct-new-api/blob/otp_challange/custom_components/securitas/securitas_direct_new_api/apimanager.py#L173that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{

"data": {

    "xSValidateDevice": {

        "res": "OK",

        "msg": "Petición procesada correctamente",

        "hash": null,

        "refreshToken": null,

        "legals": null

    }

}

}

And then make another request to login and we should get something like that:

{

"data": {

    "xSLoginToken": {

        "__typename": "XSLoginToken",

        "res": "OK",

        "msg": "Usuario validado correctamente",

        "hash": "",

        "refreshToken": "",

        "legals": true,

        "changePassword": false,

        "needDeviceAuthorization": false,

        "mainUser": true

    }

}

}

In the hash and the refreshToken we should get a secure web token. https://hackernoon.com/json-web-token-how-to-secure-your-data-with-jwt-8j5o3wzb#:~:text=A%20JSON%20Web%20Token%20%28JWT%29%20is%20an%20open,digitally%20signed%2C%20it%20can%20be%20verified%20and%20trusted.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true. What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device. What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time. What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

— Reply to this email directly, view it on GitHub https://github.com/guerrerotook/securitas-direct-new-api/issues/57#issuecomment-1202961007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AV2JLYDDY5FWU7R74Q5RQUDVXFEKXANCNFSM5Y3Q75DQ . You are receiving this because you commented.Message ID: @.***>

[soysnorre]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token. But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

hmmmm, interesting. Have you checked the HTTP response headers? Sometimes you find there some interesting values. If you can share with me some logs (maybe wireshark trace?), I would take a look.

Muchas gracias por el esfuerzo en esta integración @guerrerotook-. Acabo de intentar llevar a cabo la integración con Securitas y no soy capaz de llevar a cabo la misma.

Ahora tras leer todos estos ISSUES encuentro la razón de ella.

Sólo hacerte saber del gran trabajo que haces y si necesitas de ayuda para algo lo intentamos, pero mi nivel de programación es bajo es este momento en estas areas.

Saludos y gracias,

[bcampru]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token.

But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

Hello, I've tried to reverse engineer the verisure app, what i've discovered is that they are saving the deviceId param inside a sharedPreferences (com.indigitall.prefs), the key name is com.indigitall.prefs.deviceId.

For getting and setting this variable they are using the class yb/c (you can find this reverse engineering the apk), in my opinion the important method of this class is the one named u:

public static void u(Context paramContext, String paramString) {
    if (a.t(paramString)) {
      SharedPreferences.Editor editor = h(paramContext);
      if (editor != null)
        editor.putString("com.indigitall.prefs.deviceId", paramString).apply(); 
    } 
}

I've tried to track where the paramString variable is created and it comes from the class r8/b. From this point it starts to get difficult to track the origin and I've stopped here, the next step might be trying to debug the app and see what's going on.

Hopefully this will be helpful.

[guerrerotook]

Hey everyone, let me summarize my efforts so far with the new device authentication that Securitas started enforcing recently. As you may know now is mandatory to verify the device you are calling the API in order to have an open session. That is what making the HA integration not working, or not making it functional if we have to login every 20 minutes with an SMS code.

Where we are right now?

There is a new branch otp_challange that contains all my efforts to make this thing works. There is a API call validate_device that as the name says validate that the device is authorized. I have the SMS flow working in HA. You can select one of your phone numbers, receive an SMS and then call this API again. But for whatever reason this is not working as expected. We should get this response in json.

{
    "data": {
        "xSValidateDevice": {
            "res": "OK",
            "msg": "Petición procesada correctamente",
            "hash": null,
            "refreshToken": null,
            "legals": null
        }
    }
}

And then make another request to login and we should get something like that:

{
    "data": {
        "xSLoginToken": {
            "__typename": "XSLoginToken",
            "res": "OK",
            "msg": "Usuario validado correctamente",
            "hash": "",
            "refreshToken": "",
            "legals": true,
            "changePassword": false,
            "needDeviceAuthorization": false,
            "mainUser": true
        }
    }
}

In the hash and the refreshToken we should get a secure web token. But no, what we get is a hash token in the device_call making the second call to login with the property needDeviceAuthorization set to true.

What is the heart of the issue?

Right now there is a idDevice property that identifies the device that looks like this:

idDevice=d7MwrBXGQF6ZjI7b4_hVgU:APA91bFg79TE0qo3z72dWJ2iJf_swmUie777KgKSLod3qDMS5UxDh9YO5Rrd0n2bDtk2v5G2Wb9zUAoR-ES_aozdVDZTfOKCgloH6D-nvgQO2YY_ToLc6cb7EBKsdPWosFiea6oYsQZb

But I have no idea how to create id like this myself. It doesn’t look like a encoded base 64 string and it looks like a encrypted token. That is what is preventing us to successfully validate the device.

What have I tried?

I have this old android device where I installed a trusted certificate CA so I can monitor all the traffic in the device from all apps. With that I was able to fully capture all the traffic of the securitas app. I uninstall the app and reinstall a couple of time to see how the flow works. Once the device is validated, even if you uninstall the app and reinstall you don’t need to validate again. So the validate_device operation somehow persist over time.

What am I asking?

Help. I don’t know if someone have more experience with this kind of API or put another perspective that can me it works. I offer the possibility of sharing the logs without my personal information or help someone to capture the traffic on their devices.

Hello, I've tried to reverse engineer the verisure app, what i've discovered is that they are saving the deviceId param inside a sharedPreferences (com.indigitall.prefs), the key name is com.indigitall.prefs.deviceId.

For getting and setting this variable they are using the class yb/c (you can find this reverse engineering the apk), in my opinion the important method of this class is the one named u:

public static void u(Context paramContext, String paramString) {
    if (a.t(paramString)) {
      SharedPreferences.Editor editor = h(paramContext);
      if (editor != null)
        editor.putString("com.indigitall.prefs.deviceId", paramString).apply(); 
    } 
}

I've tried to track where the paramString variable is created and it comes from the class r8/b. From this point it starts to get difficult to track the origin and I've stopped here, the next step might be trying to debug the app and see what's going on.

Hopefully this will be helpful.

That is very interesting, do you know how to read those values in Android? I have a rooted device.

[AdriVillaB]

The shared preferences is stored on the data directory, /data/data/<package_name>/shared_prefs. It's a XML file with all the values there, you could grep for com.indigitall.prefs.deviceId and you'll get your value.

[otistarda]

nada nuevo sobre securitas, ¿no?