Forum Discussion

sisk's avatar
sisk
New Contributor
5 months ago

Feature request: select account in `op://` url querystring

Hi there!

Had a feature request I'd like to make.

I have several environment variables with 1Password secret paths across a couple of accounts, some of which are in my environment only when my working directory is inside some subpath. The env vars specified in my rc files tend to be with a personal account while some of my work ones are when I'm in a work-related directory. The problem with this is that when I run `op run` (with or without an explicit `--account` specified), it fails because the paths span multiple accounts.

Would be great to be able to specify the account as part of the url. Something like the following:

`op://path/to/secret?account=personal`

Thanks!

CLI
feature request

5 Replies

  • oulipo's avatar
    oulipo
    New Contributor
    15 days ago

    I agree this is very basic and would be really useful. It would obviously break backward compatibility though, but perhaps just a simple check that the first field is a "xxx.1password.com" (and any other allowed domains) would be enough?

    otherwise adding ?account=... or introducing a new format eg op://account@vault/item/field

  • 1P_Phil's avatar
    1P_Phil
    Icon for Moderator rankModerator
    2 months ago

    Hi sisk​ & sylr​ ,

    Thanks for writing in. 

    We appreciate the feature request. I have passed this along to the team. As a sub-optimal work around for now you can use the "op login" command to switch accounts. 

    Take care and have a great weekend,
    Phil

  • sylr's avatar
    sylr
    New Contributor
    2 months ago

    I agree, we should be able to reference the account in the URL, either as an attribute or as a domain:

    - op://path/to/secret?account=my.1password.eu
    - op://my.1password.eu/path/to/secret

    • 1P_Phil's avatar
      1P_Phil
      Icon for Moderator rankModerator
      2 months ago

      Hi sylr​ & sisk​ ,

      Quick update, one of our devs kindly reminded me of the "--account" flag on the CLI which is way better than "op login".  This should get you the functionality you need for scripting.

      op read --account account1 op://secret/in/account1 
op read --account account2 op://secret/in/account2

      Thanks,

      Phil

      • sisk's avatar
        sisk
        New Contributor
        2 months ago

        Hi 1P_Phil​,

        Thanks for the reply. Unfortunately, the `--account` flag is insufficient for this purpose.

        The issue arises when using `op run` to replace secret references in the environment that span multiple accounts with their contents.

        For example:

        My environment has secrets from a mix of different 1Password accounts depending on which directory I'm working out of. Some are shared secrets managed by my employer, some are personal secrets managed in my personal account. So, at any given time, my environment may have something like the following:

        $ env
PERSONAL_API_TOKEN="op://Private/Some Service I Pay For/credential"
WORK_MANAGED_PERSONAL_API_TOKEN="op://Employee/Some Service My Company Pays For Me/credential"
WORK_MANAGED_SHARED_API_TOKEN="op://Department/Some Service My Company Pays For A Department/credential"

        The first env var (`PERSONAL_API_TOKEN`) is in the 1p account I pay for outside of my employer. The other two are in the account my employer manages.

        At this point, there does not appear to be an `op run` incantation that will allow all of these secrets to resolve correctly. Depending on which account is default (or which account I specify with the `--account` flag or the `OP_ACCOUNT` environment variable), either the first var will fail to be read OR the other two will fail to be read.

        Which is to say that every secret reference in an environment at any given time MUST be from a single account. If there is even one reference that is for a different account, there is no way to execute `op run` without it failing (as far as I can tell).

        Let me know if that clears up the scenario I'm dealing with.