Skip to content

Change the Authentication flow, and run it at the very beginning of extension's Life-Cycle [LC] #11

@kdidenko

Description

@kdidenko

Currently, the OAuth2 process is only started after DOMContentLoaded event emitted for TabSaver's BrowserAction dialog box, which is completely not the proper optimization (architecture) approach, taking into consideration TabSaver's infrastructure and it's Life-Cycle.

Then, next to the Google Analytics [GA] code initialization, it is asynchronously(!) trying to request the Google API access_token for further retrieve the basic user info. Requesting the access_token causes the user to Sign in to his Chrome Account, which has a serious impact on the data extension is working with.

Currently, there is no interaction implemented between main TabSaver's functionality and OAuth2 process activities, which must be changed in order to make both modules properly handle the authentication flow and private data.

Since now it is required to coordinate any synced extension's data updates (like modifying any saved user Session or even storing current one) according to the authentication status, the best solution will be to move all initial OAuth2 functionality earlier by the extension's Life-Cycle, and the best place will be to put it into the BackgroundPage

  • 1. Addapt and attach the OAuth2 functionality from the identity.js along with existing Background Page script stub
  • 2. Refactor the identity.js code for requesting the access token from a not interactive mode immediatly after BackgroundPage module have been loaded (theoretically on the browser start; //TODO: find it out!)
    • 2.1. Find reliable information regarding the extensions Life-Cycle
  • 3. tabsaver:OAuth2.client.getAccessToken( {interactive: false}, _see_next_steps__callback );
  • On Success: store the access_token and corresponding UserDetails in a secure place later accessible from the main TabSaver's dialog (BrowserAction)
  • On fail: store an empty UserDetails object at the same place containing flag notifying that a background, non-interactive session getting access_token failed, so the extension will start this Authentication flow over, but using interactive mode this time.
  • 4. [Further]: make sure that both BackgroundPage's and BrowserAction's identity.js instances may easely exchange access_token in realtime. Add this functionality, if NOT!

See related issues:

#1 Add verification if user is currently logged in to his Google account
#2 Restructure the source code

Metadata

Metadata

Assignees

Labels

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions