[oauth] Fix access token serialization/deserialization

[jlaur]

This fixes a regression of #3066 where serialization and deserialization to and from storage was broken after migrating from LocalDateTime to Instant:

2022-09-11 22:18:41.210 [ERROR] [lient.internal.OAuthStoreHandlerImpl] - Unable to deserialize json, discarding AccessTokenResponse.  Please check json against standard or with oauth provider. json:
{
  "accessToken": "xxx",
  "tokenType": "Bearer",
  "expiresIn": 2592000,
  "refreshToken": "xxx",
  "createdOn": "2022-08-14T21:21:05.568991"
}
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 6 column 17 path $.createdOn
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:226) ~[bundleFile:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:131) ~[bundleFile:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:222) ~[bundleFile:?]
	at com.google.gson.Gson.fromJson(Gson.java:963) ~[bundleFile:?]
	at com.google.gson.Gson.fromJson(Gson.java:928) ~[bundleFile:?]
	at com.google.gson.Gson.fromJson(Gson.java:877) ~[bundleFile:?]
	at com.google.gson.Gson.fromJson(Gson.java:848) ~[bundleFile:?]
	at org.openhab.core.auth.oauth2client.internal.OAuthStoreHandlerImpl$StorageFacade.get(OAuthStoreHandlerImpl.java:283) [bundleFile:?]
	at org.openhab.core.auth.oauth2client.internal.OAuthStoreHandlerImpl.loadAccessTokenResponse(OAuthStoreHandlerImpl.java:119) [bundleFile:?]
	at org.openhab.core.auth.oauth2client.internal.OAuthClientServiceImpl.getAccessTokenResponse(OAuthClientServiceImpl.java:326) [bundleFile:?]
	at org.openhab.binding.mielecloud.internal.auth.OpenHabOAuthTokenRefresher.getAccessTokenFromStorage(OpenHabOAuthTokenRefresher.java:121) [bundleFile:?]
	at org.openhab.binding.mielecloud.internal.handler.MieleBridgeHandler.tryInitializeWebservice(MieleBridgeHandler.java:232) [bundleFile:?]
	at org.openhab.binding.mielecloud.internal.handler.MieleBridgeHandler.initializeWebservice(MieleBridgeHandler.java:143) [bundleFile:?]
	at org.openhab.binding.mielecloud.internal.handler.MieleBridgeHandler.initialize(MieleBridgeHandler.java:120) [bundleFile:?]
	at jdk.internal.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 6 column 17 path $.createdOn
	at com.google.gson.stream.JsonReader.beginObject(JsonReader.java:384) ~[bundleFile:?]
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:215) ~[bundleFile:?]
	... 22 more

Value will now correctly be serialized as Instant into the store, and deserialization supports both Instant and LocalDateTime (for backwards compatibility).

[lolodomo]

I believe there is a kind of urgency to review & merge this fix.

[J-N-K]

Thanks.

[lolodomo]

@jlaur : do you know if the bug was included in a 3.4 milestone?

[jlaur]

@lolodomo - it was unfortunately introduced in 3.4M2.

[lolodomo]

Ok, we know what to say in case the problem would be reported in the community forum.

I saw myself an exception the last time I installed a snapshot.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/mercedes-me-binding/136852/55

[lolodomo]

@jlaur : I just installed snaspshot 3089 generated yesterday and at startup, I still see that error:

Edit: it could be an old data from the JSON DB. I try to delete it and restart.
Edit2: seems OK finally (I suppressed the file from the main directory but not in the backup subdirectory).

[jlaur]

I just installed snaspshot 3089 generated yesterday and at startup, I still see that error:

Edit: it could be an old data from the JSON DB. I try to delete it and restart. Edit2: seems OK finally (I suppressed the file from the main directory but not in the backup subdirectory).

I'm wondering how that data was created, and with which version:

"createdOn": {
    "seconds": 1663660427,
    "nanos": 311625000
  }

That timestamp is 20.09.2022 09:53:47 CET (with DST), i.e. this morning. Current snapshot version:

openhab-core/bundles/org.openhab.core.auth.oauth2client/src/main/java/org/openhab/core/auth/oauth2client/internal/OAuthStoreHandlerImpl.java

Lines 251 to 253 in 4a84b80

	.registerTypeAdapter(Instant.class,
	(JsonSerializer<Instant>) (date, type,
	jsonSerializationContext) -> new JsonPrimitive(date.toString()))

uses Instant.toString() for serialization, which should generate something like 2022-09-20T07:53:47.311625Z.

Since you installed the snapshot yesterday and this JSON seems to have been generated today, I don't have a good feeling about this. Which binding do you use, and is it possible somehow to reproduce? EDIT: Okay, now I saw that it's homeconnect. Is that also current shapshot version?

[lolodomo]

Since you installed the snapshot yesterday and this JSON seems to have been generated today, I don't have a good feeling about this. Which binding do you use, and is it possible somehow to reproduce? EDIT: Okay, now I saw that it's homeconnect. Is that also current shapshot version?

Sorry, don't loose your time, I think there is no problem, it was my file from the previous version which was read. The new version has just been installed one hour ago (while the home-connect token was probably updated this morning by my old snapshot).
After removing all files containing oAuth2 tokens, restarting OH, checking my 2 bindings using oAuth2 work, and then restarting OH again, I see no errors.

[jlaur]

Sorry, don't loose your time, I think there is no problem, it was my file from the previous version which was read. The new version has just been installed one hour ago (while the home-connect token was probably updated this morning by my old snapshot).
After removing all files containing oAuth2 tokens, restarting OH, checking my 2 bindings using oAuth2 work, and then restarting OH again, I see no errors.

Okay, thanks. Still, I'm wondering how this was created, and if this scenario has to be supported also. Serialized tokens generated before #3066 shouldn't look like this, and they should also be correctly deserialized now. Tokens generated after this PR should also not look like this, and should also be correctly deserialized. Perhaps some permutation of pre/post #3066/#3083 vs. core/addons can cause this.

[lolodomo]

Here is how it looks now in the DB:

  "ecowatt:signals:monecowatt.AccessTokenResponse": {
    "class": "java.lang.String",
    "value": "{\n  \"accessToken\": \"xxx\",\n  \"tokenType\": \"Bearer\",\n  \"expiresIn\": 7200,\n  \"createdOn\": \"2022-09-20T18:24:22.923094Z\"\n}"
  },
...
  "homeconnect:api_bridge:bridge.AccessTokenResponse": {
    "class": "java.lang.String",
    "value": "{\n  \"accessToken\": \"yyy\",\n  \"tokenType\": \"Bearer\",\n  \"expiresIn\": 86400,\n  \"refreshToken\": \"zzz\",\n  \"scope\": \"Washer-Control Settings IdentifyAppliance Hood-Control Monitor WasherDryer-Control Dishwasher-Control Dryer-Control CleaningRobot-Control Oven-Control CoffeeMaker-Control\",\n  \"createdOn\": \"2022-09-20T18:26:24.357219Z\"\n}"
  },

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh4-0-0-snapshot-and-m1-google-tts-exception/145046/6