Changing login data in launcher

[jrb66]

I am currently trying to modify an existing FM application - which I inherited and I am still trying to understand. Launchers are a new experience thrust upon me....

My issue is as follows:

The application consists of a main database with its own launcher for users to gain access to the application. All users have privileges assigned etc.

In addition there are various other launchers -lets call them task launchers- which are used either manually or via scheduled tasks (in windows). These launchers open up the main database and run scripts found therein. These scripts that are run from the main database email out reports or notifications from Outlook.

The problem I have encountered is that the email address currently needed by Filemaker scripts has been changed along with the account to log onto the server.

For example the main database and server would previously be logged on to as 'user1' and send email via Outlook as 'user1'. Now the FM database and server are logged into as 'user2', the email address (outlook) also belongs to 'user2'.

Now when the task launchers are run they open up the main FM database using the 'user1' credentials. Therefore, when the email code/scripts are run a dialog box pops up and asks if it is OK to send out the email using the 'user2' Outlook account. Please note that email sent out by FM Server itself works without a dialog box popping up.

To resolve this I thought that if the main database wwere logged into as 'user2' when called via the task launchers, the email could be sent out as 'user2' without any email dialog boxes popping up.

How do I change the launchers to use different account credentials (user2) when accessing the main database to run scripts found therein?

I've tried recreating the task launchers and don't see where I can set credentials for accesing the main database. I don't see an option when selecting the main database scripts. The main database does not have any account name entries etc. in the 'file options' - whould I change the 'file options' or is there somewhere else I would change the default logon credentials?

Any suggestions on resolving this issue would be greatly appreciated.

John

[jamesducker]

If editing 'file options' doesn't give you what you need, then this is not a *general* FileMaker question, so much as trying to understand (as you suggest) what the previous developer has made FileMaker do.

Is there any chance you could post a sample of one of these 'task launcher' files?

We might be able to give you some pointers from there... although wouldn't be able to give a COMPLETE answer without seeing the main database as well, i.e. what the database actually DOES with whatever parameters it receives.

J

[bcooney]

I wouldn't think it's File Options, I would think there's an Open File script step in a Startup script in the Launcher hard-coded with the account and password to use in opening the main file.

However, we'd need to know what the system does given the account name that has logged in. I'd start by examining the main file's startup script. (Be careful, work with a copy!).

[jrb66]

Thank you for your replies.

In regards to your request for further information

This particular launcher simply runs a report and emails it. The 'file options' for this launcher are set to run a script on open. The script is found in the launcher database.

This is the code for the script (typed in)

Set error capture [on]

If [get(modifierkeys)=4]

Exit script []

Endif

Perform script ["ASDF" from file:"QWERT"]

Exit application

Please note that ASDF represents the script found on the main database. It simply does a find and exports the data to a spreadsheet and mails it.

QWERT represents the main database file which is logged into automatically so to speak. The 'file options' for this database are not set to run as any particular user. It is also set to run an opener script. That script is below:

#Set these Globals locally on the server (Later)

Set Field [GlobalMenus::gcUserLoggedln TextStyleAdd(TextColor (Welcome & Get (AccountName) ; UI::gBannerTextColorRGB); Titlecase+ Bold)]

Set Field [uI Temolates::zz PrivilepeName Get (PrivilegeSetName)]

#End

Go to Layout [splash” (UI Templates)]

Perform Script [“Adjust Window based on Platform”]

#Added to track logins

If [not PatternCount(Get ( PrivilegeSetName) ; only”)]

New Window

Go to Layout [fmp user access list’ (fmp user access list)]

New RecordlRequest

Commit RecordslRequests

[skip data entry validation; No dialog]

Close Window [Current Window]

End If

Go to Layout [splash” (UI Templates)]

Perform Script [switch to Layout From Primary Menu”; Parameter: GlobalMenus::gMenu2]

Essentially the script is changing the menus being displayed, altering the size of the window and adding the logged-in user to a table (keeps track of who logged in)

Thanks again for your input

John

[bcooney]

"Now when the task launchers are run they open up the main FM database using the 'user1' credentials."

How do you know this? I don't see how a launcher doesn't get presented with a credentials challenge.

You cannot run a script in another file without sending that file credentials.

What is the ASDF script?

This whole idea of launchers to run tasks is new to me also, and seems like quite the security risk from your description.

[Wim Decorte]

The idea behind is to have a launcher file set up with the proper login creds in the File->Options section and that launcher file would then pull open (passing the creds in the process) the proper solution file.

And yes: it's a HUGE security issue. Anyone with access to the launcher file can use the script debugger to stop the process at any time and use the cred's priv set to see what they can do...

[bcooney]

Of course, Wim. It didn't come to me that that must be happening bcs I've never provided such a file to users. I've only used launchers to help users bypass Open Remote.

These launchers might be candidates for FM10 server scripts.

[Steven H. Blackwell]

[color:red]Please note carefully Wim's cautionary note here. If any file can be forced open without challenging a user for credentials, then there is almost no end to the mischief that can occur.

Steven

[jrb66]

Thank you all for your advice on the possible security implications. I will place this issue on the high priority list.

After much research regarding my initial problem, I have concluded the problem lies with Outlook and not Filemaker. I suspect a previous developer had modified code within Outlook so as to prevent the email dialog boxes from popping up.

Outlook apparently should always be presenting a dialog box when an application attempts to send email via Outlook. There are no external settings to disable this 'feature'.

I found a third party application which will automatically click the 'yes' button on one of the email dialog boxes whenever Filemaker attempts to send out email via Outlook. I had the system administrator make sure that he verified firewall and anti-virus settings as using an application like this could propagate virus/malware emails.

While this solution is not what I was hoping for nor expecting, it seems to be working for the moment.

Thank you all once again for your suggestions and advice.

John