New method to get installation id

dhidalgofadrique commented 1 month ago

Message type: GET_INSTALLATION_ID

Originator: Web

Description

In order to accomplish the new datamob functionality for VIVO (APPS-8195, PRD) we need to implement a new bridge method to get the installation id.

This new method will return the sanitized installation id (letting the installation id for internal use). This sanitized id has the same format in both platforms: a 32 characters hex string (e.g: 366b8d9bab7241629ca3a9fedc5fe9ce)

This sanitized id is the same set by the app into the web cookies and into the API-Hightway context and, therefore, the one used in backend

Differences between iOS/Android (if any)

N/A

Payload definition

Request Payload
No payload required

Examples:

{"type": "GET_INSTALLATION_ID", "id": "get-installation-id-1"}

Response Payload
The payload will return the sanitized installation id

installationId: string;

Examples:

{"type": "GET_INSTALLATION_ID", "id": "get-installation-id-1", "payload": {"installationId": "366b8d9bab7241629ca3a9fedc5fe9ce"}}

Possible error cases

N/A

ieduardogf commented 1 month ago

Sounds good.

dzayas commented 1 month ago

Nothing to add here, for us it is perfect.

atabel commented 1 month ago

I'd change the message name to GET_SANITIZED_INSTALLATION_ID or something similar, as the returned value won't be the installationId, but the sanitized version of it, which is different to the raw version injected as the installation-id cookie in novum webviews.

dhidalgofadrique commented 1 month ago

I'd change the message name to GET_SANITIZED_INSTALLATION_ID or something similar, as the returned value won't be the installationId, but the sanitized version of it, which is different to the raw version injected as the installation-id cookie in novum webviews.

Sounds good to me but my concern is whether this "SANITIZED" might confuse the client using it. Maybe it could specify what a sanitzed id is in the method doc (I've changed the issue description with this info):;

This sanitized id has the same format in both platforms: a 32 characters hex string (e.g: 366b8d9bab7241629ca3a9fedc5fe9ce)

dzayas commented 1 month ago

I'd change the message name to GET_SANITIZED_INSTALLATION_ID or something similar, as the returned value won't be the installationId, but the sanitized version of it, which is different to the raw version injected as the installation-id cookie in novum webviews.

Sounds good to me but my concern is whether this "SANITIZED" might confuse the client using it. Maybe it could specify what a sanitzed id is in the method doc (I've changed the issue description with this info):;

This sanitized id has the same format in both platforms: a 32 characters hex string (e.g: 366b8d9bab7241629ca3a9fedc5fe9ce)

Beyond the naming, I think that we need to be coherent in the whole App, if the installation-id that we are using in webapp is not the same that the one returned here, it could be a problem.

This installation-id will be used to referenciate to a given app installation from the APPs further from the backends or frontend. So, the problem is not that in both platforms is the same, the goal is that the backend should be able to identify the app installation. It will be used for example to deliver pushes to a given installation.

Which "installation-id is the one that the backend has in the session information?

Because of the use case of identify device for notifications, I think that @kydorn could have feedback here.

dhidalgofadrique commented 1 month ago

I'd change the message name to GET_SANITIZED_INSTALLATION_ID or something similar, as the returned value won't be the installationId, but the sanitized version of it, which is different to the raw version injected as the installation-id cookie in novum webviews.

Sounds good to me but my concern is whether this "SANITIZED" might confuse the client using it. Maybe it could specify what a sanitzed id is in the method doc (I've changed the issue description with this info):; This sanitized id has the same format in both platforms: a 32 characters hex string (e.g: 366b8d9bab7241629ca3a9fedc5fe9ce)

Beyond the naming, I think that we need to be coherent in the whole App, if the installation-id that we are using in webapp is not the same that the one returned here, it could be a problem.

This installation-id will be used to referenciate to a given app installation from the APPs further from the backends or frontend. So, the problem is not that in both platforms is the same, the goal is that the backend should be able to identify the app installation. It will be used for example to deliver pushes to a given installation.

Which "installation-id is the one that the backend has in the session information?

Because of the use case of identify device for notifications, I think that @kydorn could have feedback here.

Good point @dzayas. After checking it in iOS and Android, these are the values managed:

Android: It uses the sanitized installation id (lowercased 32 characters string) in both cookies and the API-Highway context (so it's the value managed by backend)
iOS: It uses the sanitized installation id (lowercased 32 characters string) in the API-Highway context and the installation id (uppercased 32 characters string) so it's the valuemanaged by backend

So I think the use of the sanitized id is the right option due it's the same value used in cookies and API-Highway and every installation id will be the same in any context

dhidalgofadrique commented 1 month ago

@atabel due to the returned value of this new method is the same value used in web installation-id cookie and the API-Highway context, I think the GET_INSTALLATION_ID message name is ok, wdyt?

atabel commented 4 weeks ago

LGTM, web ticket: https://jira.tid.es/browse/WEB-2086

kydorn commented 3 weeks ago

Sorry for the delay, but yes. We should only be using the sanitized installation id.

Telefonica / webview-bridge