Replies: 3 comments 2 replies
-
Thanks for this write-up @tonylee80 . Would love suggestions and thoughts on this, as I write out the steps I’m taking towards completing this, which will turn into incremental tasks to completing the feature of multiple FHIR server connections on the CLI. @codyebberson we spoke briefly on this today, will like to start creating the tasks associated with each step towards completion.
|
Beta Was this translation helpful? Give feedback.
-
Original recommendations:
Alternate recommendation:
|
Beta Was this translation helpful? Give feedback.
-
Following up on this, when a user runs This feature should streamline the process and improve user experience, reducing the extra step for manual logins every time a profile is created. Also, it keeps the process aligned with the principle of maintaining an active and valid authentication token per profile in the CLI context. Looking forward to hearing thoughts about this |
Beta Was this translation helpful? Give feedback.
-
RFC: Auth SDK/CLI -
Status: Draft
Problem
The usage of Medplum CLI commands with options to specify auth flows can often become verbose and challenging to read.
medplum bulk export -e Group/all --base-url https://sandbox.bcda.cms.gov --fhir-url-path api/v2/ --token-url https://sandbox.bcda.cms.gov/auth/token --client-id {{BCDA Client ID}} --client-secret {{BCDA Client Secret}}
To support different authentication types, it is necessary to add additional options such as grant type, client assertion type, scopes, redirect URI, and code.
The authentication types are:
Goals
The following goals should be achieved with the proposed changes:
Proposed Changes
Medplum SDK
The MedplumClient has become large and complex, with approximately 3,000 lines of code. To improve maintainability and readability, break down the client into logical components.
/admin
and/auth
.@medplum/client
- ExtractMedplumClient
and directly related utilities fromcore
Medplum CLI
CLI: Add a global option
--auth-type
to explicitly specify the type of authorization used.authType
as an option.Profiles (config options?)
Replaces the need to enter several command line options
Stores command line options.
Manage multiple client accounts and FHIR servers.
medplum profile set <profileName> <property> <value>
: Sets the specified profile with associated options.medplum profile unset <profileName> <property>
: Unset the specified profile property.medplum profile delete <profileName>
: Deletes the specified profile and logs out profile if it’s being usemedplum profile list
: Lists all available profiles.medplum profile describe <profileName>
: Describes the details of a specific profile.medplum login --profile <profileName>
: Logs in using the specified profile.medplum whoami
: Displays the details of the current logged-in and optional profile.medplum login with profiles
Storage: Modify the
~/.medplum/credentials
file to include a new property called "profiles."Questions
Should profile be required?
What happens if the profile is not specified?
Is there a default profile?
Benefits of a default profile
No default
-Encourage users to create profiles.
Would an interactive CLI tool be helpful?
Create a profile
Login (inspired by Github CLI)
Should profiles considered to be only used for auth/global options? Could profiles be flexible enough for non auth use cases?
References
Medplum SDK enhancements to determine Auth and Client types #2191
CLI Profiles: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles
Beta Was this translation helpful? Give feedback.
All reactions