URL Recognition Problem?

[owlcroft]

I hope this will not be another demonstration of my ignorance.

Here is the problem:

1. Go to web page at http://zoompanel.com/
2. Click on "Login"; that takes one to the page at http://zoompanel.com/pointsLogin.asp

That page contains a login box that is a frame, but--so far as I can see--the only one (that is, there do not seem to be any nested ones).  The frame URL is:
   http://www.ztelligence.com/start/servlet/Login?pid=100019350&ntarget=nf_rewards&language=en&country=us

3. PWM populates the login boxes with the default userid (and what is presumably the corresponding pw).

The problem is that, so far as I can see, this should be recognized as a Custom account.  My PWM URL settings for the account are:

URL to calculate PW: zoompanel.com
Pattern to match: *://*.zoompanel.com/*

The "Extended" tab has a custom username entry, whose absence in the login userid box is how I deduce that the URL has not been recognized.

I tried adding a second pattern--

*://*.ztelligence.com/*

--to the pattern matching to try to pick up the frame, but that made no difference.

What might I be doing wrong here?

And thanks.

[[email protected]]

Additional datum:

Changing the pattern so as to eliminate wildcards makes it work.  That is--

URL pattern = http://zoompanel.com/pointsLogin.asp

--does correctly bring the custom userid and corresponding pw.

I then discovered that a trailing wildcard is OK-this works:

URL pattern = http://zoompanel.com/*

Curiously, so does this:

URL pattern = *://zoompanel.com/*

But still not this:

URL pattern = *://*.zoompanel.com/*

Thinking back, it seems to me that in my hurried re-setting of numerous pws at various sites, I saw some such behavior elsewhere, but regrettably did not record it.  But I am tolerably sure that this is not a one-off situation.

Could the *. fail in certain cases if there is no subdomain prefix at all?

[Eric H. Jung]

Could the *. fail in certain cases if there is no subdomain prefix at all?

This certainly could be a bug. Let me see if I can reproduce it. Thanks for the step-by-step instructions on how to do so. Internally, wildcard patterns get converted to regular expressions. Specifically, * is translated to .* IIRC. Perhaps the // before this is changing the expression inadvertently. I'll re-post here when I know more.

[tanstaafl]

Not a bug...

the problem is in the pattern...

Change: *://*.zoompanel.com/*

to

*://*zoompanel.com/*

Although this is very insecure...

[owlcroft]

Not a bug...

the problem is in the pattern...

Change: *://*.zoompanel.com/*

to

*://*zoompanel.com/*

Although this is very insecure...

Ah.  The problem, then, is the dot.  Thank you.

Can the dot be escaped, or do I have to go to regex to deal with the issue?  (I suspect I know the answer, but reckon I'll ask anyway.)

Meanwhile, I guess I can just leave it "hardwired" to use no subdomain, and hope the site keeps its URL as is.

Thanks again.

[Miquel 'Fire' Burns]

Have both *://*.zoompanel.com/* and *://zoompanel.com/* as patterns if you're going to use Wildcards.

[Eric H. Jung]

Perhaps the // before this is changing the expression inadvertently. I'll re-post here when I know more.

Duh. This could only have been a possibility if those were backslashes, not forward slashes. Thanks for the clarification, guys.

Can the dot be escaped, or do I have to go to regex to deal with the issue?  (I suspect I know the answer, but reckon I'll ask anyway.)

The dot doesn't need to be escaped. The only "special" characters in wildcard patterns are "*" and "?". The URL you're trying to match (http://zoompanel.com doesn't have a dot in front of it.

Change: *://*.zoompanel.com/*

to

*://*zoompanel.com/*

Although this is very insecure...

He could instead use *://zoompanel.com/* ... that's not insecure.

Have both *://*.zoompanel.com/* and *://zoompanel.com/* as patterns if you're going to use Wildcards.

Yep. Agreed. This will "future-proof" you in case they add a subdomain in the future, while still match today's URL with no subdomain (note, by the way, that www.zoompanel.com appears to work just like zoompanel.com)

[tanstaafl]

By the way...

This is a good example of why I believe that implementing a new basic/advanced security model as described here (that I'm still waiting on a reply from adamspiers (and Eric) before adding to the FR list) is a good idea...

It will do away completely with all of the common newbie mistakes dealing with Custom Accounts and Pattern Matching. It provides an automatic, very secure default/basic security mode for Custom Accounts - essentially it just provides the same level of protection as the 'Defaults' (the user doesn't have to create any URL patterns at all), and will suffice for most people - even paranoid people (I'd probably use it for everything myself) - while also providing the current Pattern Matching functionality ('URL' Tab) as an 'Advanced' mode for those who like doing it themselves.

Creating Custom Accounts will be much easier, and the learning curve for using PWM will drop considerably.