dbTalk Databases Forums  

The Holy Grail of Web Access

comp.databases.filemaker comp.databases.filemaker


Discuss The Holy Grail of Web Access in the comp.databases.filemaker forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Rick Altman
 
Posts: n/a

Default The Holy Grail of Web Access - 10-20-2005 , 10:34 AM






Here is what I would like to be able to provide for 200 members of an
organization who do not own FileMaker:

1. Email each member a link and an ID number.

2. They click the link to be taken to the web interface of the membership
database, where they cannot see any data yet.

3. They enter their ID number into some sort of search field.

4. They are taken to a specific layout, showing them their record (and only
their record).

5. They make whatever changes they want to their information and then exit.


The keys to this are: a) access restricted to their own record; b) done via
the web interface.


Is this scenario possible?




Rick A.
Pleasanton CA



Reply With Quote
  #2  
Old   
Bill Marriott
 
Posts: n/a

Default Re: The Holy Grail of Web Access - 10-20-2005 , 10:54 AM






Yes, with minor variation.

You would email them a link to a web page. They would enter an ID number and
password. Then you could take them to a specific layout showing them their
record, and only their record.

Very straightforward to do with FileMaker 7/8. Probably possible with
earlier versions, but the built-in web publishing and accounts handling is
not as robust.

Bill

"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote

Quote:
Here is what I would like to be able to provide for 200 members of an
organization who do not own FileMaker:

1. Email each member a link and an ID number.

2. They click the link to be taken to the web interface of the membership
database, where they cannot see any data yet.

3. They enter their ID number into some sort of search field.

4. They are taken to a specific layout, showing them their record (and
only their record).

5. They make whatever changes they want to their information and then
exit.


The keys to this are: a) access restricted to their own record; b) done
via the web interface.


Is this scenario possible?




Rick A.
Pleasanton CA




Reply With Quote
  #3  
Old   
Rick Altman
 
Posts: n/a

Default Re: The Holy Grail of Web Access - 10-20-2005 , 06:22 PM



Many thanks, Bill, for the reply. I need to be pointed in the right
direction: how is this very straightforward to do with FM7? What are the
tasks/procedures that I need to perform?


Rick A.



"Bill Marriott" <wjm (AT) wjm (DOT) org> wrote

Quote:
Yes, with minor variation.

You would email them a link to a web page. They would enter an ID number
and password. Then you could take them to a specific layout showing them
their record, and only their record.

Very straightforward to do with FileMaker 7/8. Probably possible with
earlier versions, but the built-in web publishing and accounts handling is
not as robust.

Bill



Reply With Quote
  #4  
Old   
Bill Marriott
 
Posts: n/a

Default Re: The Holy Grail of Web Access - 10-20-2005 , 06:47 PM



Rick,

Back in January there was a thread regarding a very similar situation. It's
a very straightforward solution. The basic approach is:

1) set up a table with one record for each user.
2) establish a default username/password for everyone in that table
3) set up a privilege set which is intended for this class of user
3) add these accounts to the FileMaker access privs table
4) for the privilege set, specify records can only be viewed/edited when the
logged in account = the account marked for that record
5) set up a startup script where users are taken directly to their record on
login.

I'm reprinting the post I made earlier for your convenience [read from
bottom up]. You should be able to find the whole thread if you have a decent
newserver, or search Google. If you have additional questions, just let me
know here or in email.

Bill
wjm (AT) wjm (DOT) org

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Easy enough to remedy.

A very simple procedure can create default accounts for all users:

Fields
=====
OwnedBy (text) [could be called "username" but I wanted to be consistent
with my last post]
DefaultPassword (text)

After you add the fields, Show All Records and....

1) click into OwnedBy and choose Records-->Replace field contents
2) specify, "Replace with calculated result:" and use the expression

Filter (Lower (FirstName & LastName & Int (Random * 99));
"abcdefghijklmnopqrstuvwxyz0123456789")

This will create a username similar to "rickaltman21". I use Filter() to
make sure no weird characters get in there (like spaces or apostrophes in
names like "O' Malley"). I use a random number just in case you have people
with the same first and last names (and to make it slightly harder to guess
someone's account name). Not a perfect algorithm, but it will do. You could
also use "FULLNAME" instead of FirstName & LastName.

3) click into Password and choose Records-->Replace field contents
4) specify, "Replace with calculated result:" and use the expression

