Conversation
Adds @varlock/dashlane-plugin wrapping the Dashlane CLI (dcli) to resolve secrets via dl:// references. Supports pre-authenticated dcli sessions and headless auth via service device keys, multiple instances, and in-session caching.
🦋 Changeset detectedLatest commit: 2b35b45 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks for this! Will review soon |
|
@LucasPicoli - would you be using this for local dev only? Doesn't seem like they have an sdk/api to pull from in production without using the CLI - which would mirror what we do for 1pass (use sdk with service account tokens for prod) |
|
@theoephraim it does work for CI/prod too, not just local dev. Dashlane supports headless auth via https://cli.dashlane.com/personal/devices which the plugin accepts through serviceDeviceKeys, same bootstrap pattern as the 1pass plugin. The main difference is that they don't have any SDK or API, so it's CLI-only for both paths, similar to the pass plugin |
| `dcli read` works against a **local vault cache** that auto-syncs with Dashlane's servers once per hour. This means: | ||
|
|
||
| - Secrets changed less than 1 hour ago may not be reflected without a manual sync | ||
| - Run `dcli sync` to force a fresh sync before resolving |
There was a problem hiding this comment.
should we internally trigger dcli sync at the beginning of the resolution? Probably too aggressive... but maybe there is a way to check when it has been synced last and trigger it depending on that, to make it more often than 1 hr? or could add a triggerSync param within @initDashlane too?
There was a problem hiding this comment.
I considered this but thought it was a bit too much overhead since the reads try and make sure everything is synced. But yeah, I think it's better if we do it on init, just to make sure everything is up to date.
There was a problem hiding this comment.
do keep in mind that when doing live-reload style front-end dev, it may be reloading the config a lot. So it still probably makes sense as an option?
| @@ -0,0 +1,277 @@ | |||
| # @varlock/dashlane-plugin | |||
There was a problem hiding this comment.
Please add the docs page to the website as well. Other plugin pages should provide a good template/example.
| @@ -0,0 +1,384 @@ | |||
| import { | |||
There was a problem hiding this comment.
thanks for adding tests. I hope to do a pass soon at providing some tooling to make it easier for plugins to include tests.
|
just a note - I also noted that the dcli will not lock itself after working on it. this should be fine on interactive environments, especially if we are resolving multiple credentials. I'll make sure to add a note that tells people to lock their vaults on the instructions. however, for headless I'll make sure that we lock the vault down at the end. |
Adds @varlock/dashlane-plugin wrapping the Dashlane CLI (dcli) to resolve secrets via dl:// references. Supports pre-authenticated dcli sessions and headless auth via service device keys, multiple instances, and in-session caching.
- Set version to 0.0.0, remove CHANGELOG.md, add changeset - Add dcli PATH callout to README, fix @type syntax - Point dcli install references to official docs - Remove dashlaneSecretRef data type - Add automatic vault sync before first read (opt out with skipSync=true) - Add automatic vault locking via spawnSync on process exit - Add docs website page, sidebar entry, and overview table row - Fix concurrent read races with in-flight promise deduplication - Guard validateDeviceKeys against non-string input
|
re: locking - might want to make that an option too. The default can be set based on whether it is headless or not. This might require adding a new hook or something, as I'm not sure there will be a natural place to add it. I had initially imagined lots of hooks available to plugins like this but there hasn't really been a need yet. Also one important thing - make sure that any init / connect logic only runs when there is actually a first read triggered. You dont want it to happen on plugin init, because you may initialize the plugin in your .env.schema, but only use it in some cases, and you dont want for example a missing |
3 participants
Adds @varlock/dashlane-plugin wrapping the Dashlane CLI (dcli) to resolve secrets via dl:// references. Supports pre-authenticated dcli sessions and headless auth via service device keys, multiple instances, and in-session caching.