Suggestion: CrossFuncScript, CrossFunc restrictions

[DorkeyDear]

Due to the fact that the Soldat Server Scripting Core suggestion thread is no longer being monitored, I thought it would be appropriate to post here.

A built in variable CrossFuncScript: string; which gets changed every time (right before) CrossFunc gets called to the value of the script calling it. If the script does not exist, the setting of the variable is up to you (EnEsCe) (if it is to be implemented).

A method to restrict certain CrossFunc function calls:
script Foo:

Code: (pascal) [Select]

procedure MyFunc();
begin
  WriteLn('MyFunc');
end;

procedure ActivateServer();
begin
  AddCrossFuncRestriction('MyFunc');
  MyFunc(); // 'MyFunc' gets written in the console
end;
script Bar:

Code: (pascal) [Select]

procedure AppOnIdle(const Ticks: cardinal);
begin
  CrossFunc([], 'Foo.MyFunc'); // no action, or exception
end;
Having the CrossFuncScript variable allows ourselves to create CrossFunc restrictions based off of scripts, thus its not completely necessary (but it still would be useful).

If CrossFunc restrictions are to be built in, I suggest:
procedure AddCrossFuncRestriction(const FuncName: string); // only the script calling this can allow it; cannot CrossFunc this function (afaik, you can't CrossFunc built-in functions anyways)
procedure DelCrossFuncRestriction(const FuncName: string); // obvious
function IsCrossFuncRestriction(const Script, FuncName: string): boolean; // for any script, can check if a certain function is allowed or not (true means not allowed); maybe named IsCrossFuncRestricted
I'm sure there could be other functions that could relate.

If just CrossFuncScript is to be implemented, a quick example to create home-made restrictions:

Code: (pascal) [Select]

function IsCrossFuncRestricted(const FuncName: string): boolean; // since each script can supply this function separately, the "const Script: string;" parameter is unnecessary
begin
  Result := (CrossFuncScript = 'Bar') and (FuncName = 'MyFunc'); // or even Result := (CrossFuncScript <> ScriptName) and (FuncName = 'MyFunc'); to not allow any script calling it
  CrossFuncScript := ''; // so if somebody CrossFuncs MyFunc, and then this script normally calls it, it doesn't think it was a CrossFunc that caused it and end up denying it when it should be allowed
// or can use an array of functions not allowed (and even could create custom functions to add / del functions), or just an easy switch case statement; any of them could work
end;

procedure MyFunc();
begin
  if (IsCrossFuncRestricted('MyFunc')) then
    exit;
  WriteLn('MyFunc');
end;
Toumaz brought up a good point; what purpose could it possibly be used for (not in those words)? Purpose:
If there is something vital to the script, or that may be a security issue if somebody access it (or stability issue, or any other kind of issue), restricting would be a great idea.
For instance, if I have a function that does either sql-related actions, socket-related content, website content receiving (that has side effects), etc., these could ruin stats / supply inaccurate information / break something / etc.

[iDante]

Cross-script security usually isn't that big of a deal because of the open nature of scripts. It seems like this is just an attempt at encapsulation within scripts, which isn't a problem atm. Server owners have control over what scripts are executed on their servers and if one is causing a problem then they can remove it.

[DorkeyDear]

open nature of scripts

They can be encrypted (for security or copyright reasons, or whatever other reasons there are). I am currently working on a script (which is planned to be partially encrypted (afai've been informed u can combine encrypted and non-encrypted files)) which will have 'security issues' if other scripts have access to certain functions.
Example: Stats-related, script A will be encrypted so u can't directly edit it, but if B tells A (by somehow finding the function name, or by guessing it ) to add 1000 kills to player id 2, the stats will be ruined. Other things along those lines can also be issued.

[jrgp]

If scripts aren't individually sandboxed, they should be.

[DorkeyDear]

If scripts aren't individually sandboxed, they should be.

If a script needs to pass on a bunch of the events onto other 'sub-scripts' (addon to the main script, which could be another script and communicating via CrossFunc, or directly as a sub-script), the naming of the events would be a pain, because you would need a list of these sub-scripts, plus possibly a 'register events' function, so ActivateServer and ApponIdle can all be registered with different function names (kuz the normal ones are already in use by the main script)

I have another idea for an alternative way to create the CrossFuncScript:
Create a custom CrossFunc function in script B that also CrossFuncs the function 'SetCrossFuncScript' and parameter being ScriptName right before the normal CrossFunc
Create the SetCrossfuncScript in script A, which simply sets a variable to the value of the string parameter.
In script A, all functions could start with a quick check IsCrossFuncRestricted(funcname: string) and inside that, reset CrossFuncScript to '' (or in each function) to avoid some other script (or script A) CrossFuncing (or calling) a not-allowed function from the previous script calling (that set the CrossFuncScript).

Disadvantage: Scripts can lie, and say it is something that it is not. Although, it may be possible to encrypt the file and rename SetCrossFuncScript to something less easily guessable (or possibly randomly generate the function name on compile, then recompile and doing some WriteFile (or alternate ways) stuff to make it so it knows it shouldn't try re-generating the script and recompiling again).