PUBLISHING THE WEB SECRUITY DATABASE? NOPE.

OK. I was not able to publish the Web Users_.fp5 database, but I was able to duplicate it and publish the re-named and slightly modified duplicate for web users to create their own logins/passwords. I use a script to import this data into Web Users_.fp5.

Now, does anyone have tips for me as to how to restrict users' access to their own records? I want something like the RECORD LEVEL ACCESS feature but I have only found references to it using Access Privileges, not the Web Security Database. Other FMForum Posts have also complained about the slow, unpredictableness of the Record Level Access feature, anyway.

What have other folks used or developed? Please boast, brag, and/or theorize.

Thanxalot!

What I am doing is simple:

WebSecurity is protecting the databases.

User log in with unique numeric usercode and password.

All can see everything.

I do carry over their usercode and password.

When searching for their record only users with the same usercode and password will find their private record and can amend it as they wish...

Hi, Anatoli.

I see, so you store both the usercode and password in fields on each record. So, is this an EXACT SEARCH type of thing with a ==? Web Security Database remembers a user's login and password so they do not have to type passwords for each record changed, right? Thanxalot!

Has anyone else tried anything different, or is Anatoli's solution the best way to go?

-- ST

A Security document on the Filemaker web-site describes how to do this.

All the best.

Garry

There is exact search in WebSecurity, but it may lock other users out of displaying other data from that database -- obviously that depends on overall design. And it is impossible to do partial and exact search on the same field.

You can do also "exact search" without WebSecurity db with compromised security but more flexibility.

I've read latest security documents from FMI and it is kind of funny. Some while ago FMI played dead with "hacking" syntax which was discussed deeply here. Now they do publish that as a "feature" for security testing

Why there is not a preference setting to allow or disallow that commands?

In fact that is pushing me from FM in long run.

First to Lasso and consequently to MySQL and/or to other SQL databases.

Hmm... Thanx, Anatoli/Garry. I found the Web Security.pdf right in my own FMP Application folder (oops, forgot!) and remember now that it is helpful but not exactly what I wanted. In the section, "Protecting specific records in a database" it basically says to make a record-specific password field (YourSecretCode) and use Web Security Database (WSD) field settings to control access. This is what I was going to do originally (allow anyone who knows record password to make edits) but I decided to go with a login/password system instead.

Please comment on my plan...

I was going to use AUTO-ENTER in Define Fields to put CREATOR NAME into each record made (they must login first). However, there was no CREATOR PASSWORD option in the auto-enter options, though. Upon further investigation, I see I might be able to use CDML tags [FMP-ClientUserName] and [FMP-ClientPassword] instead.

Then, I will try to use WSD field settings and exact search for creatorname and recordpassword fields while keeping data fields on public read access.

Ummm... I guess I also need some kind of "logout", too. Anyone know how to do this with WSD or can point me to docs? Thanxalot.

hi sktajiri ,

I'm not sure you can use any of my comments but I've done a website using usernames/passwords etc on a clients db. I did it using sessioncookies; after the login (lookup/match with rel. db containing userinfo), all forms that use CDML contain [fmp-if] statements. After login a cookie will be set with the users accesslevel and based on that parts will be shown to that user. This was at first timeconsuming, but a little [fmp-include] made it much easier to maintain.

Adding records is done the same way, except you 'filter' out what parts they can fill in or what buttons they actualy see by the IF statements. adding the Uname/Pword to the record willl make the user the 'owner'. Changing the accesslevel in the rel. db containing userinfo will in fact show more, or less info for that user...

Also, set cookietime for the password to 0 and it will expire after closing the browser. You can have the username on autoenter (also for a period of time if you want).

Dont know if this helps...

JP

I found combination of WebCompanion and IE cookies unreliable, so I've used in my above example Tokens.

That never failed.

hello there....this was said and done but here is what I did:

Users.fp5

----------FIELDS------------

1[userName]-- text

2[Password]-- text

3[userID] --auto serial increment unique

4[AccessLevels]- drop.values numbers Guest=0, User=1, PowerUser=2,MegaEntry=4,Admin=5,.....

when user enters the right password and username a Token is assigned to unique =UserID that is passed arround to make sure user is adding/del/editing her/his records.

also we insert this digit arround by hidden fields so any record created will have the UniqueID attached...hmmm..also before they see their records/results the little hidden field will be there to set itself equal to that token we dragg from the login

soo....If I add record :

==================================

Fname|Lname|Address| CreatedBy |

==================================

Merry|Jane|Green Ave. | 666|

------------------------------------------

.....

...

..

==================================

this means that this record was created by user whose UniqueID=666 !

Access level is used with FMP-IF to display links/commands on initial(LoggedIn.html) page..so

IF AccessLevel >=2 let them see the ADD/EDIT/DELETE links

.... IF NOT then they see someting else

there...it works for me..all I do is add a user and assign the rights and they can do the rest.

Also, Users.fp5 and Web Users_.fp5 have to match usernames/passwords to those DBs you want them to access!

I know its not THE solution but...hey give me some credit 1st time I HEARD of FM was 2 months ago ...and I hate it just as I do any other DB |:

good luck to all of u