subdomain URL matching doesn't work and other issues

[adamspiers]

Hi Eric,

Thanks a lot for a great extension.  I've read a LOT of the help available on the website, but I'm still having problems understanding how the URL matching algorithm works, and I find other aspects of the interface quite confusing.  This long post is not a rant or complaint, I just want to help you make a great extension even better :-)

For example, I want to apply a modifier to multiple subdomains of the same domain:

   subdomain1.mydomain.com
   subdomain2.mydomain.com

etc. regardless of the protocol/port/path/anchor/query.  I have been testing with 1.6.1.  I thought it would be enough to create an account with the name 'mydomain.com' which had the modifier set, but this never matched - all subdomains used the default settings.  I also set 'Use the following URL to calculate the generated password' to 'mydomain.com' but this didn't help either.  It's not clear to me which one is supposed to be used in the matching process - 'Name' sounds like it's just a label, and 'Use the following URL to calculate the generated password' sounds like it only affects calculation (not matching) of the current browser URL with this account.

The only way I ever could get it to match and apply the modifier was by explicitly adding a regexp pattern:

   https?://[^/]+\.mydomain\.com/.*

to the pattern list entitled 'Activate auto-population when the URL of a webpage matches any of the following patterns', even though I don't want auto-population to occur!  I only want population when I press the CoolKey (i.e. non-automatic - I suggest you change the sentence above it to read "Population can also activated using CoolKey", since it's confusing to say that *automatic* population can be activated *manually*).

Anyway, I hope you will say that this is a bug in the matching logic, because it would be deeply inconvenient to have to create a wildcard or regexp for every single account I create.

Nor was it clear to me whether the pattern list controlled whether population was automatic for only the extra fields in "Advanced Auto-Populate", or also for the username/password fields.  What is supposed to happen if 'Automatically populate username and password fields for sites that match this URL' is unchecked, but one of the wildcards/regexps matches this URL?  The wording suggests that in this case username/password fields will be automatically populated.

