Graal Forums - Protected variables

Graal Forums (https://forums.graalonline.com/forums/index.php)

- Future Improvements (https://forums.graalonline.com/forums/forumdisplay.php?f=10)

- - Protected variables (https://forums.graalonline.com/forums/showthread.php?t=71199)

Twinny

01-03-2007 01:26 PM

Protected variables

Similar to access specifiers in C++, it would be cool if we can create private or read-only variables so remote objects can't view and/or edit them.

I bring this up when as I realized that anyone could access the strings in my StaffRights dbnpc and read/change them. Thus I'd like an option to be able to protect objects and their associated variables. Only really needed serverside.

I have no idea how hard this would be to implement but cool if we could make variables read only or private/hidden.

Also, I'd also think it'd be great if we have an option to compile a weapon/class/npc 's coding with encryption. This could either be done by

Finalising and encrypting a NPCs code so it can never be accessed/changed again - only deleted
Encrypting a NPC with a password
Giving anyone with rights to the weapon the ability to encrypt / decrypt the NPC.

With the recent use of weapon scripts that can steal servers, this may be a useful addition as well. These may have been requested before. If this is a stupid idea, at least say why >_<.

xXziroXx

01-07-2007 07:48 PM

Quote:

Originally Posted by wiki.graal.net

const intVar = 3;
intVar = 4; // will not work
player.chat = intVar; // displays 3

That exists already.

Twinny

01-07-2007 07:55 PM

Quote:

Originally Posted by xXziroXx (Post 1262313)

That exists already.

The key point was modifiable within the local object whilst locked to others. Like private and protected access specifiers for C++

Angel_Light

01-07-2007 10:22 PM

Quote:

Originally Posted by Twinny

Finalising and encrypting a NPCs code so it can never be accessed/changed again - only deleted

An artist knows he has achieved perfection, not when theres nothing left to add, but when there is nothing left to take away.

Tyhm	01-08-2007 12:25 AM

Quote:

Originally Posted by Twinny (Post 1260257)

With the recent use of weapon scripts that can steal servers, this may be a useful addition as well. These may have been requested before.

Ah, innovation. If there was a Legal way to back up and transfer servers (GPAK), there wouldn't be such a propensity to steal servers...scriptkiddies always take the path of least resistance, if they coulda talked the serveradmin into lending them the scripts they woulda...

Twinny

01-08-2007 06:04 AM

Well with the addition of NPC server rights, stealing servers is a bit harder. But i still want private and protected variables >_<

Admins

01-08-2007 11:45 PM

Eventually we could add some kind of "this.protected.var" or similar, or "thisr."

Twinny

01-09-2007 05:09 AM

Great! ^^

Inverness

01-13-2007 08:49 PM

I prefer "thisr.", "this.protected.var" makes me cringe.

Tyhm	01-13-2007 08:58 PM

Agreed

Admins

01-13-2007 09:11 PM

Problem with thisr. is ... then we also need thisor., gets complex :D

Inverness

01-13-2007 10:28 PM

Quote:

Originally Posted by Stefan (Post 1264564)

Problem with thisr. is ... then we also need thisor., gets complex :D

You have a point ;)

How about something in the TGraalVar that when true makes an object only editable by its 'parent' object? I assume that variables are subobjects of the script?

object.protected(true/false);
object.final(true/false);

Opinions?

Twinny

01-14-2007 07:39 AM

this.test = new TProtectedString();

or something similar to that could work ^^.

Skyld

01-14-2007 01:57 PM

this.protected.var seems reasonable enough if it clears the thisor. problem.

Inverness

01-15-2007 02:56 AM

Quote:

Originally Posted by Twinny (Post 1264783)

this.test = new TProtectedString();

or something similar to that could work ^^.

Why have to do that when you could simply make 'protected' an attribute of all Objects?
Object.protected = true/false;

Tyhm	01-15-2007 05:57 AM

Because it'd be one more bit applied to every variable ever...?

killerogue

04-02-2007 06:43 AM

Hate to revive this but I love the idea of password protected NPCs and encrypted ones as well.

Twinny

04-02-2007 02:03 PM

Heh..i'd much prefer my original idea of protected vars. this.protected.var would be awesome but this.var.protected = true; could also be cool ^^.

But soon!

Tyhm	04-02-2007 08:31 PM

Maybe if we just had more control over public and private variables...I don't know if I like the idea of classes being downloaded onto the client so they can see "Huh, whatever variable z01 is, that's the password...so I'll just say that, and it'll match it up...oh, I see, they have it scripted so I have to say the password backwards...well, I say that then."

Twinny

04-03-2007 12:01 AM

Quote:

Originally Posted by Tyhm (Post 1295976)

Ahh.... where did classes come from? Or clientside for that matter? >_<. A protected var could be like a var within a DBNPC serverside. Client has the same access it has had as always: none while serverside scripts would also be unable to access it. There's no loss of security with protected vars >_<

Tyhm	04-03-2007 12:49 PM

Piffle, I could care about internal security (the relative risk of people who already have access to RC), but I shan't. It's not the sort of thing that seems to merit having its own script to repair.

Twinny

04-03-2007 01:48 PM

Quote:

Originally Posted by Tyhm (Post 1296354)

Piffle, I could care about internal security (the relative risk of people who already have access to RC), but I shan't. It's not the sort of thing that seems to merit having its own script to repair.

Then what are you caring about?

I requested protected variables. Kinda like making bank flags protected variables so staff members with any kind of script access (eg. level, weapon etc.) couldn't access the flags and change them from another object. Could also be like making a mud library into a DB with protected vars so weapons / items can't be changed without using the actual DB itself - thus logged. I don't see why we can't have it?

Quote:

Originally Posted by Tyhm (Post 1295976)

Maybe if we just had more control over public and private variables...

We currently have no control of such things - they don't exist for developers.

Quote:

Originally Posted by Tyhm (Post 1295976)

I don't know if I like the idea of classes being downloaded onto the client so they can see "Huh, whatever variable z01 is, that's the password...so I'll just say that, and it'll match it up...oh, I see, they have it scripted so I have to say the password backwards...well, I say that then."

No idea where that thought came from. In anycase, protected vars would be wasted clientside anyways. All important information should be held serverside.

Twinny

06-25-2007 12:14 PM

I've recently given this a bit more thought and I think this could work

Private Variables: Set by default, only the current object and all child objects can access variables.

Trust Variables: An extension of private. All variables will become private but you can add what objects are trusted. For example, a DBNPC called System may have trust with a DBNPC called Accounts. This one is not as important but it would be cool

Public Variables: When created, the player will have to set the variable as public. Public variables will have two settings: read and read/write. This could be done like

PHP Code:


		
			
obj.public=0; // Variable is private
obj.public=1; //Object is public read-only
obj.public=2; //Object is public read/write

Although the two levels of public variables aren't vital as such, they would definitely be handy. These settings should also use inheritance although a child can change it's variable settings if desired.

Doable? :D

zokemon

06-25-2007 11:25 PM

Can't make private variables by default as it would mess a lot of servers up. Maybe like a server option: privatevariablebydefault=true or something
I also posted this in another thread:

Quote:

Originally Posted by zokemon (Post 1322423)

Yeah I was thinking about that...
You could just do like:

NPC1:

NPC Code:

function onCreated() {

  public this.myvar = "Hello!";

  NPC2.getMyVar();

  private this.myvar;

  NPC2.getMyVar();

}

NPC2:

NPC Code:

function getMyVar() {

  echo("Test Results: " @ NPC1.myvar);

}

Echoed text:

NPC Code:

Test Results: Hello!

Test Results:

Color coded to show you the format of the code too ;P
(You would use public and private much like you use new, if, else, while, do, etc.)

Inverness

06-26-2007 02:21 AM

I think I would prefer private/public status to be set using a function on the object, that way you could make a function to set the status of many variables at once.

Twinny

01-22-2008 01:40 AM

I still desire these updates! Callstack access does rock but with protected vars: ultimate security! I will love you long time and bake many pizzas should you add this ^^

Admins

01-23-2008 04:21 AM

Hmmm In some languages there is a way to "freeze" an object. The variables of the frozen object cannot be edited anymore. That could eventually be added to Graal to make stuff like the DB-npcs not-modifiable. Eventually we could also make it so that you can "freeze" the object but still allow modifications from within the object itself.

A major problem for private variables is more the speed though, because it will need to check for each operation if the operation is allowed from the current object. Languages like C++ and Java only do private/protected stuff by the compiler, it's still possible to access those variables from outside with some tricks at runtime. So the scripting engine would need to remember the access rights for each object and check for access rights when the variable is read or modified.

A "freezing" mechanism could make that faster because it would only set the access flag for all sub-variables at the time you freeze the object, and later just check for the access flag. It could also automatically block all attempts of calling join which could be used to extend the script of an object and then send a trigger to it to modify its own variables.

cbk1994

01-23-2008 04:29 AM

One way you could do staff rights systems for now would be to use a system like this:

Have a folder that only the owner/manager and only essential staff have access to. In there, keep a file of flags (XML, saveVars, however you prefer to do it), and then each time you want to access something, reload it. Only save it when the function is called, etc. It's not that complicated, but could be difficult to implement. I find it nice to have a folder that only essential staff have access to anyway. Of course, hypothetically, you could just make a new folder, but many UC servers give every single staff rw */*, etc and then if they don't have that, everyone has change folder rights.

Just an idea.

zokemon

01-23-2008 04:43 AM

Quote:

Originally Posted by cbkbud (Post 1371370)

Anyone with script rights could savevars/savelines over said text file though.

cbk1994

01-23-2008 05:05 AM

Quote:

Originally Posted by zokemon (Post 1371377)

Anyone with script rights could savevars/savelines over said text file though.

True.

New solution: script the whole damn server yourself. Noone else deserves rights! It is YOUR server, after all!

I suppose, if all else fails, you could even manually edit the file, or, easier, just make a folder in your private folder where you have files such as rights_cbk1994.txt, and in it just a list such as

PHP Code:


		
			
summon
boots
totalabuse

where it is read. Trickier to do, but probably more secure. Then you could simply give the (npcserver) read rights to it.

Twinny

01-23-2008 05:21 AM

Quote:

Originally Posted by Stefan (Post 1371369)

Whatever works best so long as objects can't read/write to frozen variables ^^

Would this be a next Gserver update? :D

Crow	01-23-2008 04:15 PM

Quote:

Originally Posted by zokemon (Post 1371377)

Anyone with script rights could savevars/savelines over said text file though.

Remove NPC-Server access to the folder and manually add/remove rights.

bscharff

01-24-2008 02:40 AM

With the new callstack function, we could easily do some sort of protection.

Stefan could add some sort of onStrChanged(str, str, obj, str)
params[0] could be the string being modified
params[1] could be the new string value
params[2] could be the object that is changing it
params[3] could be the old string value

Then add a check like if onStrChanged() is in the object's functions (the one with the string being modified - to relieve any possible confusion) then run through the function, otherwise, just modify the string without any nonsense.

cbk1994

01-24-2008 03:07 AM

Quote:

Originally Posted by Crow (Post 1371471)

Remove NPC-Server access to the folder and manually add/remove rights.

Yah, basically what I said in my correction post ;)

Quote:

Originally Posted by bscharff (Post 1371609)

Except you'd get that called many, many times a second. Think. Every single variable.

Twinny

01-24-2008 03:37 AM

Quote:

Originally Posted by bscharff (Post 1371609)

onStrChanged()...... some of you people really don't seem to be getting this....when i say protected/private variables, only the local object can even see them let alone write to them! Other objects can't even read their contents or know if they exist!

Inverness

01-24-2008 03:38 AM

Well I suggested onVarChanged() along time ago myself.

By the way, you should call them variables instead of strings.

Also, I had thought it might be a better idea to be able to define a read and write function for a variable, easily making variables read only or private or be able to notify the object of changes.

Something like this:

PHP Code:


		
			
function onCreated() {
  this.join("util_callstack");
  this.strvar = 0; // initialize it (insurance)
  this.strvar.setreadfunction(this.read_strvar);
  this.strvar.setwritefunction(this.write_strvar);
}
// The actual value would be stored invisibly by GScript and only provided as a parameter when the read or write is called.
// This is example of private variable using this method.
function read_strvar(value) {
  if (getcallingobject() == this) {
    return value;
  }
  else {
    return null;
  }
}
// the new value of the 'variable' would be returned and GScript would catch the return value and assign it to the variable internally.
// indexes parameter would be an array of indexes used with the variable.
// ex: this.var1[3][5] = 4; would call: write_var1(<currentvalue>, 0, 4, {3, 5});
function write_strvar(value, operation, newvalue, indexes) {
  // getcallingobject() is class function of util_callstack
  if (getcallingobject() == this) {
    switch (operation) {
      case 0: // =
        value[indexes[0], indexes[1]] = newvalue;
        return value; // Gscript catches the return and sets that return to the variable's value.
      case 1: // +=
        value[indexes[0], indexes[1]] @= newvalue; // string append instead of addition.
        return value;
      default:
        return value; // no other operations allowed for the variable.
    }
  }
  else {
    return value; // value is not modified, it is a private variable
  }
}

Ideally if something like this were implemented it would only produce a slowdown with variables that are specifying a read and write function, or just one of the two.

And a more secure method would probably be a new type of script function definition:

PHP Code:


		
			
function onCreated() {
  this.join("util_callstack");
  this.strvar = "3"; // is using the special defined functions.
}
varread strvar(value) {
  return value;
}
varwrite strvar(value, operation, newvalue, indexes) {
  // do stuff
}

Its a stretch but its something I think might be interesting if used properly.

Admins

01-24-2008 12:26 PM

Well we could eventually start with adding some flag to complete block access to variables from outside, and then you write functions for retrieving data.

The syntax for getters/setters would look more like "function set varname(value)" and "function get varname()" to be compatible with ECMA/JavaScript.

Twinny

01-25-2008 12:12 AM

Quote:

Originally Posted by Stefan (Post 1371679)

That or perhaps add a new section for variables like this.private.vars . That way the engine knows straight off that it can't touch other objects vars contained within obj.private

But whatever works ^^

All times are GMT +2. The time now is 11:16 AM.