Monthly Archives: September 2020

The Disambiguator (A KeePass Plugin)

0
Posted by admin on September 25, 2020 – 2:03 pm
Filed under Uncategorized

The TLDR;

For the impatient crowd šŸ™‚

  • Download The Disambiguator KeePass plugin here.
  • Unzip it and place the PLGX file in the KeePass “Plugins” folder, just like any other plugin.
  • Restart KeePass. You should see a “Compiling Plugins” notice and then KeePass should start normally.
  • In KeePass, click “Tools”, “Plugins” and verify that The Disambiguator is now in the list of loaded plugins.
  • Edit the AutoType entry for a credential set that has an ambiguous Window Title.
  • add “{exe:nameOfExecutable}” (without doublequotes) at the end of the WindowTitle. Replace nameOfExecutable with the filename of the Executable program file that the Target Window belongs to. In the case of Quicken, for instance, that would look like {exe:qw.exe}

Now open your target application and use AutoType as you normally would. If everything is set right, KeePass will now automatically select the appropriate credentials for the target window using both the Window Title and the application executable.

Introduction

I’ve used the password manager KeePass for a very long time. Excellent, simple, clean install, low resource usage and fast.

Editing a Credential Set in KeePass

The AutoType support, while possibly not quite as simple as some full commercial packages, is quite flexible and has never let me down.

Well, almost never.

KeePass’s AutoType feature works by allowing the user to enter one or more “Window Titles”, which it then compares against the target window when you user presses the AutoType hotkey.

When only one configured Window Title matches the Window Title of the target window, KeePass automatically can choose that single set of credentials, and perform the autotype. It’s almost like magic!

Editing An AutoType Entry in KeePass

Trouble Ahead

But, what happens when there are 2 or more credential sets that have the same Window Title?

For instance, both Quicken and Exodus request the user to login via a login screen with the Window Title “Enter Password”.

If you’re “responsible” with you passwords, and we all are as KeePass users (right?!), then you’re not using the same credentials (username and password) for two different applications. This means you likely have two different sets of credentials stored in KeePass: one for Quicken and one for Exodus. And you’ve setup AutoType for both.

But there’s the rub. Both sets of credentials have AutoType setup to key on the Window Title of “Enter Password”, as they must.

The KeePass Credential Chooser

Unfortunately, when you have, say, the Quicken Login window displayed and press the KeePass AutoType hotkey (normally Ctr-Alt-A), KeePass discovers 2 sets of credentials (and possibly more) that match. Because it can’t magically decide which to use, it pops up the Credential Chooser dialog so that you, the user, can make the choice.

This is all fine and good, but it can be a bit of a pain, and it forces the user to make a choice when the choice should be automatic.

Enter The Disambiguator

The problem here, of course, is disambiguation. Using the Window Title as the only “disambiguating” factor is ok most of the time, but, as the above example shows, it’s not always quite enough to completely identify a single specific credential set to use for autotype.

Alex Vallat has a very nice plugin for KeePass called WebAutoType which specifically allows users to configure matching URLs for autotype entries. This will almost always provide enough uniqueness to properly match a single credential set for Web Pages. But unfortunately, it does nothing for normal desktop apps like Quicken or Exodus.

That’s where The Disambiguator comes in.

to be continued

Automation Virtual Conference

0
Posted by admin on September 21, 2020 – 2:44 pm
Filed under Uncategorized

Ok. I’m not one to typically post notices Re: my employers, but I thought I might make the few readers I have, aware of an upcoming virtual conference that Worksoft is having on testing and robotic process automation on Oct 28.

Click here to learn more.

Troubles with Nuget v5.7

0
Posted by admin on September 16, 2020 – 9:16 pm
Filed under nuget
Tagged as

I’ve worked with Nuget for quite some time, both consuming published Nugets as well as creating Nugets to be published.

But I ran into a pretty vexing series of issues today, that, from what I can tell from the posts I found by Googling, might be affecting a lot of other users.

To begin with, I was running an older version of nuget.exe, ver 4.9. So, I dutifully updated to v5.7 and still had the same issues.

My first problem was this lovely message:

Illegal characters in path.
System.ArgumentException: Illegal characters in path.

After far far too much experimentation, I discovered that putting the project filename, the nuspec filename or the output directory filename in double quotes, was the problem.

In other words, this:

nuget pack ".\myapp.csproj" -Verbosity Detailed -OutputDirectory ".\bin\Release\"

won’t work. But this:

nuget pack .\myapp.csproj -Verbosity Detailed -OutputDirectory .\bin\Release\

works just fine.

Unfortunately, if your project’s path happens to contain spaces, you won’t be able to specify the path properly. I haven’t investigated any way around that.

But wait, there’s more!

That got me past the “Illegal characters in path” error, only to be greeted by this:

Authors is required.
Description is required.
System.Exception: Authors is required.
Description is required.

In my case, I was using a pretty standard nuspec file, something like this: 

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd" >
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$company$</owners>

It turns out there were two issues here:

  1. Ignore the error message. It’s terrible because, first, the xml element is <authors>,Ā not <Authors> as the message implies. And second, the tokenĀ is actually $author$ (singular), not $authors$ or $Authors$ or even $Author$.
  2. But much weirder was that it failed like this because I was actually specifying a relative path to nuget.exe, like so:
    .\nuget\nuget packĀ blah blah

Yeah, you read that right. Believe it or not, that relative path somehow causes nuget to fail to resolve tokens in the nuspec file!

I put the nuget.exe in the same folder as my nuspec file and it worked!

So I moved nuget.exe to a folder that was on my PATH, and that worked as well!

So then I tried to fully specify the drive, folder and filename to the nuget.exe and that failed also.

Very bizarre.

I did come across a number of nuget bug reports indicating that it has problems if you rename the exe. That in and of itself is concerning and just plain weird.

But my guess is it’s trying to open the assembly via reflection, failing, an d short circuiting execution, skipping someĀ very necessary code in the process. Regardless. Back in operation finally!