sudden 403 on location.getSecurityPanel() location.getDevices()

[ferdinandhelmer]

Is there an existing issue for this?

• I have searched the existing issues

Describe The Bug

sudden 403 on location.getSecurityPanel() location.getDevices()

• it worked for a long time
• suddenly (sometime ysterday) it stopped
• • login and refresh-token checked and that's fine

may a beginners mistake, but what am I doing wrong?

To Reproduce

No response

Expected behavior

getSecurityPanel returns the corresponding object rather than a 403

Relevant log output

No response

Screenshots

No response

Additional context

No response

OS

Linux

Node.js Version

18

ring-client-api

11.7.5

Operating System

Linux

[tsightler]

You listed ring-client-api version as 6.0.3, which is a valid version, but is ancient and might not be using the required headers. Is that really the version you are using? If so, you should definitely upgrade to a recent version and re-test. I just checked these functions in 12.0.1 and everything still seems to work as expected so I don't think anything has changed in the underlying API.

Another common issue with 403 is being blocked due to abuse, i.e. too much polling or using a VPN service, or if the token expired and constant polled with the bad token, etc. Since I don't know your use case this is a potential issue as well. Make sure that the Ring app can connect from the same network. Usually, if you've been blocked for a bad token, you just have to stop polling the Ring API from that IP for some hours and the ban will be lifted.

[ferdinandhelmer]

I was not sure about the ring-client-api version first, as I use it from node-red with the package node-red-contrib-ring-alarm which in turn includes this js package.
I suspected something with the token ahndling and in that case, yes, I can just wait it out for the ban to be lifted. Being only a occasional .js user I wonder how the token rollover exactly happens. I see that in the RingRestClientObject there are several refreshtokens:

restClient: RingRestClient {
    authOptions: {
      refreshToken: 'passed-in-token',
      cameraStatusPollingSeconds: 20
    },
    refreshToken: 'passed-in-token again',
    authConfig: {
      rt: 'some other previously not known token',
      hid: 'someuuid'
    },.

What is the meaning of the second token 'some other previously not known token'? Is that one the rollover token? And what do I do in my next instantiation of the RingApi? Do I pass the other token and thus "exchange" the token with every instantiation? Would be ok for me just curious what is the way it is meant to be done.

Is there a known rate limit for such instantiations? I'd probably do it every other 5 minutes or so...

Thanks for your help and for not getting annoyed with such supposedly trivial questions.

[tsightler]

I didn't really follow the code snippets you published, but perhaps it is confused by the fact that what is called "refresh token" in the configuration is not just the raw Ring refresh token, it's a base64 encoded, stringified JSON object that combines multiple bits of persistent data including the Ring refresh token, hardware id and the Firebase push notification auth data. This string is decoded and the component parts are used so, for example, rt = only the Ring specific refresh token, while hid = the hardware id, but, in the config, all of this is combined into a single string called "refresh token" in the config.

All of this is handled automatically by the library though, as I noted above, all a consumer of ring-client-api needs to do is monitor onRefreshTokenUpdated and, when new tokens are generated (typically once an hour, but also immediately after initial connection, etc), store the new resulting string as the refresh token. This is covered in the wiki.

[ferdinandhelmer]

Thank you vor the explanations and the help! Greatly appreciated!