unexpected OP_DEVICE causing signin error?

paulpharr

I have a server node which is part of a cluster that accesses 1password CLI 1.7 through python 3.6 for user management & reporting tasks. It's an AWS server running linux2.

When I was building the server connection, I ran into the problem discussed elsewhere of not having a device ID: "No saved device ID. Set the OP_DEVICE environment variable and try again" Based one discussion in other threads related to calling CLI from CI tasks in containers, I took the suggested device ID and added it to the environment python uses to call the CLI - so any call from the cluster would use the same device ID and would constitute a virtual device. This is what I understood to be the recommended best practice in this situation & worked fine immediately & keeps the logs clean. I like it

Unexpectedly, I was immediately unable to sign in to the OP CLI tool from the shell on the same server node using the same credentials that still work fine on the python server process.

[ERROR] 2020/10/11 09:17:39 401: Unauthorized

Admittedly, this is only used in rare cases to troubleshoot CLI behavior, but was convenient to know was an option. It feels like 1pass may be surprised to see requests from two device IDs on the same IP address, but I don't think this should be true.

I looked at the shell environment and I don't see OP_DEVICE set there so it's hard for me to see what may be going on.

So questions:

For standard use from the shell, where is the device ID stored? should I see OP_DEVICE in the environment? Does OP store anything locally other than in the environment?

Is it reasonable to expect I can call IP CLI from the shell and python on the same host as two separate devices?

Do you have advice on how best to fix this annoyance?

Thanks!!

---

1Password Version: 1.7.0
Extension Version: Not Provided
OS Version: AWS linux2
Sync Type: Not Provided

paulpharr

I do now see ~/.op/config and it does have a different device ID than is being used by the python based system on the same host (as I expected). But this does not seem like it would prevent a signin to me. Still wondering why signing in from python caused shell based signins to start failing. - Thanks!

ag_yaron

Hey @paulpharr ,
That's interesting.

I asked the CLI team to take a look and see if they can shed some light on the matter. In the meantime, can you please log into your 1Password.com account, select your profile on the top right corner and deauthorize these devices, then use op signin to authorize them once more and see if it has any effect?

paulpharr

Saturday and Sunday after I first experienced the problem, I confirmed it persisted at least 10 times over the 2 days

This morning when I saw your response, I first wanted to confirm the behavior had not changed, but the shell login succeeded without any action on my part.

I then immediately confirmed the python based login & that worked fine as well

So the state worked itself out on its own - though I still feel like there was something wrong in the behavior.

ag_yaron

Thanks for the update and additional info @paulpharr .

The team had a bit of troubles reproducing what you are describing though. If you do manage to reproduce the issue, please provide a step-by-step list on how to reproduce it so they can debug it :)