Major Player Macro Access Problem

[brad]

I don't know if I just didn't understand something and made a coding mistake or if this is a bug, but here is my problem. Attached is a campaign file with a new framework I made for Savage Worlds. I have it setup so the players click the "character sheet" macro in the Campaign Macros window. That opens up their character sheet frame and everything else for the game is run from there. Now if you have not opened up your character sheet yet and you select a token other then one you own and hit the "Character Sheet" macro it will say you can't do that. However, if you first open your character sheet frame and then click on another token you do not own(pc or npc), you can then start clicking on the macros in the character sheet and it will start accessing the information in that token that you do not own and running any of the macros off of the character sheet using the token you do not own(pc or npc).

I thought with Strict Token Ownership selected and all macros stored in a lib token that such a thing would not be possible. Is there some step in the macros language coding security that I missed? Thank you for any help.

I am using 1.3v87.

Wolluck.cmpgn

MapTool v1.3b87

(1.56 MiB) Downloaded 44 times

[Azhrei]

I thought with Strict Token Ownership selected and all macros stored in a lib token that such a thing would not be possible. Is there some step in the macros language coding security that I missed?

Hm, I'm just shooting in the dark but I'm betting that the macros are trusted and therefore can bypass the normal token ownership (that why trusted macros can access properties on tokens the player doesn't own). It's likely the macro is using Wiki: getSelected() without also checking Wiki: isOwner() (or similar).

[brad]

It's likely the macro is using Wiki: getSelected() without also checking Wiki: isOwner() (or similar).

Neither of those functions are in any of the macros. In terms of automation I purposely kept it limited. More or a record keeper with shortcuts for rolls. Do I need to do something like put [h: abort(isOwner())] at the beginning of every macro?

[Bone White]

The way my framework decides which token you can "access" as a player, is run off this line of code:

[code=php]    [h: selected = getSelected()]
    [h, if(listCount(selected) > 1): abort(0)]
    [h: name = getPlayerName()]
    [h: areYouOwner = isOwner(name, selected)]
    [h: gm = isGM()]
    [h, if((areYouOwner == 1)||(gm == 1)), code: {};{[h: assert(0,"You do not own this token!",0)]}] [/code]

[Azhrei]

It's likely the macro is using Wiki: getSelected() without also checking Wiki: isOwner() (or similar).

Neither of those functions are in any of the macros.

Mr. White has the right of it. The typical approach would be to use getSelected() and create the list of tokens, then isOwner() to determine whether the player is allowed to access the ones he has selected. If you're not using those, then the macro isn't doing sufficient permission checking and that's where the problem is coming from.

[brad]

Thanks for the help and guidance. Not being a programmer I just made an assumption that made sense to me. And making assumptions is what will get you in trouble. The assumption was that token ownership was security and that you couldn't mess with a token you didn't own unless a macro that was stored in a lib token specifically reached out to a token you didn't own. Live and learn.

[Mrugnak]

The assumption was that token ownership was security and that you couldn't mess with a token you didn't own unless a macro that was stored in a lib token specifically reached out to a token you didn't own. Live and learn.

But that's exactly what's happening here. Trusted Macros stored in lib tokens are being executed on a token you don't own.

The part that you missed is that when you select things, you tend to be setting the target for macros. . . There's a whole bunch of functions that (if you don't explicitly provide a token ID) will assume you mean the selected one.

[brad]

The assumption was that token ownership was security and that you couldn't mess with a token you didn't own unless a macro that was stored in a lib token specifically reached out to a token you didn't own. Live and learn.

But that's exactly what's happening here. Trusted Macros stored in lib tokens are being executed on a token you don't own.

Not what I said actually. Yes, a macro is being run on a token I don't own. Didn't think that would be possible all by itself and I bet there are a bunch of non-coders who are trying to make the macro language work that assume it as well. I assumed if I was running a macro that originated from my token and it reached out to a token I didn't own to access information from that unowned token, that could happen if the macro was stored in the lib token. Just clicking on a token that I don't own and being able to run a macro seems very wrong and I remember that it used to be that it could NOT happen. Seems like a dangerous thing to me.

[Mrugnak]

I assumed if I was running a macro that originated from my token and it reached out to a token I didn't own

The disconnect in your mental model is that the macro doesn't originate from your character token. There are no macros on the player tokens at all, and therefore none of the player tokens can originate macros.

The macro originates from the token its stored on (or from the campaign etc). The panel you have up, showing the character sheet, doesn't call macros from the token its displaying, it calls macros from the lib:token that runs the macro that creates the panel.

The lib token accesses the selected token on behalf of the player who executes the macro, but it isn't the player, and can't be. That's actually one of the main points/features of lib tokens, so it really can't be changed.

[brad]

The thing is the macro to open the character sheet is stored in the Campaign window and it checks for ownership or the origination token(or whatever the proper term would be). It won't let you run it if you don't own the selected token. As soon as the character sheet is open though, everything is fair game. No checking, all the links to macros run those macros, no matter what token you choose. If you feel like explaining that, I am very curious. Don't feel like you have to, but it doesn't make a lick of sense to me.

