Provisioning test accounts

c__

Hi,

I'd like to set up some automated testing for my wrapper(s) around the op utility, but for obvious reasons do not want the tests to use my primary account. I could add a test user to my shared/family-plan style account, but it would still have access to any shared vaults, I think. I would prefer not to pay for an additional individual subscription just to run tests.

Would it be possible to create limited use test accounts (perhaps self-deleting after some time period, or a restricted to a certain number of items, or restricted to CLI use, or other options) for the purpose of testing op in isolation from primary account credentials? Or does something like this already exist and I overlooked it?

Thanks,
C

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

cohix

@C__

The only option available here would be to convert your account to a Teams account and use a guest account for testing.

Alternatively, you can open source your wrappers and then get yourself added to https://github.com/1Password/1password-teams-open-source

:)

c__

@cohix , they are (or will be) open source, but I do not have much to show at this time (chicken and egg problem). I will take you up on that when I have something more fleshed out. Thanks!

cohix

@C__ Let me know if there's anything I can do to help, you can email me (connor [at] agilebits.com) if there are any workflow improvements or questions you may have.

c__

I really appreciate the offer, @cohix. Thank you.

Right now the main things I struggle with are things I've already brought up on this subforum:

• I would appreciate more thorough documentation of the op utility. The "Full Documentation" page reads like a high-level overview. It'd be nice to see:

  • The entire command tree documented, as well as
  • Expected output (stdout, stderr, exit code) on success or in various error conditions.
  • Can the tool produce json that is not well-formed, or is it guaranteed to be well-formed? That kind of thing.
  • It's not necessarily the best example, but Python is at least a good starting point for what that might look like.

• I will eventually need to be able to edit existing items, preserving history. Not just delete and create new ones. :)

I understand that both of these are on your radar or even in progress already, and I also understand the realities of needing to prioritize how software development time is spent. :)

cohix

@C__,

We are indeed aware of all of the above :) Thanks for keeping us on our toes.

c__

:+1:

AGAlumB

Indeed, the feedback is greatly appreciated. Cheers! :)

c__

Hi,

I discovered a workaround for provisioning test users on a Family account. The default shared vault's membership cannot be restricted; any new member automatically gains access. However,

1. The default shared vault can be deleted, and
2. New, ordinary shared vaults can be created, and they have arbitrary access control between users on an account

This means I could just delete the ordinary "Shared" family vault, create a new "Fake-Shared" vault shared with only my wife, and then create test account(s) as needed that have no access to the "Fake-Shared" family vault (and obviously no access to any private vaults). (Of course, they should be "Family member" type users rather than "Family organizer" users.)

This works well enough for my purposes!

(I think it might make sense to allow limiting access to the initial Shared vaults anyway. For example, families expand. It might make sense to put community property financial credentials in a Family account Shared vault when it is just a pair of spouses. But often couples have kids, and probably no one wants them to gain access to their Shared vault financial credentials when they create an independent login on the Family account for the child.)

P.S., I'm still looking forward to being able to edit items from the CLI op! 😁

P.P.S., I would also encourage distributing a libop library for non-shell programs to integrate with more directly. But I can understand there are good reasons you might not want to do that.

Thanks!

AGAlumB

This means I could just delete the ordinary "Shared" family vault, create a new "Fake-Shared" vault shared with only my wife, and then create test account(s) as needed that have no access to the "Fake-Shared" family vault (and obviously no access to any private vaults). (Of course, they should be "Family member" type users rather than "Family organizer" users.)

Correct. You can delete the default Shared (everyone) vault and create additional vaults shared with some, all, or none of your family members. However,

(I think it might make sense to allow limiting access to the initial Shared vaults anyway. For example, families expand. It might make sense to put community property financial credentials in a Family account Shared vault when it is just a pair of spouses.

I'm not sure what benefit it would give to allow permissions on the default Shared (everyone) vault to be modified though, when you can always create another vault and do whatever you want with it; it is not possible to create another vault which everyone automatically has access to when you invite them, so it's handy to keep around, even if used only sparingly, unless you're certain you will never want that (you'd always have to manually add people to any other vault).

But often couples have kids, and probably no one wants them to gain access to their Shared vault financial credentials when they create an independent login on the Family account for the child.)

In that case I'd suggest it makes more sense to use a custom vault for those, with access limited only to the parents. The default Shared (everyone) vault can be used for other things, like Netflix, or security codes to the home.

P.S., I'm still looking forward to being able to edit items from the CLI op! 😁

Me too! :)

P.P.S., I would also encourage distributing a libop library for non-shell programs to integrate with more directly. But I can understand there are good reasons you might not want to do that.

I'm not sure what the future will bring, but it's the sort of thing we can evaluate more as the CLI app matures and graduates from beta. Cheers!