Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
5 tasks
kdidenko opened this issue Aug 26, 2017 · 0 comments
Assignees
Labels
documentation feature improvement existing features and attributes improving / extending activities task

Comments

@kdidenko
Copy link
Owner

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

@kdidenko kdidenko added documentation improvement existing features and attributes improving / extending activities feature task labels Aug 26, 2017
@kdidenko kdidenko added this to the Version 1.1.15 release milestone Aug 26, 2017
@kdidenko kdidenko self-assigned this Aug 26, 2017
@kdidenko kdidenko added this to To do in [TS] Infrastructure via automation Feb 16, 2018
@kdidenko kdidenko added this to To do in [TS] Authentication via automation Feb 16, 2018
@kdidenko kdidenko added this to To do in [TS] Migration via automation Feb 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation feature improvement existing features and attributes improving / extending activities task
Projects
TabSaver
Awaiting triage
[TS] Migration
  
To do
Development

No branches or pull requests

1 participant