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
Comments
-
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.
0 -
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?
0 -
I've reset the value to 300 and after X period I am logged out once again... Session Expired.
0 -
@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!
0 -
I'll start the same session in Firefox Developer Edition right now and I'll get back to you!
0 -
After not even 30 minutes Firefox has been logged out as well. I did set the timeout again for each browser and no luck.
0 -
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.
0 -
@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.
0 -
Weird, because I am getting this behavior on W10 x64 on 3 different PC's...
0 -
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.
0 -
@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!
0 -
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.
0 -
Any update as of yet? I am going into a meeting right now and every time I get back the session is lost.
0 -
@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!
0 -
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!
0 -
@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
0 -
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...
0 -
@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.
0 -
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);
0 -
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...
0 -
@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. :)
0 -
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? ;)
0 -
@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.
0 -
@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
0