Furthermore, there really need to be at least two pattern lists per account, not just one.  Why?  Because there needs to be one to determine whether the account matches the current browser URL or not (and hence whether the account's settings should be applied), and then one to decide whether population of the custom fields in 'Advanced Auto-Populate' is automatic or not, so that for example, from a single account you could have manual population (CoolKey only) of

      http://subdomain1.mydomain.com/login
      http://subdomain2.mydomain.com/login
      http://myotherdomain.com/login

but automatic population of

      http://subdomain3.mydomain.com/specific/pa...rofile-settings

using custom fields (for phone number, address etc.)

If two pattern lists is asking too much, please bear in mind that URL matching the account is more important than controlling automatic/manual population, so the pattern list should affect matching.  You could easily move the automatic/manual population to be an option available in each custom field.

(In a perfect world you could even have multiple sets of custom fields per account, but that's probably going too far.)

Hope this is useful.  If you fixed the matching bug, improved the wording in the dialog boxes, and made a better distinction between options which control matching vs. options which control automatic/manual, you'd be well on the way to a perfect extension :-)

Thanks,
Adam

[adamspiers]

Any ideas on this?  Of the 8 bugs and feature requests I posted in December, this is the most urgent, as it makes multiple accounts damn awkward to use, especially for people who are concerned about security and don't know how to write safe regexps.

[Miquel 'Fire' Burns]

Here's some extra knowledge for your RegEx
Putting something like this will do a branching of different subdomains

Code: [Select]

(subdomain1\.|subdomain2\.|www\.)?
The complete RegEx may look like this:

Code: [Select]

https?://(subdomain1\.|subdomain2\.|www\.)?mydomain\.com/.*
The subdomain part can be reduced by combining the 1 and 2 (the code is like this:

Code: [Select]

subdomain[12]Though that last bit may not apply to you because the example just happens to be numbered, but the real life situation may not work this way.

[Eric H. Jung]

Adam,
Can you please distill your suggestions into some concise bullet points? I read your initial post about 5 times and am having a hard time focusing. I get the idea of two pattern sets, although I don't understand why you'd want to apply advanced auto-populate to patterns other than the ones specified on the URLs page.

thanks,
eric

[adamspiers]

Here's some extra knowledge for your RegEx
[...]

miquelfire - thanks a lot for trying to help, however creating the right regexp is not the issue here (I have been programming complex regular expressions for over 10 years now!) - in fact the core of the issue is that I believe I should not have to use any regexps or patterns to achieve what I want.

Adam,
Can you please distill your suggestions into some concise bullet points? I read your initial post about 5 times and am having a hard time focusing. I get the idea of two pattern sets, although I don't understand why you'd want to apply advanced auto-populate to patterns other than the ones specified on the URLs page.

thanks,
eric

Eric,

I did already put a lot of effort into trying to communicate this issue across in as concise and clear a manner as possible, but I obviously failed since neither of you understand what I meant!  It's a difficult one to explain, let me try again...

Imagine I want to register for a website http://www.acme.com/ but the registration process at https://login.acme.com/ only allows letters and digits in the password.  So I open the PasswordMaker window, select the Accounts tab, and create a new account.  In the URLs tab I see it has automatically detected the correct value of 'acme.com' for "Use the following URL to calculate the generated password".  So far so good.  I click on the "Extended" tab and change the "Characters" field so it only contains letters and digits.  I click "OK", see that my new account has appeared in the list, and click "Close".  All is well, right?  Wrong!

PROBLEM 1: Creating an account has absolutely no effect without explicitly adding a pattern or regexp to match the site against.

I thought (perhaps mistakenly) that this was the point of the "URLs" tab in the "Defaults" account - I have only the "Domain" checkbox ticked, so I thought that if I created an account for acme.com, its settings would take effect on any subdomain, such as login.acme.com.  No?

There are several other problems, but this is the biggest, so for sake of simplicity shall we try to deal with this one first?

Thanks for your time,
Adam

[Miquel 'Fire' Burns]

Ah! That bit.

Maybe PasswordMaker should make a RegEx or something that allows it to match to what the default would be (In the above example, https?://([^/]\.)?acme\.com/.* if only domain was checked)

Actually, the default RegEx should be protocol independent as well if it wasn't selected in the default settings.

[Eric H. Jung]

I see. Why is Adam the only person who's requested this in PasswordMaker's 2-3 history? Is this really a gap in PasswordMaker, or is Adam using it differently than other people?

[Miquel 'Fire' Burns]

Because most of us using accounts so far had them made before the new URL pattern feature and haven't actually made a new account yet.

[Eric H. Jung]

OK, well let's add this as a feature request... not a bug. Tanstaafl, can you add it?

[adamspiers]

OK, well let's add this as a feature request... not a bug. Tanstaafl, can you add it?

Thanks.  While I'm eagerly awaiting the new version (will gladly help with beta testing, by the way), please can you explain the point of the "URLs" tab in the "Defaults" account, since I was clearly mistaken that it would affect the domain matching algorithm?

[Eric H. Jung]

Thanks.  While I'm eagerly awaiting the new version (will gladly help with beta testing, by the way), please can you explain the point of the "URLs" tab in the "Defaults" account, since I was clearly mistaken that it would affect the domain matching algorithm?

It's there so you can define how to use auto-populate for default accounts, which was accidentally removed from the last release.

[adamspiers]

It's there so you can define how to use auto-populate for default accounts, which was accidentally removed from the last release.

Sounds interesting - but I don't understand at all!  Why would you ever need auto-populate for default accounts?  And how are the settings for URL components supposed to affect auto-population for default accounts?  Aren't URL components used to determine how to generate a password?  Whereas auto-population as I understand it has nothing to do with password generation.

[tanstaafl]

Ok, here we go... somehow, I completely missed this entire thread... sorry about that Eric...

Now...

Sounds interesting - but I don't understand at all!  Why would you ever need auto-populate for default accounts?

?

Enabling auto-pop on the Defaults simply causes a prompt for the MPW - or, if you have saved it to memory or disk, it simply auto-pops the username/password - for any form that contains what PWM detects as a username and/or password field, *and* whose URL does not match anything in one of your Custom Accounts (so will use the 'Default' account settings).

And how are the settings for URL components supposed to affect auto-population for default accounts?

They don't - they only affect what parts of the URL are used for password calculation...
I was actually kind of confused by Erics answer too...

[tanstaafl]

Eric - for purposes of this as a Feature Request...

It seems to me, after reading through this a few times, there are two parts to this...

1. Automatic URL pattern creation from the current URL when an Account is created, and

2. Automatic phishing protection.

It seems we've had a few discussions about #2... it has always been my position that the URLs that PWM uses to calculate passwords should *always* protect the user from phishing attacks.

When I add a URL as a pattern - or PWM does it for me when that feature is added - the parts of the URL that render it subject to phishing attacks should be automatically handled by PWM.

By this I mean...

If I manually add a URL right now as "*.mydomain.com", PWM should only allow VALID child URLs of mydomain.com... in other words, it should be the same as the regex Adam provided in his first post:

https?://[^/]+\.mydomain\.com/.*

Make this automatic protection optional, if desired, but I think it should be on by default, with a big fat warning if the user disables it.

I believe that satisfying both #1 (4th in the FR list with 9 votes) and #2 would completely resolve Adams concerns - and I think would be a huge improvement in the New User Experience (and old alike)...

So - Adam - did I read your concerns right? Or did I miss the mark completely?

[Eric H. Jung]

If I manually add a URL right now as "*.mydomain.com", PWM should only allow VALID child URLs of mydomain.com... in other words, it should be the same as the regex Adam provided in his first post:

https?://[^/]+\.mydomain\.com/.*

OK, but which do I use as the "master" pattern; i.e., the pattern against which all future patterns are compared to see if they are children?