Ignore strings in window title to reduce ambiguity for auto-type (Google Chrome)

k-m-c
2014-04-28
2016-12-13
  • k-m-c

    k-m-c - 2014-04-28

    I am, similar to other users, struggling using the auto-type feature in Google Chrome with conflicting "Google" entries in the database, since any "Google" title entry always matches with the "* Google Chrome" window title of the browser.

    I am aware of the workaround of adding custom target windows in the auto-type tab. But since every google product (drive, gmail, etc) has a different window title, also differing for multiple languages, and I have several google accounts, this solution doesn't seem practical.

    My suggestion for a more generic solution would be the use of "ignore strings" that could be entered globally (i.e., always ignore "Google Chrome", "Mozilla Firefox", etc) or with a special character in the title field (for the example above: Google -"Google Chrome"), similar to the target window filters

    Is this technically feasible?

     
    Last edit: k-m-c 2014-04-28
  • wellread1

    wellread1 - 2014-04-28

    The major difficulty that I see is that adding target window matching options (e.g. 'ignore strings') to the 'Entry Title-Window Title' matching feature increases the complexity of a feature that is intended to be very simple. Custom auto-type is the feature designed for maximum flexibility.

     
  • k-m-c

    k-m-c - 2014-04-28

    I see your point, but contrary to the custom auto-type feature, the "ignore strings" would not even require a dedicated dialog/form. Just the added functionality and an additional paragraph in the help file. Keepass is made for the power user anyway ;)

     
  • wellread1

    wellread1 - 2014-04-28

    ...the "ignore strings" would not even require a dedicated dialog/form. Just the added functionality...

    Where would you prefer to see the 'ignore strings' setting?:

    Applied to the Workspace (Tools>Options)
    Applied to the Database (File>Database Settings...)
    Applied to Groups (Edit>Edit Group)
    Applied to Entries (Edit>Edit/View Entry)

     
    Last edit: wellread1 2014-04-28
  • k-m-c

    k-m-c - 2014-04-29

    good question... In my case, a Group setting would be sufficient (hierarchically) and most efficient (i.e., not having to edit every entry in the group)

    If it's easier to implement, a Database or Workspace setting should work fine as well.

    Thanks for your fast response! Where's the donate button? :)

     
  • wellread1

    wellread1 - 2014-04-29

    If it's easier to implement, a Database or Workspace setting should work fine as well.

    Thanks for your fast response! Where's the donate button? :)

    I think you might misunderstand. I am a user, nothing more.

    You can donate to KeePass at http://keepass.info/donate.html


    I remain skeptical of the overall utility of the proposed feature.

    The proposed feature would save some auto-type configuration for the specific case of 'Google' accounts but not much else, because the other browser tab suffix terms: 'Firefox', 'Explorer', 'Mozilla', 'Chrome', 'Internet', 'Google Chrome', 'Mozilla Firefox', or 'Internet Explorer', etc. are not especially common in Window Titles outside of the suffix.

    For the specific case of Google Accounts the Sign in page in the US is usually 'Sign in - Google Accounts'. There are a variety of ways to parse this Window Title to create a meaningful Entry Title that will match a broad number of Google sites but won't be triggered by the browser suffix '- Google Chrome'. Foreign sites are an additional challenge. If you don't want to use custom auto-type, which I would favor, you can use the Duplicate Entry option (Edit>Duplicate Entry) and select 'Replace usernames and passwords by references' to create entries that match the Title in the language of your choice and link to the username & password of a primary entry containing the actual username & password.

    It has been my experience that identifying the cause of unexpected Window Title matches is more difficult when there are multiple Window Title matching schemes active. The proposed Group level scope creates a situation where an entry's Window Title matching behavior changes simply by moving it into or out of a Group where the proposed 'ignore strings' feature is active. This level of indirection is certain to create confusion among less sophisticated users. Also, many users will use a feature even if they don't understand its full implications. Other users may just forget the feature is active in a particular group.

    Finally any change that requires the database to include additional built-in fields (e.g. the strings to ignore & on/off check boxes) will likely require a database format change. Format changes can create compatibility and forced upgrade issues .

    Note: I prefer to disable Entry Title matching and rely on Target Window matching exclusively i.e. custom auto-type just to keep the Window Title matching schemes as simple (restrictive) as possible. A user who uses very generic Entry Titles such as 'Google' is forgoing the advantages of the more descriptive titles that are possible when Entry Title matching is abandoned in favor of custom auto-type.

     
    Last edit: wellread1 2014-04-29
  • A. K.

    A. K. - 2014-04-29

    In KeePass 2.x you can use regular expressions to define target window pattern. For my Google accounts, I defined the following expression:

    //Google(?! Chrome)//
    

    This will not propose Google login for every page opened in Chrome.

    If you need, you can add to that more patterns, to support Gmail, Youtube, Blogger, Analytics and whatever you use with your Google account.

     
    • k-m-c

      k-m-c - 2014-04-30

      Cheers! That does the trick. I read about the regexp but did not understand that I have to use them in the target window field...

      Thanks a lot!

       
  • Suncatcher

    Suncatcher - 2016-12-13

    Cool expression, thumbs up!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks