Session keeps expiring - not honoring Auto Lock

We are currently using the Web interface of 1Password to do our password storing and we keep getting bounced from the session after a window of inactivity. We've set the count to 50, 200 and 300 minutes but no luck as of yet. Removing cookies and localStorage didn't work (we're web developers).

Probably a bug while setting a expire time or are we missing something?

For those who wonder, no, we're not logging out, refreshing the page or restarting our client (Chrome in this case). The tab is simply inactive for a small window of time each time. Give or take 20-30 minutes. We work with VPS's so we continuously need passwords. Thus you can imagine that this is starting to get very frustrating.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Windows 10 64bit
Sync Type: Not Provided

«1

Comments

  • khadkhad Social Choreographer

    Team Member

    Hi @ReSpawN,

    Thanks for taking the time to contact us. I'm sorry that you are having some trouble.

    Removing cookies and localStorage didn't work (we're web developers).

    If you reset your browser, the auto-lock setting will be reset to the default of 10 minutes. Is it possible that something — an extension, a third-party app — is clearing everything out between sessions? I know you understand this stuff, but I wouldn't be doing my job if I didn't at least ask. :)

    What happens if you set the timeout to 1 minute? Does it lock after 1 minute as expected? I just did some preliminary testing, and it appears to be functioning as expected for me. However, I didn't want you to have to wait another 300 minutes for me to try a timeout that long before you got my reply. I'll do a little more testing, but please let me know if things are working correctly for shorter times.

  • Yep! It locked after exactly one minute, so that logic works fine. I have no other plugins besides the Web Developer toolbar and Adblock Plus. AdBlock is even disabled on 1Password because I want the full functionality without hickups and I assume that 1Password is not serving advertisement crap. ;)

    Can I test anything else for you?

  • I've reset the value to 300 and after X period I am logged out once again... Session Expired.

  • brentybrenty

    Team Member

    @ReSpawN: Is Chrome perhaps trashing the tab's process due to inactivity? I'm actually curious because keeping a single tab open in the background in Chrome for more than 300 minutes and then returning to it isn't something I encounter in my usage. I know Chrome has gotten more conscious of energy consumption lately, so I wonder if this may be related. Do you have the same issue in other browsers? We'll get to the bottom of this!

  • I'll start the same session in Firefox Developer Edition right now and I'll get back to you!

  • brentybrenty

    Team Member

    @ReSpawN: Awesome! Thank you so much for your patience and willingness to work with us on this. I think a stable browser might be better, but if it's limited to Chrome that might at least provide some clue. :)

  • After not even 30 minutes Firefox has been logged out as well. I did set the timeout again for each browser and no luck.

  • AFAIK the Developer edition is purely a nice style/look/feel with more development tools but for the heck of it I tried Firefox ol' plain and simple: same issue.

  • brentybrenty

    Team Member

    @ReSpawN: Thanks for following up! It's a bit confusing because of the naming scheme, but FirefoxDeveloperEdition seems to be an alpha release currently at v49, with beta at 48 and stable at 47.

    Thanks for the 30 minute figure. I'm trying this both in Chrome and Firefox (stable and alpha) to see if I can reproduce the issue with either a 300 minute lock (or something lower, but we'll start there).

    ~3 hours in, it isn't looking promising...but I just realized that I'm using a different OS, so I'm starting the same on Windows 10 as well to see if that may be the culprit. I'll let you know what I find.

  • brentybrenty

    Team Member

    @ReSpawN: It looks like about 2-3 hours on the first set (which is 2-3 hours shy of 300 minutes). Definitely not 30 minutes, but I'm waiting on Windows 10 to see if I can confirm the same behaviour there as well.

  • Weird, because I am getting this behavior on W10 x64 on 3 different PC's...

  • brentybrenty

    Team Member

    @ReSpawN: I've noticed another thing about this. On macOS at least, when I logged back in after the session ended, the timeout was reset to 10 minutes. Is that happening in your case as well? Still another 90 minutes or so here on Windows 10...

  • ReSpawNReSpawN
    edited July 2016

    Same timeout again, from console:

    libjs-20160707.js:202 GET https://domain.tld/api/v1/vault/xxx/items/xxx401 ()n.send @ libjs-20160707.js:202l @ libjs-20160707.js:202(anonymous function) @ libjs-20160707.js:202n.map @ libjs-20160707.js:202map @ libjs-20160707.js:202(anonymous function) @ mA2xrUy-UgQ6oqFOySc4XP3Q9f8.js:384
    mA2xrUy-UgQ6oqFOySc4XP3Q9f8.js:622 getVaultItemWithUuid failed: TypeError: Cannot read property 'item' of undefined(…)(anonymous function) @ mA2xrUy-UgQ6oqFOySc4XP3Q9f8.js:622
    mA2xrUy-UgQ6oqFOySc4XP3Q9f8.js:607 Uncaught (in promise) TypeError: Cannot read property 'item' of undefined(…)

    Also received a 401 on fetching an item and a notifier. That one got cancelled because of the redirect I guess.

  • brentybrenty

    Team Member
    edited July 2016

    @ReSpawN: It's been 4 hours on Windows 10 so far, they haven't locked, and I'm afraid I may run out of steam before they do! :lol:

    I've passed on the details you provided as well as the results of my own testing on to our development team so they can investigate this further as well. Thanks!

  • Perhaps a thing to take into account is that we're not using the tab and even in Firefox the window is behind other/minimized.

  • brentybrenty

    Team Member

    @ReSpawN: Indeed. I'm getting the full timeout 300 minute here otherwise, so we'll need to continue to test different scenarios.

  • Any update as of yet? I am going into a meeting right now and every time I get back the session is lost.

  • brentybrenty

    Team Member

    @ReSpawN: I'm sorry for the inconvenience. We're looking into it, but not being able to reproduce it is making it difficult. On the plus side, I think it's at least better that 1Password locks too aggressively rather than leaving your data exposed in error. I definitely wouldn't be comfortable leaving my machine unattended with 1Password unlocked knowing that someone would be able to access it while I was away.

    Is that what you're usually doing when this happens? If so, I'd imagine you'd have the OS itself lock, and that could make a huge difference in testing. Please let me know!

  • brentybrenty

    Team Member

    @ReSpawN: Just wanted to follow up on this. The devs have tracked it down to a caching issue, but I'm still trying to understand why it would only happen for you and not me, in spite of testing it with multiple browsers/platforms. Thanks again for bringing this up!

  • Well, it more rather then less is dead on. We indeed lock our stations when we step away but that doesn't happen regularly, only during breaks. The lock occurs while we work, thus on an unlocked machine though with user activity. We haven't been able to NOT reproduce, so to say, as we're continuously locked out. :(

    If I can be of any more assistance in debunking/debugging this, just let me know!

  • brentybrenty

    Team Member

    @ReSpawN: Absolutely! Thanks so much for bearing with us while we try to get is sorted out. Just to clarify, the devs seem to be able to corroborate your findings, so I'm fairly confident we'll be able to get this resolved for you. Why it works properly for me is a mystery. :unamused:

    ref: b5-1850

  • Any progress Brenty? We're still experiencing the bug and it's starting to get quite annoying. I understand this isn't high priority but I can't believe that we're the only ones having it...

  • brentybrenty

    Team Member

    @ReSpawN: If others are experiencing it, they haven't reported it. That's not to say it isn't important, but I didn't want to dodge your direct question. :(

    That said, we're considering a few different options for addressing this. Frankly, it's surprising that others aren't running into this issue...but that's probably because it defaults to 10 minutes, in which case you won't run into this.

    I don't have anything to share yet, but I appreciate you following up on this. We'll let you know when it's addressed in a 1Password.com release, since I've tagged your posts and notes in the issue we have open.

  • ReSpawNReSpawN
    edited August 2016

    Awesome! We hope the issue will be resolved shortly. We really want to work with a 2 hour timeout. :)

    For now, we created a 'lil snip:

    javascript:setInterval(function() { document.getElementById('vault-view-link').click(); setTimeout(function() { document.getElementsByClassName("click-target")[0].click(); }, 500); }, 420000);

  • MeganMegan

    Team Member

    Hi @ReSpawN,

    Thanks for sharing that! We really appreciate your patience as we work to track this down. :)

  • Any update on this? It's been 2 weeks to the day and still no resolve. We can make due with the snippet that I posted but still there is a bug somewhere. We'd really like to use a lock timeout because even now after a week we're still logged in. All fine and good, but secure is a another thing...

  • JacobJacob

    Team Member

    @ReSpawN Thanks for checking in. The issue is still on our list, but to reiterate what @brenty said, we've only had one other user ask about this. I'll let the team know you checked in, though, and we'll see what we can do.

    All fine and good, but secure is a another thing...

    I'm not sure this affects security. Locking sooner is certainly better than never, so this issue sways on the good side of things. :)

  • Thanks for the update Jacob.

    The quote you are referring to is I guess misunderstood. What I meant was the security of our plugin which circumvents the entire lock screen. We'd love to use the prolonged timeout functionality you call Auto Lock but we had to invent our own way of mimicking that functionality. Again, to reiterate myself, being the one who is vocal about it doesn't mean that I am the only one experiencing it.

    I am trying it at home right now with Chrome 52 on Windows 10 x64 with my own 1 Password account. Let's see how that works out. I can imagine that if it somehow is related to hardware/network/firewall at work, the problem shouldn't surface at home, right? ;)

  • brentybrenty

    Team Member

    @ReSpawN: I'll definitely be interested to hear your results since we've seen some different behaviour in our own testing. But I'll be honest, we may just end up lowering it if it won't work consistently between different platforms/browsers/configurations. 300 minutes also seems excessive, perhaps for anyone but you and a handful of others who are super security-conscious. Most users won't go to the same lengths to secure their computers, and the browser itself will always be a huge attack vector. Something to think about.

  • brentybrenty

    Team Member
    edited September 2016

    @ReSpawN: Just wanted to let you know that we have a fix for this in today's update. 1Password.com will try more actively to keep the session alive. Please let us know if you encounter any further issues with this — and thanks again for your patience! :)

    ref: b5-2002

This discussion has been closed.