Item permalinks

Feature name:

  • Item Permalinks

Feature Description

  • Add ability to copy a permalink to an item and add a route to the webapp that opens these links
  • The links would be like bitwarden://valut.bitwarden.com/item/2b3acfcb-6e78-4f0e-9bf7-ab8901e85876 mentioned here
  • This feature can be implemented in all clients, but I’d start with web since that’s what I’m familiar with. This can be later implemented in other clients as well.

My Employer is currently thinking about switching the password management tool out, and currently this is the feature that we can’t live without

Clients / Repos Affected:

  • Web
  • Browser extensions

Timeline to completion (estimate):

ETA: Q1/2021

4 Likes

Hi @simhnna , this feels like a worthy undertaking. The AngularJS routing engine should support this I believe.

Some thoughts on direction:

  • The routing should use a structure that allows deep-linking both organization items and personal items
  • The logic for generating the permalink for this should live in jslib since its logic for creating/referencing the permalink will be shared across clients; this includes the abstraction for it and default implementation
  • Permalinking should always point to the web vault (even when generated/copied from other clients)
  • I believe the protocol should match https:// and not bitwarden:// given we use the bitwarden:// protocol for launching our desktop application from the browser for the purposes of web flows (like auth through SSO to the desktop, etc.)
  • The routing and lookup logic would then only need to live in the web vault itself

Please follow existing coding conventions (place, form, function, and format) and if you have any questions please feel free to post here and tag me. Also please understand any contributions to Bitwarden, either internally or via the community will require testing by our QA team, so it may take some time from PR, approval and merge/release.

Thanks again!
~ Chad

1 Like

I had a quick try and found something else that needs to be implemented first.

Assuming you have .../organizations/xxxxxxxx/vault bookmarked and try to open it. You’re immediately redirected to the login page and after a successful login you’re not redirected.
It looks like there are only two routes that are redirected after a login /settings/premium and /settings/create-organisation

I tried redirecting all urls after login, but since the vault data is fetched after a successful login, redirecting only works if the required data for the route is already available.

I see two possible solutions:

  1. Wait until all data is fetched and then do the redirect
  2. Rework the components so they fetch the data if it’s not yet available

Option 1 would probably require less work, but it feels kind of hacky
Option 2 would require more changes, and I’m not sure if I can find all places where this is needed

And a general question. Should a dedicated page for items be created, or should the edit dialog just be opened? For items the only option I currently see for permalinks is something like .../vault?itemId=xxxx that then automatically opens the dialog

I think option 1, allowing the vault to open as usual, then popping the dialog seems like the best option and least intrusive. Feels like you can fire an event upon successful auth, when there is a “deep link” in the route, and use another service to subscribe to that event and wait for the data + page to load, then pop the edit dialog for the affected item. That feels like a decent flow, although it could take a minute to load, it allows direct linking as well as the rest of the experience to load for other quick actions, etc.

Option 2 while it seems perhaps “more correct” also feels like a mine-field.

Let me know if that makes sense, and of course you or anyone is welcome to provide feedback here to help give perspective, etc. (I am not a software designerologist)

Ok. I have a version here that implements option 1.
The issue with that, is that this currently only works for item permalinks. All other urls might not work.
The urls are currently /#/vault?itemId=${id}

I guess we could add a new component that loads all permalinks with a common prefix so something like /#/vault/permalink?${objectType}=${id} and only redirect to these links after login. Internally the component would wait for the data be to fetched and then redirect to the object component.

But that way we’d have two links to each object. And you can’t just copy the current link and send it to someone.
I still think that dedicated components/routes for each object would be better for the future. That way initially only needed objects can be fetched with a full sync happening in the background. That should also make bitwarden feel a lot faster

That seems like a decent direction, I agree we can and likely should have dedicated permalink structures for each type of item to keep things simple and I imagine there are only so many things you can permalink. From what I saw does this handle Organization shared items as well as items in the personal vault? Those would be the only 2 things concerning for permalink at the moment anyway.