How to pass user information with login script

[Collin]

I'm designing my own login script. It's a combination of an admin password and a user password (filemaker security system), scripts that block access and the verification of a entered password for my own login script.

I'm using a script that searches a user database for the entered password, if it finds the entered password the username and password are stored in a global field called username and password. And passed to the other databases with the command set field (also stored in global fields).

The problem I have with this solution is that it works wonderfully with one user. Butt when I share the database on a FileMaker server I can't pass the information of a second user to that field (was afread that this would be the case). Without the username some scripts won't work correctly (finding records for that user).

Does anyone know how I can pass the username and password information between te databases so that the scripts can do their work. Or any suggestions on what I need to use to make these scripts work with the passed userinformation.

[djgogi]

I don't get it!?!

What do you mean with can't pass the information of a second user to that field?

In an multiuser environment, every user has his own set of globals.

Dj

[Collin]

example:

I want to log in as user Jack. Jack has the password capitol.

I start the database and fill in the password capitol. The scripts finds this password in the user database and stores the found username and the password in the global field username and password in the menu database.

The menu database then loads all the other databases and passes this information also to their global fields.

The on a second computer I want to log in as Bert.

Bert has the password route66. When you have entered the password the same script and procedures are followed by filemaker.

When I then go to the second layout where these global fields are and where everything is stored. I see in the global field username the name of the first user: Jack. And the password of that user: capitol.

And may I aks what exactly do you mean with: "In an multiuser environment, every user has his own set of globals.". Do you mean with this that you can store different information in the same field with the command set field with multiple users?

[djgogi]

Yes, globals are not part of record structure: they are created on user's computer.

So you are probably looking at globals from computer 1(Jack/capitol) if you were controlling from bert's computer than you would see his info.

Dj

[Collin]

Thanks to your help I now understand how the global field works (I used the global field type after seeing this in a login script).

So thanks to your explanation I knew something else must be wrong with the script I was running. And gues what I discovered, the password wasn't beeing passed to the user database. And in the global field check password it still had the old password from the previous session stored (jacks password) and so it would search for that password and log in under that username.

The problem was caused due to a broken relation between the login database and the user database (had to change the name of the login database due to the fact that there already was a file with the same name hosted on the network).

After I adapted the script to the new filename it works fine.

Butt this pointed out a nice hole in my security. I killed the log in problem with a script called init wich makes the global field check password empty (set field = "check pasword",""). So if ever again something like this happens it won't be possible to continue the script (on error 401 it displays the message wrong password and the field password has to be filled in for a user).

Thanks for your help.

[Kundinger]

Hello Collin,

I utilize a

[Collin]

I do understand your post, I'm using a similar concept for my database.

I'm also using relations to pass information to the other databases. Only I use relations to pass the login information (I also use relations to pass information to other databases for search events).

Every database in my solution has the user and their corresponding rights stored in a global field. Those fields are reset on exit and also when you open the file (a crash doesn't clear the global field).

I'm using the multiple database solution because the databases have such different functions that they vary in window size (example: http://www.x-pc.info/zooi/kreatodb.html ). Thus a single window solution wouldn't give the flexibility (the database needs to have a 'building block construction', this for adding new databases and maintenance on one of the databases).

Although your solution is interesting and is worth looking in to for certain situations.