Jump to content

Problems with ExactMatch


This topic is 8394 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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?

Link to comment
Share on other sites

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
cool.gif" border="0

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.

Link to comment
Share on other sites

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
cool.gif" border="0

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

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

Link to comment
Share on other sites

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
cool.gif" border="0

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

Link to comment
Share on other sites

This topic is 8394 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.