Entry Based URL override is not honored

wellread1
2014-07-12
2014-07-16
  • wellread1
    wellread1
    2014-07-12

    The entry based URL override found on the entry's property tab is not honored by KPEnhancedEntryView. In standard KeePass, this override affects only the entry's URL field and takes precedence over all other overrides and defaults.

     
  • AlexVallat
    AlexVallat
    2014-07-12

    Just trying to get an idea of what sort of behaviour would be useful here. The way I understood it was that the URL override was an override for the behaviour of the entry as a whole, so if I right click on an entry and choose URL->Open.

    Are you saying you want it to apply to individual fields too? So rather than showing the links that are actually in the field, it should have links to whatever is in the Override property?

     
  • wellread1
    wellread1
    2014-07-12

    I propose that KPEnhancedEntryView URL field behavior track the Entry View pane URL field behavior in Standard KeePass when an entry level override is defined on the entry's property tab.

    Example (no workspace URL overrides are defined):

    • A user's default browser is FireFox.
    • The user creates an entry for gmail with URL field https://mail.google.com and sets the entry's override to cmd://{GOOGLECHROME} "{URL}" on the entry's property tab.

    Current behavior with KPEnhancedEnhancedEntryView installed.

    • When the user double clicks on the URL field in the KeePass List View pane, gmail opens in Google Chrome, as specified by the entry URL override.
    • When the user clicks on the URL field in the KPEnhancedEnhancedEntryView pane, gmail opens in FireFox; the specified entry URL override is ignored.
    • When the user clicks on a different URL (e.g. https://www.amazon.com in Notes), the URL opens in FireFox; the entry URL override does not apply.

    Desired behavior with KPEnhancedEnhancedEntryView installed and current behavior in KeePass.

    • When the user double clicks on the URL field in the KeePass List View pane, gmail opens in Google Chrome, as specified by the entry URL override.
    • When the user clicks on the URL field in the KPEnhancedEnhancedEntryView pane, gmail opens in Google Chrome, as specified by the entry URL override.
    • When the user clicks on a different URL (e.g. https://www.amazon.com in Notes), the URL opens in FireFox; the entry URL override does not apply.
     
    Last edit: wellread1 2014-07-12
  • AlexVallat
    AlexVallat
    2014-07-12

    I see, so it would only affect the actual standard URL field, and it wouldn't change the URL as displayed, but if you clicked on that URL to follow it (or right clicked and choose to open it, presumably) it will follow the override URL instead of the one shown. I guess that could work, sure.

    I suppose the best approach would be that if the standard URL field link is followed in KPEnhancedEntryView, it should just ignore that and request KeePass to follow the URL for the Entry using it's normal mechanism (as if from the list view), that way all overrides should be applied in the normal way.

     
  • wellread1
    wellread1
    2014-07-12

    ...so it would only affect the actual standard URL field,...

    Correct, it would apply only to the entry's "URL field".

    I suppose the best approach would be that if the standard URL field link is followed in KPEnhancedEntryView, it should just ignore that and request KeePass to follow the URL for the Entry using it's normal mechanism (as if from the list view), that way all overrides should be applied in the normal way.

    Correct. The reasoning is that KPEnhancedEntryView is a Viewer, and shouldn't deviate from KeePass defined behavior without good reason.


    I hadn't considered the case of Workspace defined URL overrides prior to your comment. I see that KPEnhancedEntryView does not honor these overrides either.

    While the same reasoning as above applies to KeePass defined URL overrides of custom string values containing URI schemes; an important change, described below, was made in KeePass 2.27 that should be taken into consideration and would affect any implementation. In general custom string values are not handled in KeePass locations except when they appear in the Entry View pane. In that case KeePass applies the Workspace URL overrides defined in 'Tools>Options>Integration(tab)>URL Overrides...'.

    However, for KeePass 2.26 and before, a typical built-in override option for https was: cmd://{GOOGLECHROME} "{URL}" This lead KeePass to process URLs defined in custom string values using the URL in the entry's 'URL field' which had undesirable side effects. For example if an entry's URL field contained https://google.com and a custom string value in the same entry contained https://amazon.com, when a user clicked on the amazon link in the Entry View pane, the google page would open instead. This was because KeePass processed the request using the override containing "{URL}".

    Beginning with KeePass 2.27 a new {BASE} placeholder was added and a typical built-in URL override option for https is: cmd://{GOOGLECHROME} "{BASE}". As a result, when custom string fields are handled by KeePass now, they use the URL the user is expecting (i.e. defined in {BASE}).

    Obviously, it would not be appropriate for KPEnhancedEntryView to honor Workspace overrides in KeePass 2.26 and earlier, but it would be appropriate for KeePass 2.27.

    Finally, I don't think overrides are particularly widely used, but those users that do use overrides are likely to notice the difference in behavior between standard KeePass and KPEnhancedEntryView. Particularly because the increased accessibility of custom string KPEnhancedEntryView encourages their greater use.

     
  • AlexVallat
    AlexVallat
    2014-07-13

    Thanks for all the information. Doing some testing with KeePass' standard entry viewer, the current behaviour appears to be that the option "Override all entry URLs" is not applied to anything other than the entry URL (and then, only if the entry override is not set). The option to override schemes, though, is.

    So, I'd suggest keeping consistency with that behaviour and having scheme overrides apply to custom fields that contain URLs, but the master override and entry override apply only to the standard URL field.

    I don't really want to have different behaviours dependent on the version of KeePass, so I think the best thing to do would just be to recommend upgrading to 2.27 if you use scheme overrides and they aren't working the way you want them to.

    Here's a preview of 0.27 with fixed up override handling for the URL field. I think it should do the right thing for all cases now, or at least a thing that might be considered right for most use cases.

     
  • wellread1
    wellread1
    2014-07-13

    It will be a few hours before I can test the plugin or review your complete post, but I do have one comment now.

    I have noticed that the entry override in KeePass also applies to custom string fields that contain the same URL. There are some subtleties in the matching criteria that suggest this is This may be by design e.g.

    If the entry URL is http://keepass.info/help/kb/testform.html
    Then an entry override will apply to a custom field containing:

    http://keepass.info/help/kb/testform.html
    https://keepass.info/help/kb/testform.html

    but not:
    https://keepass.info/help/kb/testform.html
    http://keepass.info/help/base/index.html
    ftp://keepass.info/help/kb/testform.html

    Perhaps this behavior should be confirmed as by design with Dominik.


    Update: In the example I described above where the URL is http://keepass.info/help/kb/testform.html, the matching behavior appears to be influenced by factors I have not identified yet. Hence for the case of a custom string containing:

    https://keepass.info/help/kb/testform.html

    1. entry override does not occur in KeePass 2.27 with default settings.
    2. entry override does occur in a KeePass 2.27 development snapshot with some other plugins (future KeePass 2.28).

    Update 2: The original finding was in error. I had set an override for the 'https:' scheme that I neglected to clear. Corrected findings are above.

     
    Last edit: wellread1 2014-07-13
  • wellread1
    wellread1
    2014-07-13

    Thanks for all the information. Doing some testing with KeePass' standard entry viewer, the current behaviour appears to be that the option "Override all entry URLs" is not applied to anything other than the entry URL (and then, only if the entry override is not set). The option to override schemes, though, is.

    That agrees with my findings with the identical URL exception noted. I summarize the precedence that I found below:

    KeePass 2.27 with default settings.
    Order of precedence (highest first)

    1. An entry's 'Override URL' is scheme independent in the URL field (e.g. does not care about http:, https:, ftp:, etc.) and applies only to the entry 'URL field' and 'identical URLs' in all fields including custom strings (also Title, Username, Password, Notes).
    2. 'Override all entry URLs' are scheme independent and apply to all entry 'URL fields', and identical URLs in all fields including custom strings.
    3. Custom (workspace) 'URL overrides...' are scheme dependent and apply to all entry 'URL fields' in all fields including custom strings.

    So, I'd suggest keeping consistency with that behaviour and having scheme overrides apply to custom fields that contain URLs, but the master override and entry override apply only to the standard URL field.

    See the 'identical URL' exception above that pertains to the entry's 'Override URL' and 'Override all entry URLs'.

    I don't really want to have different behaviours dependent on the version of KeePass, so I think the best thing to do would just be to recommend upgrading to 2.27 if you use scheme overrides and they aren't working the way you want them to.

    Makes sense to me.

    Here's a preview of 0.27 with fixed up override handling for the URL field. I think it should do the right thing for all cases now, or at least a thing that might be considered right for most use cases.

    I tested the plugin, everything behaves as you intended in my test. I have also posted a query at the KeePass forum requesting confirmation that the 'identical URL' matching behavior described above is intended.

     
    Last edit: wellread1 2014-07-14
  • AlexVallat
    AlexVallat
    2014-07-14

    Thank you. For the identical URLs thing, reading the source I strongly suspect that the reason for this behaviour is that in the standard entry view there is no other way of determining whether the link clicked on is the URL field or not. All that is reported is the destination of the link, so if it matches the value of the URL field then it is treated as such.

    KPEnhancedEntryView is not subject to the same limitation, as it knows whether the link clicked was the actual URL field or not.

    I will wait and see if Dominik answers your post in the KeePass forum before publishing 0.27 - if necessary, the KeePass behaviour can be duplicated fairly easily.

     
  • wellread1
    wellread1
    2014-07-14

    As a user I am happy if I can express the expected outcome of clicking a URL as a simple rule.

    • The KPEnhancedEntryView rule is simpler and easily understood.
    • The KeePass rule is surprising and a little confusing at first, but ultimately has good logic (a URL should behave the same throughout the entry).

    Either way is good for me.

     
  • wellread1
    wellread1
    2014-07-14

    By the way, KeePass includes a drop down list of suggested entry overrides. You might want to add that to the URL overrides on your Property sheet.

     
  • wellread1
    wellread1
    2014-07-14

    There is an an opportunity that has not been considered.

    KPEnhancedEntryView could replace the limited KeePass URL based 'Entry Override' with a Scheme based 'Enhanced Entry Override' that applied to a particular protocol (or protocol and its secure variant). It would probably require the KPEnhancedEntryView add a couple of custom string values or create plugin provided placeholders.

    Just a thought.

     
  • AlexVallat
    AlexVallat
    2014-07-15

    I think I will keep it as having separate behaviour for the URL field and the other fields, then - it is easier to understand, and if the user wants the entry URL behaviour then they can just click on that field instead of the custom one.

    If I can obtain the list of suggested overrides from KeePass, I'll add that, sure.

    I'm not sure I understand what you are asking for with your latest post, though - isn't that what's already provided by the scheme based overrides in the options dialog? I don't really want to start adding special field values to entries if I can possibly avoid it, I'd rather KPEnhancedEntryView just provided a nicer UI over existing data.

     
  • wellread1
    wellread1
    2014-07-15

    I think I will keep it as having separate behaviour for the URL field and the other fields..

    That sounds good to me.

    I'm not sure I understand what you are asking for with your latest post, though - isn't that what's already provided by the scheme based overrides in the options dialog?...

    Your comment that "KPEnhancedEntryView is not subject to the same limitation, as it knows whether the link clicked was the actual URL field or not." and my testing, got me thinking about what an improved entry override would do. In the original example, the user's default browser is Firefox but the user wishes to use Google Chrome for gmail. In this situation it is likely that the user also desires all URLs in the entry be opened with Google Chrome.

    A limitation of a scheme based workspace override is that it is not portable, because custom URLs in the database break in any workspace that don't know about the custom scheme (e.g. if a scheme 'chrome' were defined that opened every URL beginning 'chrome://' with Google Chrome). On the other hand assigning a standard protocol in a scheme extends the reach of the override to all URLs in the workspace. Not what the user desires.

    The limitation of the current entry level override is that it applies to the URL field only, or if its bent, to identical URL's also. Overriding the URL field alone, or the 'URL identical URls', addresses only ~75% of the user's desires.

    If a plugin provided one custom string field, to specify a range of protocols that the entry override should apply to, the reach of the entry override could be extended to a wider range of entry URLs in a manner that a user would understand. The approach is also portable because overloading the built in entry override field simply causes the scope of the override to become limited to the KeePass rule: 'URL + identical URLs' in any workspace where KPEnhancedEntryView is absent. Other URLs would revert to the default handler. I expect the most common protocol range would be http|https, but the user could define other ranges.

    One disadvantage of the proposal is that a custom string field is required. However if the field were managed by the plugin so that it was only present when populated, and removed if empty it seems like a reasonable cost. Ideally the custom string name would sort at, or near the bottom of, any string field list. It should also be readily identifiable as originating from the KPEnhancedEntryView plugin.

    This expansion of the Entry Override could be introduced at any later point if it was seen as desirable, so it may not be something to consider until demand becomes apparent.

     
    Last edit: wellread1 2014-07-15
  • AlexVallat
    AlexVallat
    2014-07-16

    OK, I understand what you're getting at now. I'm afraid I really don't like it, as a feature, though. If there seem to be enough people who really really want some way of setting a browser to use on a per-entry basis then it might be worth taking a look at that from one step back, and asking if URL overrides are really the best way to offer that.

    For the moment, I think right clicking on a URL and choosing to open it with a specific browser is good enough.