search

smartdevicelink / sdl_java_suite

SmartDeviceLink libraries for Android, Java SE, and Java EE
BSD 3-Clause "New" or "Revised" License
186 stars 171 forks source link

Impartial or empty trusted list for multiplexing app #636

Closed Tnnnguyen closed 6 years ago

Tnnnguyen commented 6 years ago

We observe an unwanted behavior for multiplexing apps during cross apps validation. This is due to the current nature of the web service call result when an app is requesting for the trusted list: the successful returned list contains only the currently installed apps that are trusted.

For example:

  1. App A with package name com.sdl.appa and is the only installed multiplexing app App A requests the list, sending com.sdl.appa, it gets the empty list

  2. The Livio app with package name com.livio.sdl and is the only installed multiplexing app Livio app requests the list, sending com.livio.sdl, it gets com.livio.sdl

Subsequently, if a none trusted app is the only installed multiplexing app on the device, upon a successful request and download, its trusted list is empty and it cannot correctly validate other trusted apps that may be installed later.

Here is the flow:

1. App A is the only installed multiplexing app and is not on the trusted list:

In any case, an empty trusted list received from RouterServiceValidator.getTrustedList() at any time during a run of a multiplexing app does not make sense because there are trusted apps by default.

For test 1 above, we can work out the logic so App A gets the default trusted list in case the request result returns an empty list. However, for test 2 below, there is not a way for App A to correctly validate Spotify as Spotify is not on the default trusted list but was made trusted later, unless we either update the default trusted list or modify the behavior of the woprjr request result. @joeygrover do you have any comment on this?

2. App A is the only installed multiplexing app and is not on the trusted list:

joeygrover commented 6 years ago

The issue reported isn't correctly stated and the case explained is already handled, for that I am closing the issue.

When the router service connects and sends the SDL start intent, the SdlBroadcastReceiver calls the RouterServiceValidator to perform a trusted router service list query. Within this call, the RouterServiceValidator searches the device for all SDL enabled apps and creates a JSON object. Next, the RouterServiceValidator checks to make sure it wasn't flagged to force a redownload of a list or that the timeout hasn't been reached. If neither of those are true, it then makes sure that the previously generated list of SDL enabled apps on the device matches the one used in the previous query. If it does match, the callback will return and the cached list will be used. If the list of SDL enabled apps does not match the one cached from the earlier trusted router service query, it will trigger a redownload event that will then use a new, updated list. If the list is retrieved successfully, the new list of SDL apps installed will be cached as well. This covers the case of apps being installed/deleted between connected sessions. If you find an error with this process not working as designed please raise a new issue.

Finally, an empty list does make sense. While the library includes default trusted apps, those are only known to be trusted at the time of library release. There can come a time when those packages are no longer trusted and must not be used. Therefore, if they are not trusted they will not be in the list, and if no other app is trusted an empty list will be returned.

Tnnnguyen commented 6 years ago

I agree this issue should not be flagged as bug but rather enhance. And the case explained is not handled please read the above steps carefully, more detailed steps below. The current code ensures that, in this flow, the app that is installed later has the most updated list of SDL enabled apps (thus itself in the trusted list if it's trusted) while the firstly installed app, without any forced download, will only have an empty trusted list.

Preconditions: No SDL enabled multiplexing app installed in device

Steps:

  1. Install app A, multiplexing and not trusted, with package name com.sdl.appa
  2. App A gets the list of SDL enabled apps from device, it gets com.sdl.appa
  3. App A makes the request for the trusted list, sending com.sdl.appa
  4. App A gets the empty list back, it saves it to shared preference
  5. Install app B, multiplexing and trusted, with package name com.livio.sdl
  6. App B gets the list of SDL enabled apps from device, it gets com.sdl.appa, com.livio.sdl
  7. App B makes the request for the trusted list, sending com.sdl.appa, com.livio.sdl
  8. App B gets the response from woprjr server that contains com.livio.sdl and saves it to shared preference
  9. At this point if app A attempts to validate app B, it will not get a correct result as its trusted list is still empty.
joeygrover commented 6 years ago

This is not correct.

All apps perform the logic stated previously for every connection made. Every app for every connection checks to see if any SDL enabled apps were installed, deleted, or updated. If true for any of those, it will redownload an updated trusted app list. Each app contains their own list of trusted apps and previously scanned apps that were used to request the trusted app list.

Locking this conversation as the logic is misunderstood and should be cleared up before continuing to discuss here.

Tnnnguyen commented 6 years ago

At step 9. please state what the trusted list is for App A and App B.

Base on what I see: App A gets an empty list App B gets com.livio.sdl

Every app for every connection checks to see if any SDL enabled apps were installed, deleted, or updated

Correct, but app A is not making a connection at this point and does not redownload. It's only for app B that gets the latest SDL enabled app installed as in step 6.

joeygrover commented 6 years ago

App A will have an empty list at the exact time of App B's installation, however, the list itself is only needed when there is a connection. Therefore, there is never a time when the list isn't updated and it needs to be and there is no issue. Creating a network call each time an app is installed, deleted, or updated would be incredibly irresponsible on the our part, especially if the user doesn't connect to a module.