#1873 WinUtil.OpenUrl() incomplete processing logic

[sambowry]

Thank You for the '-e' switch!

I think i found a bug in WinUtil.OpenUrl(). The "SprEngine.Compile()" use the "URL" field of the "peDataSource" parameter when it expands "{URL:...}" placeholders written into an "Url Scheme Override". This way it ignores the previously calculated value of the "strUrlToOpen" parameter.

Sketch of the wrong processing:

OpenUrl(string strUrlToOpen, PwEntry peDataSource)
    strUrlFlt = strUrlToOpen;
    strUrl    = SprEngine.Compile(strUrlFlt, new SprContext(peDataSource, ...));

    strOvr    = UrlSchemeOverrides.GetOverrideForUrl(strUrl);
    strUrl    = SprEngine.Compile(strOvr, new SprContext(peDataSource, ...));

The correction may looks like:
(2 lines added, one modified)

WinUtil.cs line: 163

  if( strOvr != null ) {
    bCmdQuotes = WinUtil.IsCommandLineUrl(strOvr);
+   PwEntry peOvr = peDataSource.CloneDeep();
+   peOvr.Strings.Set("URL", new KeePassLib.Security.ProtectedString(true, strUrl));
    strUrl = SprEngine.Compile(strOvr, new SprContext(
*       peOvr, pwDatabase, SprCompileFlags.All, false, bCmdQuotes));
  }

[Dominik Reichl]

The current behavior is intended, not a bug. The SprEngine must operate with the original entry URL, not any modified/compiled version of it.

Best regards,
Dominik

[sambowry]

I made a test with the KPEnchancedEntryView plugin. See the attached picture.
There are 3 URLs, each clickable. If i click on one, Internet Explorer will open the right page.

But if i enable the http {FIREFOX} override, when i click on the debian or on the fedora link, Firefox will open the ubuntu each time.

I think it is a bad behavior, but i accept that it is intended. I will ask Alex Vallat to repair his buggy plugin :-)

[wellread1]

I have confirmed the incorrect URL override behavior reported by sambowry in KeePass 2.26 without plugins:

If a particular protocol is overriden using a built in or custom override, then all URLs in an entry that use the protocol, resolve to the URL specified in the entry's URL field.

For example if the http protocol is overriden, and the entry's URL field contains:

• http://www.google.com, then all URLs in the entry's Notes or String Fields (e.g. http://www.amazon.com) will open http://www.google.com

• nothing, then all URLs in the entry's Notes or String Fields (e.g. http://www.amazon.com) will open: file:///KeePass program directory/

Note: URLs in String Fields were opened via the link listed in the Entry View, otherwise they don't open in KeePass without plugins.

[Dominik Reichl]

I see, but anyway this is no bug. The {URL} placeholder is well-defined: it is replaced by the current entry's URL. So, the behaviors in your examples are perfectly correct.

What we actually want is not the URL of the entry (i.e. {URL}), but the string that is being overridden. Thus I've now introduced new placeholders for this: {BASE} and {BASE:RMVSCM}. Treating {URL} like {BASE} (as suggested initially) would not be a good solution, because there are various situations where you really want the entry's URL, not the base string.

If the URL of an entry is http://www.google.com/ and you run http://www.amazon.com/ (with the same entry as context), within any override {URL} will be replaced by the Google URL and {BASE} by the Amazon URL.

I've changed all built-in URL scheme overrides to use the new {BASE} and {BASE:RMVSCM} placeholders.

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

Moving to closed feature requests.

Thanks and best regards,
Dominik

[sambowry]

Thank You! It would be nice to have all {URL:} placeholders as {BASE:} too. Additionally two other placeholders may help on writing URL Overrides: {BASE:USERNAME} and {BASE:PASSWORD}.

[Dominik Reichl]

Ticket moved from /p/keepass/bugs/1244/

[Dominik Reichl]

I've now added the following placeholders: {URL:USERINFO}, {URL:USERNAME}, {URL:PASSWORD}, {BASE:SCM}, {BASE:HOST}, {BASE:PORT}, {BASE:PATH}, {BASE:QUERY}, {BASE:USERINFO}, {BASE:USERNAME}, {BASE:PASSWORD}.

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

Thanks and best regards,
Dominik

[Anonymous]

I've noticed that these placeholders, along with some of the other ones added recently, are not yet showing in the Configure Keystroke Sequence window. Will they be there eventually or is there somewhere else I can find them for reference?

[Dominik Reichl]

Adding the {BASE...} placeholders to the auto-type sequence dialog would make no sense, because they can only be used in URL overrides, not in auto-type sequences.

However, they will be added to the placeholders help page, when KeePass 2.27 is released:
http://keepass.info/help/base/placeholders.html

{URL:USERINFO}, {URL:USERNAME} and {URL:PASSWORD} will be added to the auto-type sequence dialog for KeePass 2.27.

Best regards,
Dominik

[Anonymous]

Okay that makes sense. Thank you Dominik for the clarification!

[sambowry]

Thank You! I made a quick test:

{BASE}          = "test://user:pass@host:99/path1/path2?query"
{BASE:RMVSCM}   = "user:pass@host:99/path1/path2?query"
{BASE:SCM}      = "test"
{BASE:HOST}     = "host"
{BASE:PORT}     = "99"
{BASE:PATH}     = "/path1/path2"
{BASE:QUERY}    = "?query"
{BASE:USERINFO} = "user:pass"
{BASE:USERNAME} = "user"
{BASE:PASSWORD} = "pass"

Its perfect! :-)

I'm one step closer, but new difficulties arises because i must add a windows 'DOMAIN' before the username:

{BASE}          = "test://<b>DOMAIN\user</b>:pass@host:99/path1/path2?query"
{BASE:RMVSCM}   = "DOMAIN\user:pass@host:99/path1/path2?query"
{BASE:SCM}      = ""
{BASE:HOST}     = ""
{BASE:PORT}     = ""
{BASE:PATH}     = ""
{BASE:QUERY}    = ""
{BASE:USERINFO} = ""
{BASE:USERNAME} = ""
{BASE:PASSWORD} = ""

The result is strange because of the missing fields but backslash is not an RFC3986 compliant character of the 'userinfo' so i can't say that this result demonstrate a bug.

Thank You again!