Implement credential nicknames #34
Conversation
These are purely labels for users' convenience. Nicknames are editable internally, but this capacity is not yet exposed to users. The nickname is now included in the downloadable credential file, but will currently be ignored by the client.
|
Originally I wanted to let users change credential nicknames whenever they want, since nothing on the server side cares what they are. However, it has since occurred to me that there is no good way to ensure propagation of an updated name to the users client configuration(s). It may therefore be better to just never support changing these. |
There was a problem hiding this comment.
Why are nicknames included in downloaded bundles? It seems to me that they're purely UI for the admin website, and not used in any communication, so I'm not sure they need to be downloaded. If they don't need to be downloaded, then changes don't need to propagate, so they can be edited, which is nice.
scimma_admin/hopskotch_auth/templates/hopskotch_auth/edit_credential.html
Outdated
Show resolved
Hide resolved
My plan was that we would use them for disambiguation when a user has multiple credentials which are valid for the same Kafka host, as we've been discussing on the multiple credential configuration document. We don't have to do that, of course, but if the point is to give the user an easier way to think about/refer to them, that seems like the main other place where it would be relevant. |
|
I'm not sure about assigning addt'l meaning to the nicknames quite yet, beyond just a description to users on the website. It could get confusing very quickly, with the username, password, nickname, and potentially a "profile name" in the hop config (if that's how the "multi-cred" feature gets implemented in hop). It may be OK to keep this code around for experimentation, but my vote for the prod roll-out would be to start with "less is more" keep nicknames website-only (e.g., I like how https://github.com/settings/tokens handles their PATs)? (because once a feature is out, it will be difficult to remove or change if if we change our minds). |
|
I was imagining that this would obviate the need for a 'profile name' by taking its place. I was also trying to get this integrated in order to have a foundation on which to build the multi-credential stuff on the client side, which won't really work very well without it (unless I'm missing a good alternative). |
These are purely labels for users' convenience.
Nicknames are editable internally, but this capacity is not yet exposed to users.
The nickname is now included in the downloadable credential file, but will currently be ignored by the client.