[Workbench] Regular user should view VMs and repositories, and manage tokens and SSH keys, on an approachable "access" page instead of relying on the generic "view/edit items" pages.
One page, four content areas (3 small "view only" plus one that lets you add/remove SSH keys)Show:
- VMs I can log in to: show hostname, login name, last login (if available)
- Note about "See "setting up SSH access" first"?
- Repositories I can access: name, is_writable, fetch or push-url (depending on whether it is writable)
- Note about "See "setting up SSH access" first"?
- Current API token
- Show the copy-and-paste section (currently shown on the Help tab of the "manage API tokens" page)
- Show my existing SSH keys (filter by key_type=="SSH")
- If no existing SSH keys, explain why you should add one (in order to access shell VM and repository)
- "Add SSH key" button
- modal with form, like "setup user"
- always set key_type to SSH
- error handling is important (many people will provide bogus keys!) -- e.g., show error message in modal footer
- Link to "learn more" (opens in a new tab) inside the modal as well
- "Setting up SSH access" section with the information that currently appears at
- "Edit SSH key" is sort of nice, but not a big priority: it's not much more convenient than deleting an existing key and adding a new one.
In each section, a "Learn more" link opens a new tab with the appropriate page of doc.arvados.orgUpdate nav links:
- Add "Account settings" item, in the email address dropdown, linking to this new page
- Make generic "show VMs, authorized_keys, API tokens" links show up only for admins, in the gear menu (like the Users item is now)
- If this means the gear menu is now empty for non-admins, then don't even show the gear menu for non-admin users!
- Filter ssh keys and api tokens by
owner_uuid == current_user.uuidso this page works nicely for admins too.
- Repo usage is based on permissions, so admins will have push (write) access to all of them.
- For VMs, only show access based on can_login links with a username. This means admins will only see the VMs on which they have explicitly been given user accounts.
|API tokens||SSH keys|
#15 Updated by Radhika Chippada about 6 years ago
- Status changed from New to In Progress
Branch 3193-manage-account is ready for review.
- Is the logic in apps/workbench/app/controllers/users_controller.rb -> manage_account method good to get the current user's repositories, virtual machines, and ssh keys?
- The rest of the UI code can verified by testing the UI page, than reading through the code.
- Please let me know if the text in the new window needs to be improved
- Currently, I am pointing to the SSH documentation in all sections. Do we want to point to any other pages for VM and Repositories sections?
#16 Updated by Peter Amstutz about 6 years ago
- This is good, I like the two-column layout
- The "Virtual Machines" section doesn't show the last log in time, as specified in the story
- The "Repositories" table is empty for me logged in as firstname.lastname@example.org, but I was expecting it to show the "peter" repository
- The "for more information" link on the "Repositories" panel should probably link to the writing a crunch script tutorial because that goes into the most detail about using Git with Arvados
- According to conversation with Ward yesterday, users should be able to create new repositories. So there needs to be a "Create new repository" button under "Repositories"
- Can we change the text in the "Current token" box to be more compact:
export ARVADOS_API_TOKEN=5alsxxxxxoxywl7layyyy3tbttyb1rzzzz2cg67g1l export ARVADOS_API_HOST=qr1hi.arvadosapi.com unset ARVADOS_API_HOST_INSECURE
- Maybe the "Setting up ssh access" section should be its own box, instead of part of the "ssh keys" box? Or perhaps it should be part of the "virtual machines" box (instead of "SSH keys") because the purpose of setting up ssh is to log in to a virtual machine.
- There's no breadcrumb in the nav bar to let you know you are in the "Manage account" page
- Confirmation dialog "Really delete key" should have a question mark "Really delete key?"
- The login name (and actually all the upper right menus) should probably have a caret marks next to them (i.e. a downward pointing triangle, similar to "Projects") and/or hover effects to indicate that they are clickable.
- http://doc.arvados.org/user/reference/api-tokens.html needs to be updated to reflect the new path to fetch your API token. The "Current Token" box should probably have a "for more information" link to that page as well.
#17 Updated by Peter Amstutz about 6 years ago
Link.where(tail_uuid: current_user.uuid, link_class: 'permission', name: ['can_write', 'can_read']). each do |perm_link| repo_links << perm_link[:head_uuid] end
Should use Link.filter() and filter
["head_uuid", "is_a", "arvados#repository"]
#18 Updated by Radhika Chippada about 6 years ago
Peter, addressed your comments and more that we discussed one on one. The drop down caret issue and top nav bread crumbs issue are not addressed as I do not want to tie up this story for that topnav UI work. Also, Tom and I discussed earlier and since the last login information is not readily available, we decided to not do it for now.
The rest of the issues are addressed. Please take another look. Thanks.
#19 Updated by Peter Amstutz about 6 years ago
- (Still like the layout)
- Where it says "export ARVADOS_API_TOKEN ARVADOS_API_HOST=qr1hi.arvadosapi.com" the ARVADOS_API_TOKEN part is redundant since it was already exported on the previous line. Take it out so it just says "export ARVADOS_API_HOST=qr1hi.arvadosapi.com"
- Maybe use a horizonal scroll bar for the "Public key" cell instead of cutting it off?
- There seems to be some extra whitespace at the bottom of the "SSH Keys" panel
- The dialog text "Really delete key" is still missing a question mark, it should say "Really delete key?"
- The "Adding your key to Arvados Workbench" sections in doc/user/getting_started/ssh-access-unix.html and doc/user/getting_started/ssh-access-windows.html needs to be updated for the new UI.
- "Name" column on SSH keys is too narrow. It should probably be about 50% wider.
- Under "Repositories" instead of "true"/"false" under the "Writable" column, it would be less ambiguous if it the cell value was "writable" or "read-only".
#21 Updated by Tom Clegg about 6 years ago
- There are extra leading and trailing spaces in the SSH key display.
- I get horizontal scroll bars but the key still takes up lots of space.
- Suggestion (covering both complaints):
- <pre style="margin:0; overflow-x:scroll"> <%= key[:public_key] %> </pre> + <pre style="margin:0; overflow-y:scroll; max-height:7em"><%= key[:public_key] %></pre>
- Maybe put a
<i class="fa fa-plus"></i>icon in the "Add new SSH key" button?
- 5% col width was too small for the trash can on the window width I happened to test with.
- That "read token <<foo" stuff avoids the questionable practice of leaving secret tokens sitting around in your ~/.bash_history. I'd (still) rather sacrifice appearance for a bit of security here. Alternative suggestions:
- (could be an easy solution) reducing the font size could make it fit better.
- (wouldn't want to block on this one) put it behind a "reveal" control.
- should we explain on the page why we do this?
#22 Updated by Tom Clegg about 6 years ago
Another side note to not block on: generating fingerprints turns out to be pretty easy. (We should probably use this instead of a regexp to sanity-check on the API server side, too.)
gem install sshkey
require 'sshkey' SSHKey.valid_ssh_public_key? "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo+8pc/xNohU3Mo2pAieLohLJcWy9OmNOnsEWlegYYoeynkczimicKRmB2iP50v2oKrtshIXwigfU26b0rGEJayFvsA7FCstz5G/tJy3YJGnQUDmrQBuB8SsQDL/O0Nnh8B8XmKSlxuv3FxLyPhUmcxxjIUIEMWVMlIKAfzmySsPby/QREJffUkFPa+luNkOVd5cyvwd6dnl0SLbrqZgcF3fbkOLDVgv3oceIYLjcy/SjqGR4wtGWHFFuna0M2/5YEvWpxD/HNO3WkFEdlAUEEWpvd/u3bmHq2p7ADbaX9ZaNDb8YbjFIOUxaJh+Vf0V6nDhEnUPylzM07F3fnvXQM53Xu5oYA6cp0Com61MBaXUDwM/w6PS2RtF8CG3ICMs5AsIy+Cnsuowj3fRlK29dgZ7K2pYRV2SlQj4vxjwpUcQCL/TFv31VnCMFKQBqmqh8iwZV3U6LLc3cwL9COXnIPF4lXjODL3geWsBNXo3hfoj6qD+2/+9/zOZUtGbQXlBmNC/wG/cK1A1L4S9docZT4QAiaSCdwcLB68hIvQMEOpffoeQhNZj0SddLLdEyjJY6rfWjbmnV68TzXoDz26hoPtagD+wvHOxz3D8BQ9RIqfNI1jNlwVkoKNVfszIPmESwJCu99+6TnyJl4923MTEXNOrJ7LgVUemWchOlkTDINuw== email@example.com" #=> true SSHKey.fingerprint "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo+8pc/xNohU3Mo2pAieLohLJcWy9OmNOnsEWlegYYoeynkczimicKRmB2iP50v2oKrtshIXwigfU26b0rGEJayFvsA7FCstz5G/tJy3YJGnQUDmrQBuB8SsQDL/O0Nnh8B8XmKSlxuv3FxLyPhUmcxxjIUIEMWVMlIKAfzmySsPby/QREJffUkFPa+luNkOVd5cyvwd6dnl0SLbrqZgcF3fbkOLDVgv3oceIYLjcy/SjqGR4wtGWHFFuna0M2/5YEvWpxD/HNO3WkFEdlAUEEWpvd/u3bmHq2p7ADbaX9ZaNDb8YbjFIOUxaJh+Vf0V6nDhEnUPylzM07F3fnvXQM53Xu5oYA6cp0Com61MBaXUDwM/w6PS2RtF8CG3ICMs5AsIy+Cnsuowj3fRlK29dgZ7K2pYRV2SlQj4vxjwpUcQCL/TFv31VnCMFKQBqmqh8iwZV3U6LLc3cwL9COXnIPF4lXjODL3geWsBNXo3hfoj6qD+2/+9/zOZUtGbQXlBmNC/wG/cK1A1L4S9docZT4QAiaSCdwcLB68hIvQMEOpffoeQhNZj0SddLLdEyjJY6rfWjbmnV68TzXoDz26hoPtagD+wvHOxz3D8BQ9RIqfNI1jNlwVkoKNVfszIPmESwJCu99+6TnyJl4923MTEXNOrJ7LgVUemWchOlkTDINuw== firstname.lastname@example.org" #=> "c2:37:7a:a4:84:f5:63:58:8d:62:2e:41:b3:15:d0:e2"
#23 Updated by Peter Amstutz about 6 years ago
Tom Clegg wrote:
Offering a few nitpicks (at no extra charge!) at 4ec5750
- That "read token <<foo" stuff avoids the questionable practice of leaving secret tokens sitting around in your ~/.bash_history. I'd (still) rather sacrifice appearance for a bit of security here.
So that would be resonable if it were true, but I just checked my .bash_history and the multi-line "read ARVADOS_API_TOKEN <<EOF" form already shows up with the secret token. However, looking at the bash man page, it looks like we could provide a value for the "HISTIGNORE" variable to tell bash not to save the command line containing ARVADOS_API_TOKEN:
$ HISTIGNORE=$HISTIGNORE:'export ARVADOS_API_TOKEN=*' $ export ARVADOS_API_TOKEN=5alsxxxxxoxywl7layyyy3tbttyb1rzzzz2cg67g1l $ export ARVADOS_API_HOST=qr1hi.arvadosapi.com $ unset ARVADOS_API_HOST_INSECURE $ tail .bash_history HISTIGNORE=$HISTIGNORE:'export ARVADOS_API_TOKEN=*' export ARVADOS_API_HOST=qr1hi.arvadosapi.com unset ARVADOS_API_HOST_INSECURE
#24 Updated by Peter Amstutz about 6 years ago
+1 on using sshkey gem.
Here's how you summarize a public key on the ssh command line:
$ ssh-keygen -l -f ~/.ssh/id_rsa.pub 2048 ea:ff:55:f2:74:26:45:50:33:37:f4:5a:80:e4:c1:75 peter@peter (RSA)
- We should use those same four columns (key size, fingerprint, comment, key type) in our table.
- We should provide a sample command line for ssh-keygen (probably the same command line as above).
#25 Updated by Radhika Chippada about 6 years ago
Tom, addressed all your comments, except the reveal control. Most importantly, I like the key validation update we put in now. This is good. Also with the finger print, I no longer need the ugly scroll bars in the ssh panel and it is looking better.
Peter, I resurrected the current token with EOF. I think there is really no big loss the way we have it. And, I will be addressing the doc updates as part of #3234 (doc story).
#26 Updated by Radhika Chippada about 6 years ago
Some more minor updates. When no repositories or virtual machines are configured for this user, add a hint to contact admin. Also, added HISTIGNORE.
Did not address adding the additional comment, key type columns. These do not seem to be readily available from the sshkey gem we are using and seem to need further exploration. I think we need to stop the scope creep, unless this is critical information. Please let me know if so.
#27 Updated by Peter Amstutz about 6 years ago
- "Fingerprint" is one word
- The < pre > section after ~/.ssh/config: has an extra line at the end
- Now the key fingerprint column is too small and causes the fingerprint text to wrap. Maybe we should allow the browser to size the table automatically based on column widths?
- From talking to Tom this morning, he thought it was a good idea to still display the key and not just the fingerprint, to reduce confusion ("I pasted key text XYZ but the table displays ABC text")
- doc/user/reference/api-tokens.html still needs to be updated
#28 Updated by Peter Amstutz about 6 years ago
- "Using SSH to log into an Arvados VM" section in doc/_includes/_ssh_addkey.liquid also needs to be updated.
- Please change "an Arvados virtual machine accessed with SSH (Unix or Windows)" to "an Arvados virtual machine accessed with SSH (instructions for Unix or Windows)", the first phrasing implies that the virtual machine may run Unix or Windows.
- Change the section heading "The easy way" to "Setting the environment"
- The "Setting the environment manually" section now seems redundant and can be removed
#29 Updated by Radhika Chippada about 6 years ago
Peter, addressed all the review feedback comments. As for showing the public key in the SSH Key panel, I did not want to add it as yet another column. The whole reason we went for fingerprint is to not show the public key. So, I added it as a tooltip to the finterprint.