Notes - Scope Extensions Chat (Mar 22, 2023)

7 views
Skip to first unread message

Dan Murphy

unread,
Mar 22, 2023, 2:38:46 PM3/22/23
to Dan Murphy, Lu Huang, lu...@microsoft.com, Dibyajyoti Pal, pwa-dev

Attendees: Dan Murphy Lu Huang


Notes

  • Previously was in os integration

  • moved to install flow

  • requirements

    • take a field from manifest

    • use that to fetch things from other origin w/o CORS or anything like that

      • can use simple url fetcher

    • Then, that stores information in the web app

    • that info is used for other stuff.

    • it might fail to fetch - should we retry sometimes? maybe on launch?

  • Install general flow

    • get information to build a WebAppInstallInfo

    • Give that to finalizer to store into DB / do os integration

  • difficult part - hitting network - kind of a new 'dependency' similar to web_contents dependency

  • where do we put this dependency

  • open question

    • does this hit the network cache?

  • Where should this live?

    • os integration?

      • no os integration fetches urls, BUT it would technically work

    • inside install command?

      • we have to add to ALL install commands

        • not BAD but could be behind something else

      • finalizer would consider scope extensions "confirmed"

      • better for testing scope extensions - don't need to tell 

      • advantage: would we ever want to bypass the 'confirmation' of scope extensions? If so, commands allow us to just not do that.

        • OR - do we ALWAYS want to force this.

    • install finalizer? - 

      • could happen at same time as saving data? or before saving data?

      • webappinstallinfo is same as before - has the scope-extensions but not any confirmation from other origins

      • Finalizer does a bunch of things in a row

        • Saves data to database (tranforms installinfo to proto)

        • Saves data to disk (icons)

          • used to save translations?

        • (new) fetch 

        • After those are done, runs OS integration

        • done

      • only have to do this in one place - no need to affect commands at all.

      • con for testing - this would mean all installs that involve this would need to fake this

        • But we can just default to a 'confirm all' fake.

    • use a new command that is scheduled after install 

  • what about showing scope extensions in dialog

    • option 1: we can just not bother chekcing at that stage, because worst case, they aren't confirmed, and not worse for user security-wise

    • option 2: we could just call the same system to confirm for the dialog, and not save or anything - just abort the install command early.

      • we would be calling again later, but that should be cached by the network, so should be fast.

  • What should the structure look like?

  • Dan's proposal

    • Code health opportunity is to remove finalizer, move all that logic to a WebAppInstallJob (similar to uninstall job)

    • Add step to finalizer, similar to downloading icons, to 'confirm' the extensions

      • would need to ALWAYS do this, even if already installed by another source.

      • Can happen before we save to DB, or in parallel & then save results, whatever

      • just happens before OS integration

    • The logic for fetching this sits in a manager living on WebAppProvider - SEManager

      • FakeSEManager that is constructed in the FakeWebAppPRovider that would auto-confirm everything

      • OR call this this _Factory, have that sit on the WebAppProvider

    • Unit tests will auto-work, as they will auto-confirm all scope extensions

    • to test denial, you can have that Fake_Factory change it's behavior - you call this in the test

    • Want to add integration testing, which makes sure every single type of install will work for every case we're testing

      • install w/ SE, confirm that UX behaves correctly

      • install w/ SE but NOT confirmed, confirm that UX behaves correctly.

      • hurdle: how do we configure the test sites here - we should have multiple origins available, to investigate.

    • confirmation dialog

      • both options above work

        • option 1: we can just not bother chekcing at that stage, because worst case, they aren't confirmed, and not worse for user security-wise

        • option 2: we could just call the same system to confirm for the dialog, and not save or anything - just abort the install command early.

          • we would be calling again later, but that should be cached by the network, so should be fast.

    • Create a command to 'fix' unconfirmed too - maybe on launch we kick that off

      • will have a similar thing with icons


Action items

  • Follow up about inviting MSFT folks to dPWA discussion session

  • Follow up with Alan about this design & get back to Lu



Reply all
Reply to author
Forward
0 new messages