Right ("00000" & Int(Random*99999),5)

This creates a random five-digit numeric password.

Now you've got a username and password set up for each user.

Access Privileges
=====
Choose File-->Define-->Accounts & Privileges, then click the "Privilege
Sets" tab. I suggest creating a new privilege set named, "Student" which has
the ability to edit/view just the fields and layouts you want for this class
of user. I won't go into too much detail here, but it's covered quite
extensively in the online manual. (Press F1 at the Edit Privilege Set
screen). You can do all kinds of nifty stuff here, even double-secure your
database by making sure someone can only edit/view a record if username =
Get (AccountName). If it freaks you out, don't create a privilege set and
just use the [Data Entry Only] privilege set in the script below.

Script: Batch Create Student Accounts
=====
Go to Record/Request/Page [First]
Loop
Add Account [Account Name: databaseName::OwnedBy; Password:
databaseName:efaultPassword; Privilege Set: "Student"]*
Go to Record/Request/Page [Next; Exit after last]
End Loop

[* specify "[Data Entry Only]" as the privilege set here if you declined to
create your own. Don't be tempted to require users to change their password
on the next login; that option is not web compatible.]

When you run this script, it will take less than 5 seconds to update your
entire database with accounts.

I suggest you then print out the username and passwords in a form
appropriate to distribute to the database users and delete the
DefaultPassword field because it's no longer needed. The passwords are
stored safely by FileMaker. Alternately, you might wanna Export the two
fields to a text file of some sort which you save in a safe spot in case you
need it.

Regarding your pie-in-the-sky hope... You have to create the accounts before
someone logs in, otherwise there would be nothing to log into. The user
would be a guest and therefore anonymous. You could not easily control which
records they could access.

If you instead want to have a registration system where a stranger creates a
new account via a web page, that is a more complex solution but still
possible using a variant of this technique.

Bill

"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote

Quote:
Bill, it's Item A on your list that troubles me:

A) a FileMaker account already set up for each individual


There will be over 200 individuals and creating privileges for each of
them would be a significant task. My pie-in-the-sky hope here is that
their login could somehow be dynamic, and upon logging in, their name were
captured and then run through some sort of input string that created
access for them to records whose FULLNAME field matched their login.

Am I dreaming here...?



"JohnSmith") as part of the [Data Entry Only] privilege set.

B) a field, "OwnedBy," which is a text field containing the account name
that record belongs to

C) a layout, "Web Data Entry," which is showing OwnedBy and the other
fields they need to work on

You would add the following script:
------------------------------------------
If [Get (AccountName) <> "Admin"]
If [Left (Get ( ApplicationVersion);3) = "Web"]
Show/Hide Status Area [Lock; Hide]
Go to Layout ["Web Data Entry"]
Enter Find Mode []
Set Field [databaseName::OwnedBy; Get ( AccountName )]
Perform Find []
# Put the cursor into "firstField" so it's ready for input
Go to Field [Select/perform; databaseName::firstField]
End If
End If
------------------------------------------

This script only runs if the user is coming in from the web and is not
the database administrator. It will hide the status area, switch to the
data entry layout, search for the appropriate record in the database, and
enter the record to accept data entry.

Now, all you need to do is:

1) Set the file options so this script is run when you open the file, and
it will always open up to the Web Data Entry layout and show only the
record belonging to the person who logged in. [Unless they are the
"Admin" account or log in using FileMaker Pro.] Additionally, the status
area will be hidden so they cannot "Find All" or something crazy like
that to see other records.

2) Add a button to the layout which "Commits Record/Request" to the Web
Data Entry layout. You might instead link to a script which commits the
record and logs them out of the database.

Bill






"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote in message
news:i8-dnRlREePK12TcRVn-qg (AT) comcast (DOT) com...
Dana, could you treat me like the idiot that I am about these matters
and step me through how I might do this?

- I can indeed create a single layout and place all of the required
fields on it.

- I would like for guests to log in with their first and last name and
be taken to their record.

- I need for them to then begin to fill out the forms on that layout.


How would I go about creating this? Many thanks...




Rick A.



"Dana Reed" <reed (AT) chem (DOT) umn.edu> wrote in message
news:ct8pfs$lpf$1 (AT) lenny (DOT) tc.umn.edu...
In FM7 IWP, you could just use native filemaker accounts and privileges
along with the Get(AccountName) function to control user navigation.
Just hide the status area from the user and create your own scripts to
send users to the proper layout/record based on their username.









