[full disclosure, I've been involved in this as a gsoc mentor; moving discussion to public list.]
These are the two main sticking points, IMO. Quoth Demetrius Iatrakis <demetrius.iatra...@gmail.com>: > Only the device and refresh flows are supported. There is an > implementation of the authorization code flow (tested on macOS) here: > https://github.com/Mitsos101/plan9port/pull/1. However, it is not > included in the module as there is no good browser to plumb the URL > to. First off, for those following along at home, device flow is a browserless way of using oauth, but providers appear to often limit it beyond the point usefulness, so we'd need to find a way to make factotum communicate with a browser in order to get the tokens in. Sadly, even the netsurf port isn't enough browser to run Google's oauth login page. So, the question here becomes how to glue in a helper program between factotum and oauth. There are a few options -- using the plumber in both directions will work, but it's a bit gross -- and involves broadcasting the tokens. The only real alternative I can imagine is having a special file that factotum calls out to in the namespace, something like: /rc/bin/oauth-helper: #!/bin/rc ssh user@unix invoke-browser-and-get-token-helper > Refresh tokens are not saved to persistent storage when factotum > exits. The user must provide consent every time factotum is restarted. For this, the tokens should probably be persisted into secstore -- but there are some security implications in giving factotum long-lived access to the persistent key store. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M4a39ddac185f3a4de8c91e0a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
