Am I a subscript?

[David Nelson]

Seems silly that I can't get this. My boss with full access run a script from Manage Scripts which should only be fired as a subscript which requires that it runs on a specific layout. I will not go into the damage it caused but you can say that I almost had to go job hunting.

Two requests please that 1) how can that subscript find out if it is being rand from another script which it will be returning to after it ends or whether it was fired independently and 2) how do I tell it not to run if ran independently or if it is not on a layout with a base table in its name of payroll?

I told owner not to do that again but I want to make sure. I've tried a few things but I think they aren't safe and if I changed the script name it could easily fail. This subscript has script parameters passed to it already full of information such as StaffID etc so I can't just test that the parameter is empty unfortunately.

How do others protect from this and I thank you for considering my need.

[David Nelson]

I just remembered something I read somewhere about ability to get the underlying table ID. I do not think this is easily accessible but then I could verify that the tableID was correct even if the table occurrence name or layout name changes. I just need to be very safe with scripts so this never happens and now I worry about all hard-coding of layouts and table occurrences in scripts. In fact now I worry about everything. :hmm:

[Kris M]

Worrying about everything is not necessarily a bad thing.

If you need to prevent a user from taking actions then manipulating the security model is the best fix.

Security by obfuscation i.e hiding controls and menu triggers from the user, is not real security.....

I know of no way to trace the script execution order at run time unless its specifically written in the script and stored in variables or fields somehow.

[David Nelson]

Thank you for helping me Kris!

Yes, writing it into scripted SAFE standard process is what I want to pin down. On Security, boss is learning filemaker also and if something happened to me they still need full access. I am adding more protections there though even for full access. But still, even I could make such a mistake when debugging and actually I have by clicking closing window and script running anyway but this one wasn't me; this we know by the time and user stamps.

Subscripts are good when ran from different scripts but they are disaster if ran alone. I thought that if I always return to the parent script before ending then I could check for ANY script running and know it would be my parent. But I do not know if this will break when served and other users are on system or whether it is safe at all.

[dansmith65]

I think this is what you are looking for: http://filemakerstandards.org/display/cs/Layout+references

There is a link on that page to an ObjectID custom function which will return your layout's internal id, which will not change when the layout is renamed.

[jbante]

I agree with Kris that looking at the security settings is the best place to start. If your boss interacts with the database both as a user and as a developer, consider splitting those roles into separate accounts so the user role doesn't have privileges to call that script by itself. Since your boss still needs the [Full Access] account, it's still possible to execute the script, but at least it's more inconvenient to re-login to do it. (See postscript.)

This subscript has script parameters passed to it already full of information such as StaffID etc so I can't just test that the parameter is empty unfortunately.

So why is it that you can't test that the script parameter is empty? If your script is always called with parameters when it's called as a subscript, it makes sense to check that the required parameters are all passed, and to simply exit without doing anything if they aren't passed. When the script is executed directly by the user (not called by a button or script trigger), there is no parameter passed to the script, so the check for "IsEmpty ( Get ( ScriptParameter ) )" could suffice to trap for the situation of executing a script directly from the Manage Scripts window.

If your script doesn't already have at least one mandatory parameter, you can add one that doesn't communicate any information other than the fact that the script was called as a subscript. It might simply be the value of True (1), or it might be the name of the parent script — anything that the script would never receive when called directly.

If the script has negative consequences when run from the wrong context, it should probably have another check that it's in the correct context at the start even when it's properly called as a subscript — thus the interest in referencing FileMaker's internal IDs for layouts and table occurrences.

P.S. We aren't always comfortable thinking about it, but all security does ultimately boil down to making forbidden actions inconvenient. More security means it's more inconvenient to do something you're not allowed to. To be even more nit-picky, I'd say the security of a system is proportional to the product of how easy it is for users to do things they are allowed to do times how hard it is to do things they aren't allowed to do.

[David Nelson]

Yes, I will tighten the security and study that more, thank you Jeremy for helping on it. Empty parameter. I thought I had tried that. Maybe that was when I had it global variable or something. Too easy. Now I can go home for the day because you have solved this for me. I will make sure any script which has a subscript has something to pass it. Then I can test for empty parameter. Then I will make sure that the subscript ends by returning to the parent script before it ends and it can even test if anything went wrong in the subscript and do something else in response. see correction bolded please.

Well. At least right now that's my theory and I'm sticking to it. And I will focus on inconvenient protections. I really like how you explained that.

[LaRetta]

And David said that Jeremy said, "And I will focus on inconvenient protections." And consider it stolen from you both. I like the idea of a script which says, "Are you sure?" and then, "did you ask your boss?" and then "What's your favorite color" and then ...

Stolen: Dissuader - a sweet scripted path of inconvenience which may even include a few dead-ends to keep 'em off guard

Thanks for a wonderful smile, good information, and reminders! :^)

[Rick Whitelaw]

Who is the developer? You? If so, only you should have unlimited access to the file. Boss or not, if he/she is not developing the solution it should be a limited access situation.

My two cents . . .

[David Nelson]

My contract requires that two company employees know full rights to get in at all times. And I agree. What if I got mad and walked out? A company has to protect their investment same way a landlord can keep keys to their rental even if they should never enter without permission. I appreciate you taking time to respond. You are right Rick and I am going to tighten up somehow. But I cannot stop his access completely.

Yes, dissuaders for sure LaRetta. And major hint everyone: keep modification timestamp and user account so if something goes wrong you know who to blame. Okay, okay if something goes wrong it would be because I didn't do good job at least that is what my boss said, that I should have protected him from himself and he is right. However in my defense I am not a programmer nor am I getting paid like one. I do what I can.