"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote

Quote:
Many thanks, Bill, for the reply. I need to be pointed in the right
direction: how is this very straightforward to do with FM7? What are the
tasks/procedures that I need to perform?


Rick A.



"Bill Marriott" <wjm (AT) wjm (DOT) org> wrote in message
news:y7idnc74D5QwIMreRVn-jQ (AT) comcast (DOT) com...
Yes, with minor variation.

You would email them a link to a web page. They would enter an ID number
and password. Then you could take them to a specific layout showing them
their record, and only their record.

Very straightforward to do with FileMaker 7/8. Probably possible with
earlier versions, but the built-in web publishing and accounts handling
is not as robust.

Bill





Reply With Quote
  #5  
Old   
Bill Marriott
 
Posts: n/a

Default Re: The Holy Grail of Web Access - 10-20-2005 , 07:37 PM



Hm... re-reading, I see you were the one who started that thread!!

Was there some difficulty following those steps?

Bill

"Bill Marriott" <wjm (AT) wjm (DOT) org> wrote

Quote:
Rick,

Back in January there was a thread regarding a very similar situation.
It's a very straightforward solution. The basic approach is:

1) set up a table with one record for each user.
2) establish a default username/password for everyone in that table
3) set up a privilege set which is intended for this class of user
3) add these accounts to the FileMaker access privs table
4) for the privilege set, specify records can only be viewed/edited when
the logged in account = the account marked for that record
5) set up a startup script where users are taken directly to their record
on login.

I'm reprinting the post I made earlier for your convenience [read from
bottom up]. You should be able to find the whole thread if you have a
decent newserver, or search Google. If you have additional questions, just
let me know here or in email.

Bill
wjm (AT) wjm (DOT) org

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Easy enough to remedy.

A very simple procedure can create default accounts for all users:

Fields
=====
OwnedBy (text) [could be called "username" but I wanted to be consistent
with my last post]
DefaultPassword (text)

After you add the fields, Show All Records and....

1) click into OwnedBy and choose Records-->Replace field contents
2) specify, "Replace with calculated result:" and use the expression

Filter (Lower (FirstName & LastName & Int (Random * 99));
"abcdefghijklmnopqrstuvwxyz0123456789")

This will create a username similar to "rickaltman21". I use Filter() to
make sure no weird characters get in there (like spaces or apostrophes in
names like "O' Malley"). I use a random number just in case you have
people
with the same first and last names (and to make it slightly harder to
guess
someone's account name). Not a perfect algorithm, but it will do. You
could
also use "FULLNAME" instead of FirstName & LastName.

3) click into Password and choose Records-->Replace field contents
4) specify, "Replace with calculated result:" and use the expression

Right ("00000" & Int(Random*99999),5)

This creates a random five-digit numeric password.

Now you've got a username and password set up for each user.

Access Privileges
=====
Choose File-->Define-->Accounts & Privileges, then click the "Privilege
Sets" tab. I suggest creating a new privilege set named, "Student" which
has
the ability to edit/view just the fields and layouts you want for this
class
of user. I won't go into too much detail here, but it's covered quite
extensively in the online manual. (Press F1 at the Edit Privilege Set
screen). You can do all kinds of nifty stuff here, even double-secure your
database by making sure someone can only edit/view a record if username =
Get (AccountName). If it freaks you out, don't create a privilege set and
just use the [Data Entry Only] privilege set in the script below.

Script: Batch Create Student Accounts
=====
Go to Record/Request/Page [First]
Loop
Add Account [Account Name: databaseName::OwnedBy; Password:
databaseName:efaultPassword; Privilege Set: "Student"]*
Go to Record/Request/Page [Next; Exit after last]
End Loop

[* specify "[Data Entry Only]" as the privilege set here if you declined
to
create your own. Don't be tempted to require users to change their
password
on the next login; that option is not web compatible.]

When you run this script, it will take less than 5 seconds to update your
entire database with accounts.

I suggest you then print out the username and passwords in a form
appropriate to distribute to the database users and delete the
DefaultPassword field because it's no longer needed. The passwords are
stored safely by FileMaker. Alternately, you might wanna Export the two
fields to a text file of some sort which you save in a safe spot in case
you
need it.

