I am using Instant Web Publishing. I followed the instruction to the letter for limiting access on a record by record basis. Cant get it to work. Hoping someone has some input for me.

Here is what I did:

Created a new text field in my records called "record_created_by." I set the Auto Enter options to Creater Name.

I created a new record and typed "orton" into the field "record_created_by."

I created a new password named "orton." For the priviledges is chose Browse Records Limited. For the Limited calculation I used record_created_by = Status(CurrentUserName).

Now according to the instructions what this should accomplish is using the Instant Web Publishing, when someone goes to database they are prompted to enter their user id and password. When I enter the password "orton" which matches one of the records with the field "record_created_by," all that comes up is a record with all the fields containing <No Access>

If I am understanding it correctly what SHOULD be coming up is the particular record containing "orton" and the user should be able to browse that record.

Anyone have a thought as to why I am getting the <No Access> response?

Larry

[ March 10, 2002, 01:27 PM: Message edited by: Larry Ross ]

Hello Larry,

I can't pinpoint the answer to Instant Web Publishing's Record-by-Record methodology cause I avoid IWP altogether.

But I can tell you that I tried to mix the FileMaker Access Priviliges (FAP) AND Custom Web Publishing-Web (CWP) and Web Security with some success.

The thing is that Status(CurrentUserName) works for Filemaker-to-Filemaker security and that AFieldCalledUserName = External("Web-ClientName", 0) works with Web Companion's Custom Web Publishing through Web Security.

When using CWP and Web Security, the Username/Password standalone window appears unavoidable and I coundn't find a way to let users create their account with username/password since it appears to be required existing.

Good Luck with IWP.

Fran

Lots of folks use the following technique with custom web publishing. The basic strategy might work with IWP.

Let the client enter a code of their own choosing. When they revisit the database they are asked to enter that code as a find request employing the exact match operator. That allows them access to only the record they originally created.

By the way, Larry, what is the current count of forum helpers who have advised against IWP?

But, but. but ... FileMaker says that IWP is easy to use.

Heck, FileMaker says with 5.5 you can even run single-step scripts, and a limited number of three-step scripts using IWP.

Now you don't suppose that FileMaker is going to warn those potential customers against running scripts on the www because ScriptMaker is single-threaded and the www is multi-threaded, do you?

No, I'm sure that the legal department does not get involved in what the sales department promotes. After all, you have read their license haven't you?

"FILEMAKER, INC. DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE."

Surely that is something which must have been written by the sales department. ;-)