Conversation
ericmj
left a comment
ericmj
left a comment
There was a problem hiding this comment.
I am not sure this fits in hex_core. It's very specific to implementing OAuth for a CLI, specifically to how Hex and rebar3 work with config resolution order and environment variables. hex_core should be more generic than that, for example you should be able to use it in web services, like hexdocs or hexdiff, and this wouldn't fit for that.
I understand we want to avoid auth logic between Hex and rebar3 if it's mostly shared, but I am not sure it fits in hex_core.
| -define(EXPIRY_BUFFER_SECONDS, 300). | ||
|
|
||
| %% Default polling interval (seconds) | ||
| -define(DEFAULT_POLL_INTERVAL, 5). |
| <<"interval">> := Interval | ||
| } = DeviceResponse, | ||
| io:format("Open ~ts in your browser and enter code: ~ts~n", [VerificationUri, UserCode]), | ||
| open_browser(VerificationUri), |
There was a problem hiding this comment.
Do we want force users to open a browser? What if we are in an environment without browsers or the CLI only wants to provide the link.
| %% Resolves credentials in this order: | ||
| %% <ol> | ||
| %% <li>`HEX_API_KEY' env var</li> | ||
| %% <li>Per-repo `api_key' from config (with optional OAuth exchange for hex.pm)</li> |
There was a problem hiding this comment.
Is this for rebar? In hex we don't have API keys per repository.
|
@ericmj I'm aware that this is very much scoped towards CLIs. Is there a reason to not include a CLI only module into I would love to be able to reuse the auth logic that is frankly quite complicated between our clients. That way we can minimize maintenance work, are able to roll out features more quickly and also ensure better compatibility. |
2 participants
Base Module organizing Repo / API Auth Management.
This PR is WIP. I'm exploring how it could look.
Implementation PRs:
hex_authmodule hex#1143rebar3_hex- Not yet started.