Well, in talking to one of my buddies, this has been resolved.
The answer is to run a re-login script in both db #1 and db #2.
So I setup a guest user in db #2 that only has permission to run 1 script (re-login script), and once the credentials are met in db #1 it calls a script to run a re-login script on both db #1 and db #2 with higher credentials. Works perfect in both FileMaker and IWP.
Hope that helps someone out there!
I am struggling with a similar problem and what you describe sounds good but I am afraid I don't understand how you pass the login credentials between DB's. Using IWP you cannot run a re-login except without the dialog. This means you need to provide both the account name and password to the script step using either a field or variable. The account name I understand but how do you capture the password? I know that you can create a faux login box and have the user enter an account name and password into global fields and use these to run a re-login without a dialog but that breaks all sorts of security rules.
How are you handling this?
What I actually did was create a table with usernames and passwords, and
then scripted a custom login screen to search the table for matching
username and password. If there was a match then it would run the
relogin script giving a certain level of credentials.
I haven't.been following this thread closely but storing passwords is a huge security risk. I could hack it in a couple of minutes...
sent from my windows 7 phone
I agree with John on this one. You've completely circumvented the security and that can have some very serious complications.
I'm not sure why you feel a need to separate data, as it makes things more difficult as you've discovered and added layers of complexity that probably isn't needed. I've used IWP over the years to permit client access to their data, their customer's data, and even test scores, securely and easily. As long as you restrict the users ability to find and manipulate, IWP is a fine solution for basic data needs.
My two cents,
Thanks for the reply. This is the only way I could see you doing it. As others have noted this is a big security issue so I need to work another way.
Thanks for your replies. I guess I'm a little stumped as to why this
would be a security issue. If we have an IWP login with everything
scripted (querying the username and password table), and the username
and password tables locked down to a specific privilege set, how is that
hackable? I can see having some relationships in there could pose a big
threat, but not seeing how a scripted login would.
The security issue is in the fact that you are capturing and storing the users password. In your organization it may not be an issue. For me however, we use Active Directory for authentication. I cannot allow a system that will ask a user to enter their AD password into a FM database where it could be viewed by anyone who has admin privledges.
I appreciate yoru two cents. The reason I have the data seperated is that I have multiple applications, each with a differnet set of privledge settings. I like to keep them in one file rather than in each of teh application files. However, this is a good argumnt for me moving this data to the application files and avoiding the need for accessing multiple files in IWP.