Problems with ExactMatch

[erasmussen]

I am trying to use the web security databases to perform record-level access restriction for web users. I have a LogonID field and a Password field that I would like to use with the ExactMatch feature. ExactMatch works just as expected with the Password field, but is unreliable with the LogonID field.

Some LogonID values work as expected and allow access to the relevant records, while other LogonID values cause Web Companion to return an error message. If I disable the ExactMatch feature for the LogonID field, then all values of LogonID work when performing a -find to pull up the relevant records.

As far as I can tell, web companion 5.0v6 (windows) can't perform an exact match if the data in the field is longer than 20 characters. This is a problem, because I am trying to use our customer's email addresses as their LogonID, and some addresses are longer than 20 characters. A developer I work with suggested switching the indexing for the LogonID field to ASCII, because it contains the @ symbol. However, that did not solve the problem.

I take this to mean that web companion is using some sort of internal index value list or relationship to perform the ExactMatch, because relationships and index value lists only use the first 20 characters.

I thought of making a calculation that was the first 20 characters of the LogonID field, and using ExactMatch with the calculation, but then realized that the Exact Find part of the web request would fail (remember that the -find action works correctly with the full data). I never actually tried this approach, though, because I'm pretty sure it won't work.

I then upgraded to FileMaker 5.5 on the same machine, hoping to solve the problem. I even went so far as to use the new set of web security databases that came with 5.5 and recreated the database/users/field permissions. Unfortunately, it got worse. As far as I can tell, in 5.5, ExactMatch fails on any text with an @ in the data, even when the total text is less than 20 characters in length and I am still using ASCII indexing for the LogonID field.

Given the inconsistent behavior between ExactMatch and -Find, and the fact that it changed from 5.0 to 5.5, I'm tempted to report this as a bug to FileMaker. However, I thought that maybe I was missing something and would ask the experts here for help first.

Has anyone else experienced this problem? Does anyone have any workarounds?

[Anatoli]

Why do you need the "ExactMatch"?

[John May - Point In Space]

What happened when you changed the storage of the field to ASCII? Did you also turn off ExactMatch when you did this?

This has always solved the problem for me.

- John

[erasmussen]

quote:

---

Why do you need the "ExactMatch"?

---

I want to make sure that users can only access their contact information records by forcing all find requests to contain both a LogonID and password. The records being found all contain the LogonID and password values, which is how I find the correct contact records. If I do not use ExactMatch, then a saavy web user could easily construct a custom find request based on some other field (or even use -findall or -findany) and reveal information that they should not see.

quote:

---

Originally posted by John May - Point In Space:

What happened when you changed the storage of the field to ASCII? Did you also turn off ExactMatch when you did this?

This has always solved the problem for me.

- John

---

Turning the storage to ASCII had no effect. Turning off ExactMatch will allow the find request to work correctly (i.e. web companion can successfully find records with LogonIDs longer than 20 characters and containing the @ symbol). However, this removes a layer of security that I would like to maintain.

The point of ExactMatch is to allow record level security via the web, which is what I need in order to prevent customer contact information from being extracted by personal information thieves. Right now, I can do the ExactMatch based on password, but not password & LogonID, which *SHOULD* work. (Yeah, I know, "should" is a big word when it comes to computers.)

Anyway, ExactMatch is simply failing to work on some data, even though the same data works perfectly when actually using it to find records. As far as I can tell, ExactMatch is either broken, or this is an undocumented limitation of ExactMatch.

[John May - Point In Space]

