Sign-in API call results in 403 - You are forbidden to perform this operation

[JeffResc]

POST request to /users/sign_in.json is now resulting in a 403 with the error "You are forbidden to perform this operation" with no reason as to why this API call is no longer functioning as it originally was.

I have confirmed that the app_id and app_secret constants seem to still be correct as changing these values will instead result in a 404 as expected.

Originally reported at home-assistant/core#123392

[bakernigel]

@JeffResc
I have a mitm capture I can provide of the Shark APP logging in if this helps. I threw together some python code to try to copy the flow that the APP uses but no luck getting past the Shark login. Contact me directly if you want.

[fermulator]

Anyone formally reached out to Shark to complain? This is a violation of their product terms; We purchased it with access to the API, they can't legally revoke it.

[zacharyfleck]

@fermulator Unfortunately they do not have any legal requirement to keep their API available. Not to mention, this particular integration was a reverse engineered API which simply isn't something they even support. Let's pretend for a moment, though, that they did want to support it. These companies write their TOS in such away that they can change them at any given time with very little notice. At least in the US, there's very little legislation around anything that relates to this. Unless there is some other way to access the API now, we might be out of luck here.

[voccs]

It looks like they've shifted to using Auth0 inside the iOS app (I'm new to Shark, not sure if that's a recent development or if the Ayla API was just an easier way in). There's a backend flow starting from here that uses this mechanism to acquire tokens and some OAuth2 bits.

I wasn't able to MITM a successful login from my phone, the final step in the flow returns an iOS Shark app location that doesn't appear to get intercepted by the proxy - whatever happens there, the flow seems to fail and revert to its beginning (I guess if it doesn't have the state associated with the start of the flow in that other, non-intercepted call, it can't succeed).

The Auth0 documentation and code samples probably provide enough so that if one captured the Shark app client ID and had valid user credentials to use, they could plug the right values in to an imitation flow and get a token at the end. It might need to differ from a captured flow a bit by using a non-iOS redirect_uri.