Investigate technical approach/improvements for Login

[mdconatser]

Document findings of approaches considered, and why they should be selected or excluded as we need this information in the TDD. Place findings in the documents as a draft, no need for extensive polishing within this task. Some content may be moved out later to the Programmers Guide.

Additionally, if implementation appears to be simple, developing a proof of concept (or locating an existing one built by someone else) would also be great for our next presentation.

[shaneknows]

Could be cool to allow for multiple email accounts to be linked and show last successful retrieval. Also finding a way to get gmail accounts working would be great. It sounded like the current IMAP setup didn't work with those

[JesterSe7en]

As requested by Andrew, I took a stab at it. Looks like to support gmail accounts, we need to use OAuth. Current implementation uses AUTH=PLAIN via login(). There are functions within enough_mail package that uses OAuth e.g. authenticateWithOAuth2(user, accessToken).

AFAIK, the accessToken parameter is granted by Google via Google Developers Console.

Generation of the Gmail API Credentials requires accessing something called the certificate fingerprint which is found in the keystore. Running cmd "keytool -keystore path-to-debug-or-production-keystore -list -v" requires the keystore password. I'm not sure who/how to create the keystore.

Source: https://stackoverflow.com/questions/36214968/how-to-get-access-token-using-gmail-api

[shaneknows]

I wonder how important this is to get working. We would have to bind the OAuth consent screen and credentials to an email account for support. Certainly doable, but I don't think any developer on this team would want to be on the receiving end of that

[shaneknows]

Think I should be able to check out this login stuff this week