You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could be implemented as a command, like cludo user, that, after initial authentication, lists some details from the server-side config that might be useful to the end user, like the targets that they are configured for, what public keys the server knows about, etc.
Additional feature/option for the target use case, would be to pass a useful error back from the server to the client, when no valid target is defined that lists which targets are available.
The text was updated successfully, but these errors were encountered:
I could see a command like this being useful, but a couple of thoughts:
targets that they are configured for,
I'd almost want this to be called cludo targets
what public keys the server knows about, etc.
I don't know that we want users to be able to list the public keys from the server. Users to keys is 1:1, so listing the public keys is basically the same as listing all other users. Seems like an admin thing instead.
For the public keys, I suppose I was thinking about the point, when a user has more of an identity, like sean is an actual user with a list of public keys (maybe including some from github), but you are correct that the current model does not really allow for this.
This could be implemented as a command, like
cludo user
, that, after initial authentication, lists some details from the server-side config that might be useful to the end user, like the targets that they are configured for, what public keys the server knows about, etc.Additional feature/option for the target use case, would be to pass a useful error back from the server to the client, when no valid target is defined that lists which targets are available.
The text was updated successfully, but these errors were encountered: