Closed ardevd closed 4 months ago
I note that JLR updated their app, which seems to work unlike their earlier effort. Presumably part of why they revised their API?
I`d like to offer some help, if you need a third party to try something out.
I have an ipace, and used you Wattcat app.
Appreciate the offer. I'll poke around the API this week and see what I find. I might end up needing willing testers if I find a way around the restrictions.
Since JLR have decided not to reach out in any way I'll keep trying to document and utilize their APIs. ;)
I'll have a look too.
I have a Discovery Sport and use jlrpy. Happy to help with testing.
It seems to me that the first two steps of the login process are working: The user authentication POST returns tokens as it should, and the device registration POST succeeds, but at the 3rd step the GET request to the login URL returns an HTTP status of 407 (Proxy Authentication Required)
JLR:
We are responsible for the performance and safety of our vehicles and provide a warranty for this. We are not able to test, approve and warrant the safety and security of unauthorised third-party access to our vehicles and its data. This is a permanent change and only approved, authorised and tested apps will have access to our vehicles and their data. We are working to develop authorised solutions to smart home and energy services as quickly as possible. We apologise for any inconvenience this may have caused, but hope you understand why this was necessary.
@Troon where did you get that from?
@Troon where did you get that from?
Facebook I-PACE Owners group members have had that back in response to questions via DM on X (formerly Twitter).
That leaves the question of whether I should publish a workaround even if I discover one.
@ardevd - are you on slack. Can we chat. Have an update for you.
@ardevd - are you on slack. Can we chat. Have an update for you.
Not on Slack I'm afraid. Discord?
Not on Slack I'm afraid. Discord?
Yes - msp1974
JLR:
We are responsible for the performance and safety of our vehicles and provide a warranty for this. We are not able to test, approve and warrant the safety and security of unauthorised third-party access to our vehicles and its data.
This is a permanent change and only approved, authorised and tested apps will have access to our vehicles and their data. We are working to develop authorised solutions to smart home and energy services as quickly as possible. We apologise for any inconvenience this may have caused, but hope you understand why this was necessary.
As I've said elsewhere, it's complete rubbish. The banks are responsible for the security of people's bank accounts and a wealth of personal information, yet even they can connect your bank account securely to 3rd party apps via the Open Banking protocol.
Through key exchange and restricted permissions it's totally possible to lock a system down and yet offer information and even control to customers via third party apps.
Or maybe JLR's programmers really aren't up to the job. In which case I don't want them anywhere near the control systems of the car I use to transport my loved ones around.
JLR actually has a surprisingly passionate enthusiast owners community. It's sad to the company fighting against open source contributions to their eco system instead of engaging in constructive cooperation that would benefit everyone. I have had lots of cool ideas for projects over the years but I've chosen not to invest time into it out of fear that JLR could rugpull me at any time without warning.
However, I don't intend to let arbitrary changes to the InControl API alone stop me from maintaining my projects.
If anyone at JLR wishes to discuss the matter I'd be more than happy to do so.
FWIW I'm pretty sure there is a way to work around the blockage. Possibly there is a key embedded in the app? It can be extracted. For a few years I was a player of the Niantic game "Ingress", the predecessor to the very popular Pokemon Go. There was an alternate client that Niantic tried to stomp out for years but it wasn't technically possible. I mean, at the end of the day, the server gets an API request and there's no way to be sure who it's coming from.
JLR can't stop it technically but obviously they can stop it legally if they choose to send lawyers after the developers. I'm not even sure they would be in the right, legally, but it doesn't matter, indie software developers can't fight big-company lawyers.
It might be worth looking into OVMS if the API stays locked down. Currently I'm regretting really hard that I just extended my in-control subscription and not spent that money on the OVMS hardware instead.
@ridingwolf Workaround in place. Problem solved (for now) :)
Good work @ardevd 👌😁
Good work @ardevd 👌😁
Kudos to @msp1974 for the team effort.
Well done, that was quick. Wattcat working again.
Andrew Penny
From: ardevd @.> Sent: Wednesday, March 6, 2024 6:43:02 PM To: ardevd/jlrpy @.> Cc: andrewpenny @.>; Comment @.> Subject: Re: [ardevd/jlrpy] Investigate new JLR API restrictions (Issue #116)
Good work @ardevdhttps://github.com/ardevd 👌😁
Kudos to @msp1974https://github.com/msp1974 for the team effort.
— Reply to this email directly, view it on GitHubhttps://github.com/ardevd/jlrpy/issues/116#issuecomment-1981552279, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARVLMLBTM4IRTKYNUOI3AFDYW5PTNAVCNFSM6AAAAABEIR34NGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGU2TEMRXHE. You are receiving this because you commented.Message ID: @.***>
Thanks for the fast workaround!
Thank you so much for your effort and the workaround !
JLR have seemingly blocked third party access to it's APIs. Need to investigate exactly what they have done.