Menu

Creation of case sensitive custom string fields in KeePass without KPEnhancedEntryView.

wellread1
2015-07-22
2015-08-16
1 2 > >> (Page 1 of 2)
  • wellread1

    wellread1 - 2015-07-22

    Recently while using KeePass with KPEnhancedEntryView plugin, I noticed that I was accidentally creating duplicate custom string fields that differed only by the case of characters in the string field name.

    While the problem is mostly related to use of KPEnhancedEntryView, I noticed during testing that it is possible to reproduce the issue in KeePass alone by creating a new custom string field followed by a second case variation of the same string field name in the same entry before it is saved.

     

    Last edit: wellread1 2015-07-22
  • Dominik Reichl

    Dominik Reichl - 2015-07-22

    True, custom string names are case-sensitive.

    Best regards,
    Dominik

     
  • wellread1

    wellread1 - 2015-07-22

    But auto-Type does not treat custom strings as case sensitive. If case sensitive variants of a custom string field are present in the same entry [edit], auto=type sequence the behavior of auto-type can't be predicted.

     

    Last edit: wellread1 2015-07-22
  • Dominik Reichl

    Dominik Reichl - 2015-07-22

    Good idea, here it should favor the one with the same case. I've added it to my to-do list.

    Thanks and best regards,
    Dominik

     
  • T. Bug Reporter

    T. Bug Reporter - 2015-07-22

    here it should favor the one with the same case.

    Please clarify what you mean by this. If a custom field name isn't a case-sensitive match but a case-insensitive one does exist, do you intend to have it react as if no match at all was found, or have it assume the existing field name is "close enough"? (IMO, the latter would make it pointless to allow two different fields to have names identical except for case.)

     
  • Paul

    Paul - 2015-07-23

    Surely the behaviour will not change if there is a case insensitive match, only if there is a case sensitive match and there are two, or more, fields with the same name.

    What should happen if there are two fields and the case still doesn't match?

    cheers, Paul

     
  • wellread1

    wellread1 - 2015-07-23

    My feeling is that KeePass does an adequate job of preventing case variant string field names from being entered in the first place by coercing/validating the string field names upon entry. The real problem arises if plugins that allow creation or entry of string field names don't perform similar checks, and even then case variants are only a problem if a user uses the multiple variants in the same entry because the scope of auto-type is limited to the entry.

    My preference would be to encourage plugin developers to incorporate coercion/validation when entering string field names. If Dominik were to introduce general case sensitive auto-type matching (as opposed to selectively matching when case variants exist in an entry) there will be a lot of users with broken auto-type sequences, including myself. (e.g. {S:email} becomes different than {S:Email}, and {Username} is different than {USERNAME}). However, I suspect that Dominik's use of the word "favor" above means that he has anticipated this issue.

    Some additional thoughts are at https://sourceforge.net/p/kpenhentryview/discussion/general/thread/0ad7034a/#8daf.

     

    Last edit: wellread1 2015-07-23
  • Dominik Reichl

    Dominik Reichl - 2015-08-06

    I've thought a bit more about this, and don't see how the situation could be improved. In KeePass 2.x, placeholders by definition/documentation are case-insensitive (whereas entry string names are case-sensitive), and even if I'd add something like favoring same-case strings in {S:...} placeholders, there still would be undefined behavior (e.g. the already mentioned situation when a placeholder matches multiple times case-insensitively but not case-sensitively, or more complicated situations like when replacing {PASSWORD} and a string 'pAsSwOrD' being present, but no 'Password').

    Advice: don't use entry string names that only differ in case, if you want to use them in auto-type.

    Best regards,
    Dominik

     
  • Paul

    Paul - 2015-08-07

    Agreed.

    cheers, Paul

     
  • AlexVallat

    AlexVallat - 2015-08-07

    The question is, though, should entry string names that differ only in case be actually disallowed by KeePass? It couldn't be retroactive - databases which already had them would have to keep working, but it's an option to consider to prevent the creation of any new ones.

     
  • Dominik Reichl

    Dominik Reichl - 2015-08-08

    Ok, I've implemented this. The entry string dialog now does not allow adding a string whose name differs from another existing string name in this entry only by case. Furthermore, it now supports changing the case of a string name (useful for instance when you want to rename an 'e-Mail' field to 'E-Mail').

    Here's the latest development snapshot for testing:
    http://keepass.info/filepool/KeePass_150808.zip

    Note that I'm planning to release KeePass 2.30 tomorrow, so if you find something unexpected, please report it fast :-)

    Thanks and best regards,
    Dominik

     
    • T. Bug Reporter

      T. Bug Reporter - 2015-08-09

      I was surprised to see 1.29 still on the download page next to 2.30. Don't you usually release a "matching" 1.x version along with every 2.x - or did I just catch it between updates? (Not that it really matters to me, since I don't use the 1.x versions; just curious.)

       
  • wellread1

    wellread1 - 2015-08-08

    The new string field checking works nicely as far as my testing went.

    It took me a while to figure out what you meant by " it now supports changing the case of a string name (useful for instance when you want to rename an 'e-Mail' field to 'E-Mail'". My interpretation is rule 3 below.

    My understanding of the string field Entry Rules is:

    1. When a string field name is entered into an entry it must be unique in the entry on a case insensitive basis.
    2. When a string field name that already exists in the database (on a case sensitive basis) is entered into an entry, one of the pre-existing variants is used, i.e. if a variant that does not exist in the database is entered, it is silently coerced to an existing form.
    3. After the string field name is defined in the entry, it may be renamed to any case variant desired.

    Any attempt to enter a second variant of the same string field name (on a case insensitive basis) into an entry is prevented by rule 1.

     

    Last edit: wellread1 2015-08-08
  • Dominik Reichl

    Dominik Reichl - 2015-08-08

    Right. Thanks for testing it! :-)

     
  • AlexVallat

    AlexVallat - 2015-08-09

    I will also update KPEnhancedEntryView to disallow multiple custom fields on an entry whose name differs only by case, then. The only bit I'm not sure about is the behaviour when creating new fields. Of course it will suggest existing field names - but I don't get that if you choose to ignore the suggestion and enter a new field name with different casing, that it should then change it underneath you, making you edit it if that wasn't what you wanted.

     
  • Paul

    Paul - 2015-08-09

    My testing show some issues.
    1. Entering a name with different case to the existing is prevented as expected.
    2. Editing the existing after the new entry is created allows you to change the case, sort of expected, but there is no drop down so I can see what I've already got.
    3. Returning to the new entry the incorrect case still exists, but I can't see the original in the drop down anymore and I can change it to any case I want. See 2 above.
    4. Finding the entry with the original field is not possible with search.
    5. Now that I have two different cases, adding a new entry by typing offers only one version, but in my testing it converts to the version not shown in the drop down.

    cheers, Paul

     
  • wellread1

    wellread1 - 2015-08-09

    Paul,

    I agree, there do seem to be some rough spots that could be improved, and that I wasn't critical of in my first comments. These seem to be mostly associated with the pick list(s) failing to show all existing variants of a string field name, combined with the auto-complete feature. This behavior is similar to what existed previously, we just never examined it closely.

    I would be interested in understanding your point 4. I have never been able to figure out how to find a string field name using search.


    The new rule, that I called 1 above, achieves an important goal of preventing multiple variants of the same string field name into the same entry.

     
  • T. Bug Reporter

    T. Bug Reporter - 2015-08-09

    I have never been able to figure out how to find a string field name using search.

    Neither have I; that's one of the things I use the Fields Admin Console for. It doesn't do a search, exactly, but it puts all the field names in an easily scannable list.

     

    Last edit: T. Bug Reporter 2015-08-09
  • wellread1

    wellread1 - 2015-08-09

    KeePass 2.x and 1.x have similar release rates, but the releases are not synchronized. If you are interested you can look at the release history.

     
  • T. Bug Reporter

    T. Bug Reporter - 2015-08-09

    Oh. In the short time I've been paying attention, the 1.x and 2.x releases seemed to be similarly numbered and on a similar release schedule, so I just assumed it was intentional.

     
  • Paul

    Paul - 2015-08-10

    Point 4 was mentioned only because it's something you would want to do if you had mixed case across entries. TBR's use of FAC is the solution.

    cheers, Paul

     
  • T. Bug Reporter

    T. Bug Reporter - 2015-08-10

    I really need to get to bed. It took me almost five minutes to realize what you meant by "TBR's use of FAC".

     
  • Dominik Reichl

    Dominik Reichl - 2015-08-10

    @TBR: KeePass 1.x and 2.x are independent. KeePass 1.x existed long before 2.x and for a long time the x in 1.x was higher than the x in 2.x. As development now primarily occurs in 2.x, the minor version of 2.x now overtook the one of 1.x.

    @Alex: This is caused by the auto-completion. As far as I know, the only solution to prevent the case being changed automatically would be to disable auto-completion.

    @Paul/wellread1: Also caused by the auto-completion. If the current string name would be listed in the drop-down, the case could not be changed (like in previous KeePass versions; auto-completion would automatically change back the case to one of the variants in the drop-down list). I thought that being able to change the case would be more important than listing variants of the current string in the drop-down list again, but indeed seeing the variants would be useful in some situations...

    Should auto-completion be disabled? I'm not sure... When it is disabled, to use an existing string name users would need to select it in the drop-down list or enter it exactly (no automatic correction/completion anymore).

    Here's a development snapshot with auto-completion disabled (and listing all variants of the current string name again):
    http://keepass.info/filepool/KeePass_150810.zip

    Thanks and best regards,
    Dominik

     
  • Paul

    Paul - 2015-08-10

    I think auto-completion is the right idea, it's the implementation that is problematic. Maybe you could show all possibilities and allow the user to select any one, and also allow the user to continue typing and not change whatever was entered. This gives the user choice without imposition.

    cheers, Paul

     
  • Dominik Reichl

    Dominik Reichl - 2015-08-10

    Unfortunately the .NET Framework doesn't support that. By turning on auto-completion, you also get coercion to suggested variants.

    Best regards,
    Dominik

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.