Another way to force an exact match is to concatenate an "=" character to the beginning of your search term. This should force Filemaker to find only fully-matching requests (I know it works w/Lasso at least, not sure about CDML, but I don't see why not).

- John

[erasmussen]

quote:

---

Originally posted by John May - Point In Space:

Another way to force an exact match is to concatenate an "=" character to the beginning of your search term. This should force Filemaker to find only fully-matching requests (I know it works w/Lasso at least, not sure about CDML, but I don't see why not).

- John

---

That does work when performing a find request. The thing is, I take the philosophy that you can't trust users not to send in requests that you don't expect. For example, a hacker could easily look at the syntax you use, modify it, and submit it. Since you cannot force the user to search on the fields you expect them to search on, they could easily find records that they shouldn't see.

The Web Security Databases address this with a feature called "ExactMatch", which requires exact values for one or more fields to be submitted as part of the find request. For example, you can use ExactMatch on the password field to insure that the user actually submits a valid password with each find request. If they don't, then the Web Security Database settings cause Web Companion to block the find and not return any results. Assuming that they can't guess the passwords, this is a good way to keep hackers out of your data.

The problem is that the ExactMatch function doesn't seem to work properly for some data values. I am perfectly capable of submitting the same data in a find request and having FileMaker answer with the correct records if I don't try to use the ExactMatch feature. The troubling thing is that ExactMatch behaves differently from Find in determining what is an exact match.

Consider the following request:

http://thehost.com/FMPro?-db=[database]&-lay=[layout]&-format=[format]&-op=eq&password=mypassword&-op=eq&[email protected]&-find

Assume that there is a record with the field password equal to "mypassword" and the field LogonID equal to "[email protected]".

The above find request will work if I don't use the ExactMatch function of the Web Security Databases for the LogonID field. The same request with the same database will fail, even though it should work, if I turn on the ExactMatch option for the LogonID field.

Read my first note in this thread for differences in this behavior between Web Companion 5.0v6 and Web Companion 5.5.

Eric

[Anatoli]

Eric,

for this I am using calculated field with Name & Password and I am comparing that with calculated field in database with access rights. There is also field with Name & Password. If those Calc fields fully match, the flag is set to log user in.

[John May - Point In Space]

This is why you should switch to [inline] methodology. It lets you completely lock down the database with no privs. for All Users, then set up a separate user/pass combo to embed in the inline when performing your operations. That way, a user can't submit a search with a link.

- John

[erasmussen]

quote:

---

Originally posted by Anatoli:

Eric,

for this I am using calculated field with Name & Password and I am comparing that with calculated field in database with access rights. There is also field with Name & Password. If those Calc fields fully match, the flag is set to log user in.

---

That's a good idea. I'm going to end up using that method, plus some others, to help validate the data passing back and forth from the web to our internal databases.

-Eric

[Keith M. Davie]

Eric, I notice that you are (or were) trying to do an exact search with the cdml tag -op and the cdml tag eq. Please understand that those tags do not work in html. In order to get those tags to work you will need JavaScript. If you are interested in doing an exact search using cdml/html then you should go to FileMaker and read: http://www.filemaker.com/support/index.html

Search and read: Article Number: 104829, and Article Number: 105687

Understanding the application of the exact search, you will find that the other options (found under symbols in the status bar of your FMPro db's when doing a find) can also be applied similarly, with a minor degree of intelligent application.

[erasmussen]

quote:

---

Originally posted by Keith M. Davie:

Eric, I notice that you are (or were) trying to do an exact search with the cdml tag -op and the cdml tag eq. Please understand that those tags do not work in html. In order to get those tags to work you will need JavaScript. If you are interested in doing an exact search using cdml/html then you should go to FileMaker and read:

http://www.filemaker.com/support/index.html

Search and read: Article Number: 104829, and Article Number: 105687

Understanding the application of the exact search, you will find that the other options (found under symbols in the status bar of your FMPro db's when doing a find) can also be applied similarly, with a minor degree of intelligent application.

---

The articles you reference were written for FileMaker 3.0 and 4.0. The -Op operator with the -Eq argument is the same as putting "==" at the start of your data. It was added after those articles were written and replaces "-Eq" as a standalone operator. In either event, using "==" as a prefix for the data has the same result as adding &-op=-eq to the URL. Javascript has nothing to do with it.

-Eric

[John May - Point In Space]

-op = -eq is not the same as appending "==" to your search term.

The first will find fields with ANY word in them equalling the search term. The second will find fields ONLY containing the exact search term.

- John

[erasmussen]

quote:

---

Originally posted by John May - Point In Space:

-op = -eq is not the same as appending "==" to your search term.

The first will find fields with ANY word in them equalling the search term. The second will find fields ONLY containing the exact search term.

- John

---

Doh! Thanks, you are correct. I guess I misread the text in the CDML reference for -Op.