This is definitely a valid enhancement.

This implementation might work in most instances but there is a fundamental weakness in that you are really trying to leverage the same fingerprint for two different applications that do not inherently share the same authorization base.

As an example, imagine that a Tomcat instance has user mymanager in role manager-gui and also user myadmin in role admin-gui and let's assume that these are hypothetically Tomcat default accounts.

1. According to your code, the script will first probe path /manager/html/ and finds user mymanager.
2. It will flag this path as correct for this Tomcat instance.
3. It will not find user myadmin on path /manager/html/ because it does not have the appropriate role.
4. The script finishes the testing of default users in the fingerprint, never proceeding to probe the rest of the paths, hence never finding myadmin.

A better approach might be to split the fingerprint into two, which is what I have in my NNDefaccts fingerprint set:

1. The script will first test the fingerprint for Manager against path /manager/html/ and finds user mymanager.
2. It flags this path as correct for this Tomcat Manager instance.
3. It will not test for user myadmin on path /manager/html/ because it is not part of this fingerprint (and even if it were, it still lacks the appropriate role).
4. The script finishes the testing of default users in the fingerprint, never proceeding to probe the rest of the paths.
5. The script then moves onto the fingerprint for Host Manager.
6. It finds user myadmin on path /host-manager/html/.
7. It flags this path as correct for this Tomcat Host Manager instance.
8. The script finishes the testing of the fingerprint for Host Manager.