solutions wanted On-line registration for a community chorus?

[TysonB]

This MAY be too big of a question, but I'm looking for some direction or possibly some sample code... I've just taken over the manager position of our local community chorus, where the previous manager was doing paper-based registration then hand-entering it into a flat-file Access 97 db (shudder.....). There's GOT to be a better way.

I currently have access to FMP 8.5 Client/IWP, but may soon have access to an FMP 8 Server Advanced installation. I'm a "self-taught" FileMaker guy (okay, now, all the DBAs out there, your turn to shudder) and have a good handle on the basics and the relational bits. However, I have very little experience with user accounts and privilege sets, and NO experience with using them to create, say, an online registration tool for a community chorus. I'm sure there MUST be a commercial tool out there, but everybody knows what the word "community" stands for.... I have no financial resources.

What I would LIKE to do is to create a IWP-accessible registration page where people can a) create their own accounts (w. usernames and passwords, : edit their own account information and c) NOT be able to access anyone else's account information. Simple, no? I'm familiar with the issues around guest login/registered login with IWP, I can probably work around that one. I don't want to do any financial stuff like fee tracking or online payments right now, but might in the future (walk before I run, sort of thing).

I know, this is not a small question, but any help would be appreciated... Sample code (particularly around scripting the account creation process), or pointers to good tutorials, etc. Again, I've got more time than money....

Thanks in advance,

[David McQueen]

It sounds like once they get there, they are not going to be doing too much other than entering in name, address etc. It appears to be more a problem of getting them to

a.) Set up their identification

b.) Go somewhere based on that identification.

You might want to try a secondary log in outside of the

FMP permissions.

They come in as a guest ( no password) to a screen that has

Login

New Account

If they click Login, they go to a screen that requires them to say enter a name and a password into globals on a layout and then Click the Login button.

The name and the password entered form a compound key using a calculated field. The script tries to do a go to related record step to go to their record and only their record. IF there is no relation, you trap for it and bring them back to the Login as something they have entered is not correct. IF there is a relationship, the record is isolated and you go to a layout showing their information.

For new account, the script creates a new record where they are required to enter their name, a password etc. part of which is used for their future Login.

So there is never a search and they never get to anyone elses account.

This would get away from you having to continually create accounts or from you having to allow guests to create accounts in FMP.

HTH

Dave McQueen

[TysonB]

Thanks David! I've been able to figure my way through MOST of this, but I've run into a snag or two....

First, I'm assuming that the "Login" page would have to be within a separate file, related to the main file through an external file reference. Otherwise, if it were just a separate table within the file, the restrictive privilege sets in my user database would be applied to the Login page table, correct? And if it is separate, the Login page file CAN have guest access enabled, correct? But ONLY if when my users log in, their related record is opened in a new window. What I found is that if I made the "Login" script just change layouts to one within the Login file that had all the related filelds from my Users file on it, users could do whatever they wanted (Find other user records being one bad thing) because the less restrictive priv set from the Login file applies... Thats the first snag.

The second snag is that I can't seem to figure out how to, from my Login file, reach out into the separate but related User file and create a new record without having to have a layout set up within the Login file that shows related fields from Users.

So, my first snag is that I can only display existing user records in a new window if I want to maintain the restrictive priv set of the User file, my second snag is that I have to display related fields within my less restrictive Login file if I want to create new records. These seem to be two mutually exclusive problems. Unless I am missing something, which is quite possible.

Hmmm. Other than that, it seems to be the approach I needed.

[David McQueen]

Thanks David! I've been able to figure my way through MOST of this, but I've run into a snag or two....

First, I'm assuming that the "Login" page would have to be within a separate file, related to the main file through an external file reference. Otherwise, if it were just a separate table within the file, the restrictive privilege sets in my user database would be applied to the Login page table, correct? And if it is separate, the Login page file CAN have guest access enabled, correct? But ONLY if when my users log in, their related record is opened in a new window. What I found is that if I made the "Login" script just change layouts to one within the Login file that had all the related filelds from my Users file on it, users could do whatever they wanted (Find other user records being one bad thing) because the less restrictive priv set from the Login file applies... Thats the first snag.

I am assuming that you are FileMaker 7 or better.

What you would like is for them to enter the site without a password, whether it is the guest account or the guest account is disabled and you make up a separate account with it's own privleges for this. If you cannot have no password, you really only want one password and one account name, which can be posted to the web page.

You do not want this from a separate file or even a separate table. This is a layout in the main table. Status areas are locked down so that they cannot navigate unless you say they can navigate.

You are trapping for the fact that they are coming in by web interface. Based on this you are pushing them to the secondary login layout.

It does not matter what record they are in when they go there as all they will see is global fields, which you will have cleared as part of the opening script. No left over passwords or names.

The only time they would create a record is when they create a new account. This would be fully scripted.

They would never do a find. When they log in they would go to their record, which would be a form which they could fill in. Again, everything locked down so they cannot search or navigate except via your buttons.

The idea is that the only places they can go are the create a new account layout or their own record layout. In the first instance, it does not matter what record they are in because all they see is global fields and they cannot do any damage. In the second instance, you have already put them on their own record.

The idea is to keep it as simple as possible. I am being quite general here as I am not on a machine that will run FMP 7-8 and it was a couple of years ago when I last implemented a similar system. But, you only want to show them what they have to see. You don't want them finding any thing.

If you want to be even more secure, when the relationship is set up from the log in, you just change layouts and only show related fields. Then even you are never finding anything.

HTH

Dave

[TysonB]

Hi David,

Thanks! Between your excellent advice and my bloodymindedness about getting this #$%## thing to do what I eventually figured out I wanted it to do, I think I've got a pretty workable prototype... Not beautiful, but as far as I can tell, functional.

One thing, tho,

You say

You do not want this from a separate file or even a separate table. This is a layout in the main table. Status areas are locked down so that they cannot navigate unless you say they can navigate.

One of the things I noticed/thought about when I was using a separate "login page" file and accessing the related account information via an external file reference, this approach would probably allow me to build multiple access methods for/pathways to my data in the main file... As long as I've got a) matching privilege sets and users between the two files (login & data...I think this might have been my problem with my initial snags I ran into) and I'm careful to maintain the file references if I move the two files. Your (or anybody else's) thoughts about the pros and cons of this approach would be appreciated.

Anyway, I've attached the prototype I built, in case anybody else wants to take a look at it...

Thanks again!

If you want to be even more secure, when the relationship is set up from the log in, you just change layouts and only show related fields. Then even you are never finding anything.

HTH

Dave

login.zip

[TysonB]

Ah, right, I forgot to note the full access username and password for my prototype file. In complete violation of what everyone says about password security, it is admin and admin.

There's no data in it, tho