Open wenzowski opened 12 years ago
Hi Alex,
I agree it's not the cleanest way to do it and I'm definitely open to alternative suggestions, but I don't want to add anymore gem dependencies other than 'crack'. I don't mind if we add alternative ways to get the refresh token, but they must be alternatives, not the default and I'd rather output an error message saying something like, "you need to install the launchy gem first" when someone tries to use it, rather than including another gem dependency.
I have quite a few local changes which I am almost ready to push as well, I finally got around to taking a proper look at all the changes you added last week. There's still a couple of problems with the SecretData class that I've noticed, but I'm fixing it at the moment. I can only spend another hour on this today, so I'll push my changes back up shortly.
Regarding problems with SecretData, a PR to https://github.com/wenzowski/secret_data would be greatly appreciated...especially if you decide to accept #11 (see 57a403e
).
I'm definitely against adding any runtime dependencies wherever possible, and have been keeping this in mind as I've been going. For instance, current wip for #12 is inheriting Rails || ANSI || Stdlib logger.
Perhaps I should package this functionality as an additional gem?
Btw, I'm not sure the rake task actually works in current release, but don't remember the issue I had, and haven't gotten that far in my own coverage yet.
What about using a Service account (instead of web appllication) as an option?
Right now, getting a refresh token is kinda clunky.
What about including a small padrino app in development environment to generate a link to the correct auth url (read_only, read_write, or full_control) and display the response's auth_code?
Perhaps even open the browser automatically with launchy?
On success, the padrino app could provide a link to a
response with a valid config.
Whaddayathink?