The method '[]' was called on null

[Todd1561]

Hi there, thanks for taking the time to create this project. I've been using it for over a year now without much issue. A couple days ago I noticed my basic script to pull battery charge level stopped working. I'm getting this error, any thoughts? The stock Nissan iOS app works for me so it doesn't appear to be an issue on their end or with my account.

Unhandled exception:
NoSuchMethodError: The method '[]' was called on null.
Receiver: null
Tried calling: []("authToken")
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:54:5)
#1      NissanConnectSession.login (package:dartnissanconnectna/src/nissanconnect_session.dart:110:30)
<asynchronous suspension>
#2      main.<anonymous closure> (file:///D:/Utilities/TANEVs/dartnissanconnectna-master/getCurChargeLevel.dart)
<asynchronous suspension>

[l3nticular]

Same for me; I'm guessing the API key was rolled. I have the API key from the latest iOS app version and I'm attempting to give it a try.

[l3nticular]

(The latest iOS app API key is different than the one in the repo; I'm not sure if that's expected though).

[l3nticular]

Trying just the updated API key didn't work. I wonder if I have to update the UserAgent etc. to match iOS when using this key.

[l3nticular]

Yep, that worked! I'll submit a PR.

[drewzarn]

I used the change from @l3nticular and it fixed the issue for me as well. FYI @Tobiaswk

[Tobiaswk]

@drewzarn @l3nticular The new API key has been added (see da59b39). I've also added an optional userAgent parameter to the login/authentication operation/method. Nissan has blocked the default user agent I used previously. You need to provide a device user agent matching your device or spoof a valid one.
Example iOS;
CFNetwork/897.15 Darwin/17.5.0 (iPhone/6s iOS/11.3)
You could use a static user agent like above. They cannot block this as it's valid for other users of that device. I choose to construct it based on the device when using the client within My Leaf (see Tobiaswk/carwingsflutter@064f4e6). I like this approach better instead of a static user agent.

[l3nticular]

Thanks Tobias; I think it would be best if you make the API key a parameter too. I’m guessing (with no evidence) that they might be tying the API key to the version number in the UserAgent.

I posted the useragent from my app in the PR which seems to be significantly different than yours.

[Tobiaswk]

@l3nticular They only use one static API-key (that they sometimes change on new client versions etc.). The commit I referenced for carwingsflutter uses the correct user-agent header that the official app also uses. It's the system user-agent derived from the OS and device identifier (vendor and model).

[l3nticular]

@Tobiaswk interesting. Are you sure they only use one API key across iOS and Android apps? My thought about the user agent changing is that I would expect that every time the API key gets rolled, they might tie that to a UserAgent roll as well. The PR that I pushed was using the UserAgent captured by mitmproxy. I'm guessing (based on seeing iOS 11.3) that your iOS capture was taken a long time ago, and the current useragent used actually embeds the App version. I think that the app was not overriding the useragent previously, so the default iOS non-Safari useragent was shown. Now it appears that they are overriding it.

[Tobiaswk]

I'm not sure about iOS but on Android a static API key is used. It's generated on the client side using 3 static hexadecimals. Obviously as a form of cheap security through obscurity. The result is a key that never changes. Only when the static hexadecimals are modified in the source. Den 27. september 2021 08.47.06 CEST, l3nticular ***@***.***> skrev: ***@***.*** interesting. Are you sure they only use one API key across iOS and Android apps? My thought about the user agent changing is that I would expect that every time the API key gets rolled, they might tie that to a UserAgent roll as well. The PR that I pushed was using the UserAgent captured by mitmproxy. I'm guessing (based on seeing iOS 11.3) that your iOS capture was taken a long time ago, and the current useragent used actually embeds the App version. I think that the app was not overriding the useragent previously, so the default iOS non-Safari useragent was shown. Now it appears that they are overriding it.

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2 (comment)

[l3nticular]

This is an issue all over again. My iOS Nissan EV& Services app updated from 7.2.4 to 7.2.5 and now it looks like an entirely new API. URL is https://nissan.sc.omtrdc.net/b/ss/nissanlive.leaf.app/0/OIP-4.13.8/s.

I would assume that the old API should still be working, but my leaf2mqtt instance can't log in. I'm going to dig into it more this weekend. Please let me know if your existing instances are running fine.

[l3nticular]

Looks like a forced update; the old API might not work anymore.

leaf2mqtt    | $ Headers: {Content-Type: application/json, API-Key: bAwSKw0f+p0tG8astBGpvsXmgcWiVWLrh5ejIYg55D+jH1j1Oi3Hsqw21ri0XBJp, User-Agent: NissanLeaf/7.2.4 CFNetwork/1312 Darwin/21.0.0}
leaf2mqtt    | $ Result: {forceUpdateAndroid: true, forceUpdateiOS: true, iOSMinVersion: 7.2.5, androidMinVersion: 7.2.5, iOSCAMinVersion: 7.2.5, androidCAMinVersion: 7.2.5}

[l3nticular]

Correction; it looks like I didn't get your baseURL update as well. So the API that was working fine for me before stopped working, but your latest update does indeed fix it.

I'm still surprised how much different the app API is now than the old API. I'm wondering if its days are numbered.