Regarding your pie-in-the-sky hope... You have to create the accounts
before
someone logs in, otherwise there would be nothing to log into. The user
would be a guest and therefore anonymous. You could not easily control
which
records they could access.

If you instead want to have a registration system where a stranger creates
a
new account via a web page, that is a more complex solution but still
possible using a variant of this technique.

Bill

"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote in message
news:2dqdncnGMIPe62PcRVn-vA (AT) comcast (DOT) com...
Bill, it's Item A on your list that troubles me:

A) a FileMaker account already set up for each individual


There will be over 200 individuals and creating privileges for each of
them would be a significant task. My pie-in-the-sky hope here is that
their login could somehow be dynamic, and upon logging in, their name
were captured and then run through some sort of input string that created
access for them to records whose FULLNAME field matched their login.

Am I dreaming here...?



"JohnSmith") as part of the [Data Entry Only] privilege set.

B) a field, "OwnedBy," which is a text field containing the account name
that record belongs to

C) a layout, "Web Data Entry," which is showing OwnedBy and the other
fields they need to work on

You would add the following script:
------------------------------------------
If [Get (AccountName) <> "Admin"]
If [Left (Get ( ApplicationVersion);3) = "Web"]
Show/Hide Status Area [Lock; Hide]
Go to Layout ["Web Data Entry"]
Enter Find Mode []
Set Field [databaseName::OwnedBy; Get ( AccountName )]
Perform Find []
# Put the cursor into "firstField" so it's ready for input
Go to Field [Select/perform; databaseName::firstField]
End If
End If
------------------------------------------

This script only runs if the user is coming in from the web and is not
the database administrator. It will hide the status area, switch to the
data entry layout, search for the appropriate record in the database,
and enter the record to accept data entry.

Now, all you need to do is:

1) Set the file options so this script is run when you open the file,
and it will always open up to the Web Data Entry layout and show only
the record belonging to the person who logged in. [Unless they are the
"Admin" account or log in using FileMaker Pro.] Additionally, the status
area will be hidden so they cannot "Find All" or something crazy like
that to see other records.

2) Add a button to the layout which "Commits Record/Request" to the Web
Data Entry layout. You might instead link to a script which commits the
record and logs them out of the database.

Bill






"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote in message
news:i8-dnRlREePK12TcRVn-qg (AT) comcast (DOT) com...
Dana, could you treat me like the idiot that I am about these matters
and step me through how I might do this?

- I can indeed create a single layout and place all of the required
fields on it.

- I would like for guests to log in with their first and last name and
be taken to their record.

- I need for them to then begin to fill out the forms on that layout.


How would I go about creating this? Many thanks...




Rick A.



"Dana Reed" <reed (AT) chem (DOT) umn.edu> wrote in message
news:ct8pfs$lpf$1 (AT) lenny (DOT) tc.umn.edu...
In FM7 IWP, you could just use native filemaker accounts and
privileges along with the Get(AccountName) function to control user
navigation. Just hide the status area from the user and create your
own scripts to send users to the proper layout/record based on their
username.










"Rick Altman" <rick.a (AT) NOSPAMaltman (DOT) com> wrote in message
news:8dOdnZ1Iork5u8XeRVn-iQ (AT) comcast (DOT) com...
Many thanks, Bill, for the reply. I need to be pointed in the right
direction: how is this very straightforward to do with FM7? What are the
tasks/procedures that I need to perform?


Rick A.



"Bill Marriott" <wjm (AT) wjm (DOT) org> wrote in message
news:y7idnc74D5QwIMreRVn-jQ (AT) comcast (DOT) com...
Yes, with minor variation.

You would email them a link to a web page. They would enter an ID number
and password. Then you could take them to a specific layout showing them
their record, and only their record.

Very straightforward to do with FileMaker 7/8. Probably possible with
earlier versions, but the built-in web publishing and accounts handling
is not as robust.

Bill







Reply With Quote
  #6  
Old   
Rick Altman
 
Posts: n/a

Default Re: The Holy Grail of Web Access - 10-20-2005 , 08:56 PM



That's too funny; I do recall that thread now. I was too inexperienced to
have carried out those instructions so I gave up entirely. Now I'm a bit
better equipped and I am grateful for you steering me back there!


RA




"Bill Marriott" <wjm (AT) wjm (DOT) org> wrote

Quote:
Hm... re-reading, I see you were the one who started that thread!!

Was there some difficulty following those steps?




Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.