Fastest programmatic way to test session expiration?

HippoMan

I am looking for the fastest way, programmatically, to determine whether a given CLI session has expired. By "fastest", I mean using the smallest amount of computer resources.

I am doing the following. Can any of you think of something that would utilize even fewer resources?

#!/bin/zsh -f
[[ -z "${OP_SESSION_my:-}" ]] && exit 1
exec /usr/local/bin/op get account 1>/dev/null 2>&1
exit -1   # in case 'op' doesn't even execute

This script's return code will be 0 if there is a valid CLI session in effect.

---

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

cohix

@HippoMan There is a method that will work, but it could be tricky.

If you look in $TMPDIR/com.agilebits.op.[UNIX_UID], there will be a bunch of dotfiles, each one representing one of your sessions. If you look at the JSON in those files, you'll see something like this:

{
  "kid": "v8lL1IL8Yee3hYQwmcyWNa5d5Gs",
  "enc": "A256GCM",
  "cty": "b5+jwk+json",
  "iv": "ytU07OQOHKJWmyHA",
  "data": "i66SEoujJJZxcqCLWQU1sGrLwbfLzogaO6t_Oep3tlzZSJOfugKOFGoqqcrgStagJ-Y6WHNKtccAlGXltDKvxvtKzhJGsw07-yqNwFoi7tRgw4a79WWZeSPwpAgI8N3G40t_KouN3LU94Iem0tBKaT96s-34yX3SSqSrFADOCsdhNinaFDi7JBlgVLaPN9Yzeg1NlkGscNhSiOVfF95DvTCOmuHsZadX05Jh2hicFvvMuluuLTg9YhLaXEtdyRCdOWOsvyI7_k6vazmjVPT6lZDA30U72hVJM1Znepodj2A3zQiacUv7eokbd7pt4NS5papcWxxGTMo0b7xlasFXA9tAdyDE",
  "accessed": "2018-05-30T16:03:38.123678186-04:00"
}

This is a session file that we use to store the encrypted session key for your CLI sessions.

If you look at the accessed field, that timestamp is the last time the session was used to contact the 1Password server. If less than 30 mins have elapsed since that timestamp, then the session is probably valid.

The problem is that there may be many of those files (they're cleaned up automatically as you use the tool, we do the 30m check internally), but if you only have one session going on, then this could be a valid strategy.

Let me know if there's anything else I can help with.

cohix

Oh, and any number of things could have invalidated the session, like user suspension, device deauthorization, etc. But it's something, at least :)

HippoMan

This is quite helpful.

So, does the kid attribute contain the same value that gets stored in OP_SESSION_my?

HippoMan

Of course, these files are owned by root and only have 600 permissions, which means that I can't read them as a non-root user unless I use sudo or some other permission-raising scheme.

So how about an op status command in an upcoming CLI version?

cohix

@HippoMan No, kid is "Key ID", which is not the same as the env var.

Ah, that's a good point. I'll add a suggestion for some sort of status command.