Automatically Retry the CLI Command upon Session Unlocking #240
Comments
|
@emmacasolin please update the MR description with your plan as you proceed in this issue too. |
|
Remember to link the MRs/PRs. |
|
I'm currently mocking up a diagram of the retry loop in ASCII flow before I make it in plantuml but I've got a couple questions about the root password input preference system. I'm assuming "take from the parameter" would be checking for an argument like |
|
Here's a mockup of the CLI command retry loop: I'm still not sure what the optional environment variable is so I've left it as a self request from the client for now. I was struggling to show that the password request options are tried one after the other in separate loops of the retry loop (as opposed to one after the other in the same loop of the retry loop) so I might try to find a way to make that clearer, but other than these two issues I think this diagram is ready to be remade in plantuml. |
|
|
Ah ok, makes sense. How about having something like this: And then I'll make a separate flow diagram for the input options |
|
Unfortunately plantuml's flow diagram functionality is quite limited so I had to make the input flow diagram using another website in order to get it the way I wanted. The top one is a sequence diagram of the loop and the bottom one is a flow diagram of the root password input preference system. |
|
I've created an MR for this issue here - still need to update the description both there and here (will do first thing Wednesday) and then I'll start planning out what needs to be done. |
|
From a CLI perspective then, am I right in thinking it's something like this: |
|
Yeah that looks right from my understanding of it
|
|
After a review and merge of sessions retry, please work with @joshuakarp to clean up documentation too as this should be pushed into reference docs. We will need to come up with a proper structure for our reference docs. |
|
I believe this can be closed once the Gitlab MR is merged. There's been some changes to this process there. @emmacasolin should also look into writing some documentation/tidying up diagrams on this new retry process (as per the latest discussions here https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/213#note_728972375) |
|
Merged. @emmacasolin has documentation pending to be reviewed in MatrixAI/Polykey-Docs#4. |
Specification
MR: https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/213
When a user executes a CLI command without having been authenticated previously the command sent to the agent will be rejected as "unauthorised". Instead of throwing an exception here, we can prompt the user for the root password in order to authenticate the client. Provided we know that the user is not a machine (which would classify as unattended usage), we can continue to prompt the user for the root password until the correct password is supplied and they can be authenticated. We will refer to this loop as the CLI Authentication Retry Loop (CARL):
Before we can activate the CARL and begin to prompt the user for the password, we need to ensure that the command is not unattended (since we need to account for both machine and human usage). We can do this by checking if either of the two environment variables
PK_PASSWORD(for the root password) orPK_TOKEN(for the session token) are set (since the purpose of setting these is for unattended usage). Before we activate the CARL we also need to check that the first exception we receive back from the agent isErrorClientAuthMissing(thrown when the call has no authorisation metadata), since we only want to retry the call if the client is not authenticated, rather than if the authentication metadata is invalid or if there is some other error on the agent side. Once we are inside the loop we only want to restart it if the error we receive back from the agent isErrorClientAuthDenied(thrown when the authorisation metadata is invalid), since this means that the password supplied by the user was invalid and we want to prompt them to try again. The user can always manually exit the loop from the terminal if they have forgotten their password or otherwise wish to cancel the call.Since we want this loop to be as automated as possible, prompting the user to enter their password should be our last option. As such, the retry function can be optionally called with an initial metadata object that is constructed during parsing of command line options for each call. This metadata is encoded using the first set value from the following in order:
PK_PASSWORDenvironment variablePK_TOKENenvironment variableIn this way, if the password is already supplied it will be made use of. Once we enter the CARL we know that all other options have been exhausted and we have to prompt the user for the password.
Additional context
Tasks
src/binlocationtests/bin(these are singular tests, you can pick any CLI command for this):bin/utilsand all relevant commandsThe text was updated successfully, but these errors were encountered: