My site records aren't always getting correctly stored when I generate a password and save it via the Passwords toolbar. So when I create or modify a site record, I log out of the site, close the window, then go to Passwords in the WSA console to inspect the site record, launch and test.
The hitch is that the console doesn't update after I create or update a site record. Every time I make a change via the toolbar, I have to kick the console in the head to get the site data to refresh. Because I haven't found a better way, I use the browser controls to refresh, and that means I have to reauthenticate. That is a pain if I have to do a string of tweaks to get a site record right.
How can I get the Passwords console page and toolbar to play together better?
(edits: grammar and duplicate signatures)
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Initially, I tried to use both the passwords console page and the PM functions from the browser tool bar simultaneously. I had the problem that updates I made via the toolbar weren't refelect on the console page unless I logged in again--and that was a pain for me because I'd set up two-factor authentication.
After using the system for awhile, I've decided that this behavior is likely by design, and my expectation of different behavior was simply uninformed. After creating a new site using the browser toolbar, there is no reason to go to the console page to double-check the record. One can easily open the site from the toolbar and inspect the record to make sure it is complete. I simply use the add-on now. I haven't even visisted the console page in months.
I've just started using the password manager in other browsers besides Chrome. I notice that site updates I make in browser A aren't available in browser B until I restart that browser B. This time, I'm not surprised by that behavior. :D
I think I know that feeling. If I could surgically attach my Android phone, I would. The little guy serves me so faithfully. :D
I hope you feel better soon, David. No rush on this, after all it's just inconvenient, not a showstopper. Take good care of you...
I am sorry, I have not started on this yet... I am not feeling all that well at the moment. I will get this done tonight or tomorrow though 🙂
Apologies, if I sound a little callous, just a bit long in the tooth and have been seeing this sort of ping pong going on for years.
Hopefully, David, can validate your issue and then it can be passed on to the Support Team for sorting.
Oh, great, guys, this just in from Jasper_the_Rasper:
Heartbleed maliciously exploited to hack network with multifactor authentication
So long, secure feeling, it was nice knowing you. :(
I will be looking into seeing if I can get it activated using my Android tablet... I do not currently have an Android phone available.
How Apple and Amazon Security Flaws Led to My Epic Hacking
Here's Everywhere You Should Enable Two-Factor Authentication Right Now
I started using it because a client had it on their MailChimp account, and I very quickly got addicted to feeling secure. I would not use a Password Manager that didn't provide 2FA.
Well, you are the first post here that I have seen that has set that up... I think most users are not even aware of it.
I have not yet set that up... due to no one else having used it or asked about it yet. I will get that set up tonight if at all possible so I can have a better look at what is going on here.
BTW, why the 2FA...is it really necessary?
I set up two-factor authentication on my account. In order to access the Password Manager, I have to read a code from my mobile phone (from the Google Authenticate app), then type it into the Password Manager in my browser. That's why I'm fussing about this--it's really inconvenient to have to keep refreshing and reauthenticating to see new sites in the web console.
The reason I am looking for new sites in the web console is because when I generate passwords they're not always saved reliably via the toolbar addon. Sometimes the site is saved with an empty password field and sometimes it saves with the wrong password. Also, when I generate replacement passwords, sometimes the stie fails to update. So when I save or update a site, I need to inspect the record and make sure it has saved correctly. I also find I often need to tweak the URL the toolbar saves. I can't be sure I've got that right unless I logout of the site, close the tab, and then relaunch the site from the saved record in the console.
I hope that makes sense!
I am obviously missing something important here and being a bit dumb.
1) Open the WSA web console and log in
2) Click on Passwords and authenticate (leave the tab open)
3) Open another tab, navigate to a new website, create and store credentials via the WSA toolbar
4) Return to the already open WSA web console
6) Confirm your new site is stored (without having to refresh the Passwords tab and reauthenticate)
You may well be right about the deleted records...will have to check that out too...but just tried again on a completely new site I have never signed into before and the PM Toolbar worked fine, credentials stored correctly in Console with PM generated password (12 alpha slected), and it was correctly stored and was immediately usable having rebooted to clear everything out before trying to login with PM autofilling the credential details...and again...it worked fine.
So still flummoxed...and probably need to wait for David it to try it himself and see what result he gets.
...It just occurred to me that other addons could be affecting performance. I use Hootlet and Pin It, and I see that Google Docs has an extension installed, although there's no toolbar associated with it in the browser.
If you guys observe different behavior than me, I will shut down all my other extensions (gasp!), and we'll see what happens.
(edits: additional thoughts)
I noticed there was an option for restoring deleted passwords while I was reading the manual, so this behavior is in some way intentional. You could argue that while a site record is "deleted", its login credentials shouldn't be accessible via WSA.
I'm a former software engineer and I tend to push apps pretty hard, so I may be seeing some things other people haven't run into before on Chrome. I want to point out that my production machine is a bit old, too, but I'd be a bit surprised if that were the problem here. I keep it clean, and I don't have any ongoing trouble with other apps.
I will wait until either you or David has a chance to check out what I'm doing before proceeding.
Thanks a bunch,
So, have to admit...I am flummoxed. Will have to try this again in more controlled conditions over the weekend.
Are you running any other security-related app in conjunction with WSA (clutching at straws at the moment)?
I actual run 4 different browsers, depending on what I want to do on the Web (but also becuse it is good to have the same apps as the users that one is trying to support/help, etc...;)).
I use IE11, FF27, Maxthon (not supported by WSA per se) and Chrome...on both Win7 64bit & Win8.1u1 32bit...and I am not having any issues what so ever with Chrome...in fact I think that probably IE11 is causing more issues (though not many in reality).
I shall have to do what David will be trying, i.e., to recreate your symptoms, etc.,
I will wait until you've had a chance to verify this doesn't work for you either. I am seeing a lot of glitches, so I'm suspicious I'm not using the product as it was intended. *Unless* it's not as robust in Chrome as it is in Firefox or IE. I was actually surprised to see that Chrome wasn't fully supported until recently, as it's been a real contender for years.
I've been debating whether to try working out of Firefox today. I live in Chrome. I don't think I can do it! :p
Have a good day, peeps.
Take a look at this previous thread; not quite what you are experiencing but it does relate to the Console not receiving data correctly from a client PC, and so may be of some assistance. Also please note that it refers to the 2013 version rather than the current one so the screenshots are not accurate but I think that yo uwill get the gist of what was going on/suggested and can most probably translate this to the 2014 version.
See if anything in there helps...I will keep searching for additional pointers.
Well, that's not something I anticipated being asked! But I doublechecked my logs, and the scan has been running as scheduled. I scanned again, and the manual scan showed up in the log just like the scheduled scans, so I trust that the scheduled scans actually happened as logged.
Can you point me to any topics where you and David discussed this before? I searched before I asked, but I got no relevant hits.
I wasn't even sure this was something that was expected to work. It sounds like you and David, at least, have the same disappointed expectation as me. Do you recall if this has ever been escalated to support?