Introduce hex_auth module#178
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.
|
@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. |
I think we can do that if we make that clear in the docs and maybe scoping under a I am still am bit hesitant at keeping it so close to how Hex and Rebar3 works with environment variables and config resolution. Would every CLI client want to do it the same way? |
That sounds like a reasonable name.
Let's not do env variables. In the case of rebar, that would be better handled in the |
maennchen
force-pushed
the
jm/hex_auth
branch
2 times, most recently
from
4321c4e to
e56c3db
Compare
wojtekmach
left a comment
wojtekmach
left a comment
There was a problem hiding this comment.
This looks solid and well tested, I left some comments below.
maennchen
force-pushed
the
jm/hex_auth
branch
2 times, most recently
from
cb231fa to
b8cea90
Compare
|
One thing we have think about this approach, where we model hex_core very closely to how Hex/Rebar3 currently works. What happens when I want to add a new feature to Hex, for example meta organizations/repos that can contain sub repos. Rebar3 might lag behind adding this feature or may not want to add it all, so now |
|
@ericmj I believe that we can deal with this when we are making changes as long as we consider rebar when making them. We can choose to build it in a way where there's no trouble not implementing a new feature, make it conditional behind a flag etc. Worst case, we can choose to fork the module. |
maennchen
force-pushed
the
jm/hex_auth
branch
2 times, most recently
from
e13da1b to
c4c38cc
Compare
| {"cmd", ["/c", "start", "", UrlStr]} | ||
| end, | ||
| Port = open_port({spawn_executable, os:find_executable(Cmd)}, [{args, Args}]), | ||
| port_close(Port), |
There was a problem hiding this comment.
Should we immediately close here? That's not how we do it in hex, we just let the OS clean it up. I am afraid this could race since open_port is async afaik.
Add a high-level function that handles the complete OAuth device authorization flow: initiating authorization, prompting the user, and polling for token completion. - Add oauth_tokens/0 and device_auth_error/0 types - Handle slow_down, authorization_pending, expired_token, and access_denied responses during polling
Add config options for hex_cli_auth authentication handling: - trusted: whether the repo connection is trusted for auth_key usage - oauth_exchange: whether to exchange api_key/auth_key for OAuth tokens - oauth_exchange_url: optional custom URL for OAuth token exchange
Provides callback-based authentication for build tools (rebar3, Mix) with shared auth logic and customizable prompting/persistence. Features: - with_api/4,5 and with_repo/3,4 wrappers for authenticated requests - resolve_api_auth/3 and resolve_repo_auth/2 for credential resolution - Auth resolution order: config, per-repo keys, parent repo, OAuth - OAuth token exchange via client_credentials grant - Automatic token refresh when expired - OTP/TOTP prompt handling with retry logic - Device auth flow for interactive authentication - Support for trusted/untrusted repo connections Includes comprehensive test suite covering: - API and repo auth resolution - Trusted vs untrusted scenarios - OAuth token exchange (new, valid, expired) - OTP prompts and retries - Token refresh on 401 - Device auth flow
Instead of passing callbacks as a separate argument to each hex_cli_auth function, they now live under the `cli_auth_callbacks` key in the config map. This reduces function arity and gives callers a single place to configure hex_core.
|
Thank you! 💜 |
3 participants
Base Module organizing Repo / API Auth Management.
This PR is WIP. I'm exploring how it could look.
Implementation PRs:
hex_authmodule hex#1143