Check out the script step Re-Login.
Thanks Mike! Is there a way to make it automacally hit OK and revert back to the origional login after the script.
I feel like I should also ask for a Red Ryder B.B. Gun and a stocking full of candy
1 of 1 people found this helpful
Just execute the Re-Login script step with the original credentials.
And you can’t have one. You’ll shoot your eye out.
1 of 1 people found this helpful
Mike - We are definately on the right path here. I am still haveing to hit OK from the re-login. It opens the login message screen with the credentials correct but the user still has to click OK (I posted a picture of the script result below but you probably know what I am talking about.) Is there a way to get around the user haveing to hit OK. DB2 will need to post transactions to DB1 quickly and drop back to DB2 very quickly.
I again apoligize. I am trying to learn FM from years developing very specific MS Access "solutions" with SQL as back end databases on a large government system and am hoping to re-script some of the solutions that other localities have said "Wow, I wish we had that." So far I am a big fan of the UI, how data is handled, Web Direc, and it's ability to scale without a crazy expensive SQL server. Thanks for the support
Just check the "Perform without dialog" checkbox (lower left-hand corner when you select the Re-Login script step). It'll suppress the dialog.
hoping to re-script some of the solutions that other localities have said "Wow, I wish we had that."
We fully support that goal.
So far I am a big fan of the UI, how data is handled, Web Direc, and it's ability to scale without a crazy expensive SQL server.
So are we.
Though your relogin problem should go away with Mike's suggestion that you run it without dialog, I notice that the credientials in question (based on the image displayed) may allow the user to modify their own password. You need to turn off that permission for this privilege set in the target file if you want to be able to rely on scripted logins, so that users won't have changed that password before you try to login via a script with a scripted set of credentials.
If you allow users to change passwords, but you still need to use those passwords in scripts, you will need to track user credentials themselves within a table so you can pick the current password dynamically, which is a security risk.
Thanks Stephen for the reccomendation. On initial login, I use the following script to only hold the user credentials inside their session with Comapny Info:: UID & PASS as global using set field as a second level to make sure they are not recoreded in the DB. You pointing out that changing the password will throw a fork in the whole thing is very wise. I guess I will have to disable that one until I have some time to work around it. Do you feel that the described method is secure enough?
Do you feel that the described method is secure enough?
Just as an FYI regarding security and this script:
If a user is working with a copy of FileMaker Pro Advanced, they will be able to see and modify global variables.
In the case of your script, presumably the user would not be seeing anything that they did not already know.
However, in the scenario where a user walks away from their desk while still running your solution, all it takes is a momentary peek in the Data Viewer for someone else to learn the username and password.
I mention the above for your consideration.
I feel somewhat unhelpful here, because I am pointing out a potential problem, and I don't have a good solution to offer for it, but I feel it is nonetheless worth mentioning -- If you are in your second month of FM, the issue of exposed global vars may not have sunken in yet. A bigger problem related to this topic (which does not appear to be something that you are doing) is when developers store privilege status data in global vars.
Very kind regards and welcome to FileMaker,
Steve - Thanks for your input.
I actually just read a paper about the cons of using global variables in FM. I also cannot think of a way around this as not storing the credentials would require one particular end user to have to log back into DB2 30 times an hour. I will have to make sure that the menu options are locked down for everyone outside of the development team (which is just me at this point.) Hopefully FM will come up with some - re-login (original user) - script like the return to original layout script that can be written into future scripts thus eliminating this particular danger. I am sure that I cannot be the only person that has to do this.
Don't hold your breath.
While the re-login probably works, I am wondering why you don't just have same accounts in both files.
This clearly sounds like a multi-file solution and as such, it is a good idea to have the same accounts in both files.
When user login to File 1, if they are on a layout with data from File 2 or run a script from File 2, FileMaker will automatically try to login to File 2 with the same credentials as what the user is logged in with in File 1. If there is a matching account in File 2, the user will never be promted to login to File 2 and you don't have to store passwords.
Then you just have to setup privileges set, so the user only can access what they are supposed to.
Maybe I got your scenario wrong, but it just sounds like you are walking the mountain, when there is an easier way. (and more secure)
Oh, and welcome to the FileMaker community. Just ask, there are a lot of people who is willing to help you in the right direction here....
I'm curious why it's necessary to relogin to DB2 multiple times. Would you not just leave it open, once in?
And +1 on Steve's and Claus's cautions.
Scaling. I will reproduce DB2 for multiple orginization's but only want to deal with one implantation of DB1. The best example I can think of is a hosted payment setup where DB1 runs the payment process and shoots back a verification number. It is a very similar function but does not involve money.
I am hopeful that in the future there will be 10 or more orginization's using DB2 while I only have to maintain one working DB1.
Mike - It may be my noobness coming through
Are you saying it is possible to log into DB1 with credentials different from DB2 at the same time?