search

cheshire137 / gh-notifications-snoozer

Lists and filters and snoozing pull requests, oh my! This is an app for managing your notifications on GitHub by way of filtering issues and pull requests that are of interest to you.
MIT License
15 stars 10 forks source link

Use keytar for GitHub access token storage #102

Closed cheshire137 closed 7 years ago

cheshire137 commented 7 years ago

Fixes #52 by storing the GitHub access token in secure storage based on the operating system, instead of in a plain JSON file.

/cc @summasmiff @probablycorey

cheshire137 commented 7 years ago

Is there a reason we're still using the token rather than a more standard username + pw for this?

The token is preferable to requiring the user to give us their user name and password. If we had their user name and password, we could make as many tokens as we wanted, as well as do other things the user doesn't want to happen. The token limits the scope of what the app can do.

If we could do GitHub OAuth, that would be preferable to a token the user manually created for us, though. The hairiness with OAuth is the fact that this is a desktop app but is also like a web app. There are two ways we could do OAuth: implicit grant flow and authorization code flow.

Authorization code flow requires we safely store the client secret for the app. Normally in a desktop app that wouldn't be a problem, but the end user can actually get at all the contents and code of an Electron app. We can't store the client secret in the keychain with keytar, either, since the user can read those values in plain text.

Implicit grant flow is what's normally used with web apps that can't store a client secret. The problem with using it in an Electron app is that implicit grant flow requires a URL to redirect to. We could have the app spin up a proxy server at a particular port on localhost and then have GitHub OAuth redirect to that for us to be able to grab the access token. I think eventually we'll do this. Requiring the user to create a personal access token on GitHub was just our quick-n-dirty way of starting to use the GitHub API without the hassle of setting up a proxy server so we could do proper implicit grant OAuth.

See: http://oauthlib.readthedocs.io/en/latest/oauth2/grants/implicit.html and http://stackoverflow.com/questions/16321455/what-is-the-difference-between-the-2-workflows-when-to-use-authorization-code-f

summasmiff commented 7 years ago

Thanks, that was more than I expected. I hadn't thought of the fact that we have no place to store a client secret. Having to create a proxy server also sounds like a big hassle. It's clear that having Keytar store the token is the best situation for now, both in security and ease of use.