[Azhrei]

The thing is the macro to open the character sheet is stored in the Campaign window and it checks for ownership or the origination token(or whatever the proper term would be). It won't let you run it if you don't own the selected token. As soon as the character sheet is open though, everything is fair game. No checking, all the links to macros run those macros, no matter what token you choose. If you feel like explaining that, I am very curious. Don't feel like you have to, but it doesn't make a lick of sense to me.

Hm. Methinks we need an analogy...

Suppose your brother is the macro that's in the Campaign panel.

Suppose your brother's friend is a police officer (the macro on the Lib: token).

You can ask your brother to do something and he can relay that request to his friend. If his friend thinks it's a good idea, he may do it or he may not. If your brother doesn't even relay it to the cop, then the cop will never even know you made the request.

That is what happens when you click on your brother (oops, I mean the Campaign panel macro).

Now suppose that the request your brother makes to the cop is to conduct surveillance on his girlfriend (he suspects her of cheating). But the girlfriend was only identified by providing the address where she lived, so the cop watches for a woman coming out of that building and follows her around, possibly pulling DMV records and other shady things. (This isn't a perfectly legit use of his authority, but your brother is a really good friend of his!)

Only problem is ... the woman he followed wasn't your girlfriend! It was the roommate that also lives at that address! So the cop has just been following (some would say, "stalking") the wrong woman.

That's the problem with the character sheet. Once it's opened up, the sheet has all of the authority that the cop would have to sniff around and poke into personal affairs. So someone has to make sure that the cop doesn't run rampant and investigate the wrong people. (I.e. your macro needs to be careful about which tokens are selected when you perform operations on tokens or you might get the wrong one.)




That's not a perfect analogy, but it's pretty close. There are numerous details that don't fit, but that's what you get for an off-the-cuff analogy.

[brad]

Thanks Azhrei. I love analogies. They are just plain fun. So, I get it now. The ownership police only live in the macro panels. Period. Even if links you create originate in panel world, none of that security follows. You are just creating a land of chaos and you have to impose martial law on every single aspect of it yourself.

[Mrugnak]

Thanks Azhrei. I love analogies. They are just plain fun. So, I get it now. The ownership police only live in the macro panels. Period. Even if links you create originate in panel world, none of that security follows. You are just creating a land of chaos and you have to impose martial law on every single aspect of it yourself.

Bingo!

You made the macro check for ownership on the campaign macro, but MapTools doesn't save that information unless you tell it to, and other macros don't have access to it unless you specifically pass that information to them (or they go check it for themselves). And of course the other macros will use it once and forget unless you specifically save the information somewhere... AND go check that saved information
The exception is strict token ownership and macros on player tokens, because Maptools itself is told to check ownership and access permissions every single time (when strict token ownership is on)... because some programmer(s) told it to

Computers are stupid, literal minded genies. I'd say that's where being a programmer by trade is so helpful - we're used to how incredibly dumb they are

There's a similar situation in some of the older "low level" computer languages, like C and C++ - only it's worse because you can tell your program to read or write some location in memory, and if you told it the wrong thing, you might find yourself writing over your video drivers, or over some critical part of the operating system, and then suddenly your computer blue screens (or segfaults, or sad-macs) Modern operating systems have something like the strict token owernship going on, however - a lot of "Um, I didn't set aside that section of memory for you, why for you write there? Stoppit." which cuts down on the "oops I exploded my computer" problems while learning

[brad]

You made the macro check for ownership on the campaign macro, but MapTools doesn't save that information unless you tell it to, and other macros don't have access to it unless you specifically pass that information to them (or they go check it for themselves).

And here is where we are having a disconnect and where my confusion stemmed from. I did NOT have MapTool check for token ownership in the Campaign macro. The Campaign macro is a call to a macro in the lib token(like all the links in the character sheet it creates are). There was absolutely no ownership checking at all. But if you clicked on the macro button and didn't own the selected token MapTool cried foul and didn't let the macro run and create the character sheet. But, if you did own the token and created your character sheet then suddenly when you are clicking on links in the character sheet which are just macro calls, like the one in the Campaign window, ownership checking by MapTool stops. I may not be a programmer, but I have made a couple other larger frameworks by trial and error(and error and error...) and am aware of macros forgetting information as soon as they stop. The checking ownership with one macro call and then not with another is what was throwing me. But, now I get it. MapTool checks for ownership with no prompting for macros that are run out of its various panels, but not anywhere else, even if the links originated from a macro in those policed panels.

[CoveredInFish]

I guess when Rumble added the "unowned token select"-option to MT - and thats an awesome feature that opened a lot of possibilities - he lay responsibilty of this enhanced selection situation into the hands of the macro coders. If you write trusted macros you have to consider whether you have to check for ownership or not. Not every use case is still in the boundaries of the maptool security mechanisms.