All Requests are Failing with "Request Failed with status 400 - Bad Request" Even with Updated Key

[BigThunderSR]

All requests are failing with "Request Failed with status 400 - Bad Request". Updated key in #232 does not seem to make a difference.

[Maliron]

Why are they SOOO upset that we can interface with their API faster than the terrible MyGMC/Chevrolet app? The apps are so incredibly slow, it is so much faster to bring is all in to HomeAssistant and use that for remote starting and such. We seem to lose access to the API every couple weeks though. This really sucks.

Do we know if this is them shutting us out of the API or simply them changing it? I believe the API is not officially documented or open and this was all reverse engineered right?

[LightningManGTS]

I started doing the homeassitant > node red implementation myself because of gm dropping support for google home (big thanks Bigthundersr by the way). The least they can do is not be insufferable about their API access when their own web developers can't code their website to unhide authenticator elements properly.

[tbclark3]

Why are they SOOO upset that we can interface with their API faster than the terrible MyGMC/Chevrolet app? The apps are so incredibly slow, it is so much faster to bring is all in to HomeAssistant and use that for remote starting and such. We seem to lose access to the API every couple weeks though. This really sucks.

I also like the API being faster, but it's so much more than that. Integrating into Home Assistant lets me issue a warning if we arm the security system at night while the car is still plugged in (don't want it to catch fire while we're asleep) or early in the morning if I forgot to charge it. It sends me an email to put air in the tires if needed. I'm on my second Bolt, but if GM doesn't want me to use the API, I will switch to a different brand when my lease is up in a couple of months.

[BennyDaBee]

@joelvandal @coelho I know you two were a big help with the last big issue we had, anything you guys would be able to take a look at?

[LightningManGTS]

Is "appId" and "appSecret" in src/onStarAppConfig.json something we should be making unique in every deployment of this library like device UUID's? Is it possible that all these unique instances are showing up as one "device" and then that's what causing it to get blocked? (due to the total number and frequency of requests?)

I ask not being too familiar with how the reverse engineering works.

My only other question is, what if we ask GM directly? or is there enough trepidation that they would outright deny this by making it harder for the api requests to function? https://www.onstar.com/business-solutions/api-data-services

[BrettEBowman]

All requests are failing with "Request Failed with status 400 - Bad Request". Updated key in #232 does not seem to make a difference.

@BigThunderSR: I think that #232 was updated earlier today (Monday, 10/2/23) with another new key pair. Have you been able to test if that gets it working again?

[BigThunderSR]

All requests are failing with "Request Failed with status 400 - Bad Request". Updated key in #232 does not seem to make a difference.

@BigThunderSR: I think that #232 was updated earlier today (Monday, 10/2/23) with another new key pair. Have you been able to test if that gets it working again?

I tried it earlier today even though I knew it wouldn't work either and it did not work as expected.

We need @samrum and others to figure out what changed in the API and make the necessary modifications to OnStarJS to make things work again. Thanks.

[BrettEBowman]

Bummer! Thanks for trying!

…

-Brett From: BigThunderSR ***@***.***> Sent: Monday, October 2, 2023 6:50 PM To: samrum/OnStarJS ***@***.***> Cc: Brett Bowman ***@***.***>; Manual ***@***.***> Subject: Re: [samrum/OnStarJS] All Requests are Failing with "Request Failed with status 400 - Bad Request" Even with Updated Key (Issue #233) All requests are failing with "Request Failed with status 400 - Bad Request". Updated key in #232<#232> does not seem to make a difference. @BigThunderSR<https://github.com/BigThunderSR>: I think that #232<#232> was updated earlier today (Monday, 10/2/23) with another new key pair. Have you been able to test if that gets it working again? I tried it earlier today even though I knew it wouldn't work either and it did not work as expected. We need @samrum<https://github.com/samrum> and others to figure out what changed in the API and make the necessary modifications to OnStarJS to make things work again. Thanks. — Reply to this email directly, view it on GitHub<#233 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEEJW7OMH7WYTFNZSCBY57TX5NHKRAVCNFSM6AAAAAA5J3RWYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTHEZTCNZSG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[BennyDaBee]

Between #214 and #208, I am trying to get SSL pinning setup to be able to see the requests in real time. Having issues getting the app just to work on Genymotion

[BennyDaBee]

Yea I cant even get the normal app to work on Genymotion before I add anything else to the "device". Any help would be appreciated.

[BrettEBowman]

Flespi.com seems to have a [Changelog] general-motors-onstar protocol.

The last entry there (from 4 days ago) says:

general-motors-onstar protocol has been updated, new parameters added:

EHPE - flespi name position.accuracy
AGEIND - flespi name position.valid

That probably does indicate/confirm that there was a recent change to the OnStar API. Those items seems to only relate to getting location, not the authentication call. But maybe it is at least some clue.