Jump to content

Search the Community

Showing results for tags 'browser'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Essentials
    • Announcements
  • Passwordstate 9.x
    • General Support
    • General Hints and Tips
    • Known Issues
    • Installing Passwordstate
    • Feature Requests
    • Feature Requests - Completed
    • 3rd Party Hardware/Software Knowledge Forum
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • App Server
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 8.x
    • General Support
    • Feature Requests - Completed

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 5 results

  1. I’ve used the new function ”Link Account to Multiple Web Site URLs”. I’ve linked 2 accounts to `localhost`. Now when I use the autofill button on the password fields, I get 2 options, but I don’t which is which. The names of the accounts are the following: (I've removed my personal email from the image) So printing out the title for accounts that are of type “Linked URLs” would solve my problem.
  2. Is there a particular path that the browser extension uses or does it need access to the entire site starting at the root?
  3. I've linked 2 password entries to the URL maxdev (a local dns that I use for development). When I use the browser extension context menu to fill in the password, I always get the password for entry that is highest up in the password list. I suspect that it takes the first match for the linked URL, instead of checking further down in the list for the correct match. To summarize: Both entries below (Portal NO and Portal SE) are linked to url http://maxdev. Whichever option I choose in the browser extension context menu, I always get the credentials connected to Portal NO.
  4. Hi everyone, I'd like to recommend that previous versions of the browser extension be available in the extension stores. As a company with what will be a fairly large user base, we have the need to have a stable platform where dev/test/prod pipelines and proper change management can take some time. That time may exceed the duration from when a new version of the extension is released to when we can update the backend platform. The impact of having the extension automatically update and become non-functional because the main platform has not be updated is problematic. Perhaps maintain something like this: Passwordstate-Latest Passwordstate-Previous Even if you provide just the last released version (i.e. you don't need to support every previous version, just the last one as this will still help encourage keeping the platform up-to-date) in the stores, we can at least provide a method (tell them to install the previous version) to our users to keep them working easily. It's still not a great user experience, but better than having to expedite platform level updates because of a browser plugin. I'd really like to avoid lots of helpdesk tickets because the auto-population stops working. I'd be open to other solutions as well but I figured I'd at least propose something to start with. Happy to expand on the idea if needed. Thanks.
  5. Hello, I tried to see if this issue has already been brought up but did not find anything. It has been brought to my attention, the following scenario: A user browses a website, lets say "https://portal.office.com" where they have a password entry saved in their private password list. We also have a high number of shared passwords that have the same URL. When the user browses "https://portal.office.com" the auditing log shows that the user "retrieved password" for every password we have in the database using that URL. I feel that this process should be revised (assuming it has not been yet as we have yet to update to the latest version). There shouldn't be an audit entry stating that the password was retrieved unless it was actually pulled and used. Maybe pull a list of titles/usernames and audit that but not the actual password unless it is intended to be used by the end user. This fills up the auditing log and could cause for some confusion when a user is showing tons of password pulls when they did not intentionally do so. Has anyone else run into this? Thank you.
×
×
  • Create New...