Maptool: Players cannot call 'broadcast()' function on trusted function through a macroLink

[melek]

Describe the bug
For players, the 'Broadcast' function (and other trusted functions) issue an error when called by macro links displayed in a frame created by a normal token macro, even when the frame-creating macro is not player-editable.

To Reproduce
Steps to reproduce the behavior:

1. Create a normal token and a new macro button on that token. Make sure 'Allow players to edit macro' is unchecked.
2. Set the macro command to the following:

[h: broadcast("Test - Broadcasting")]
[frame("Test"): { [r: macroLink("Test", getMacroName() + "@TOKEN", "", "Test", currentToken())] }]

1. Click on the new macro. A broadcast message will issue and a frame will open, click the 'Test' link in the frame.
2. See expected output when playing as GM:

Test - Broadcasting   //Invoked on button click
Test - Broadcasting   //Invoked on macroLink click

1. Start the server and connect as a player with a second instance of MapTool.
2. Give the player instance ownership of the token.
3. On the player instance, click the macro to open the frame and click the 'Test' link.
4. See erroneous output:

Test - Broadcasting //Invoked on button click
You do not have permission to call the "broadcast" function.   //Error upon macroLink click

Expected behavior
I would expect the 'broadcast' function to behave the same whether the button is clicked

MapTool Info

• Version: 1.5.14 & 1.7.0
• Install: New alongside other versions

Desktop (please complete the following information):

• OS: Win10

Additional context
I wonder if I may misunderstand a security feature here, but it feels inconsistent for broadcast to only function from a token macro for players if the button is directly pressed, rather than if the macro is called via a macroLink that could only be accessed by owners of the token.

[Merudo]

Maybe the macro should be allowed if the macro is not editable and the token is owned by the player.

[melek]

I think so! The 'trusted context' thing is a bit mysterious to me, but I think this is a reasonable use of macros.

[Merudo]

I just realized there could be a security risk.

Someone could create a token with protected functions doing naughty stuff, then set "Allow players to edit macro" to false.

If that token is dragged and dropped on the map as player, it would also the player to use those forbidden macros.

[Phergus]

And this is why you don't put actual macro code on a Token macro. Instead they should always be:
[r: callRealMacro()] if using UDFs
or
[r, macro("realMacro@lib:stuff"),""] or [r, macro("realMacro@campaign"),""]

At least, that's my preferred way.

[melek]

I understand there are other, probably better approaches. I guess my question is getting at a deeper issue that trusted contexts are a bit confusing.

For instance, broadcast is a function that can only be run in a trusted macro, but works fine when clicked on a player token that is not editable by players. I think that it should work exactly the same when called from a macroLink as it does when you click the button (with the possibility for arguments, of course).

On the wiki, there are three criteria to count as a trusted macro. When checked against players clicking a macro using the broadcast function, it shouldn't be trusted or work all:

• [X] A trusted macro must not be editable by players
• [X] A trusted macro must not call another macro that is not trusted
• [ ] Clicking the macro button as a GM
  - OR - Placing the macro on a library token and having a player call it using a roll option or macro link.

However, further down that page there is another list of scenarios where the broadcast function in my example macro _should_ be trusted, as should the same macro called from a macroLink:

• [X] Any auto execute macro that is non player editable is trusted.

I'm not sure which of these conflicting sets is 'correct', though the table on that page helps illuminate that it is known that player tokens can contain trusted macros. It seems like an 'anti-workaround' to prevent frames from calling these same macros as trusted.

As far as any exploit that lets players create and run macros by disabling 'allow players to edit', I think those exploits are separate issues.

[cwisniew]

So for macro links (either in frame or chat).
Its a bit hairy...

A macroLink should obey the if its non player editable its trusted. It should really not obey the "if the GM clicked on this is trusted" (unless it meets the above criteria) otherwise players can spam links to non trusted macros and an unwary GM would run them as trusted if clicked on

[melek]

What about a player clicking a macro link to a trusted macro which resides on a token they own? That is the case I'm trying to grok.

I've been reporting variations of this issue (#1817 #1894, thank you!!), and am wondering if there's something weird in general going on with macroLinks in frames...

[Merudo]

So a requirement for @TOKEN permissions:

• The macro must not be editable

Is this enough? Or do we need one of the following:

• the calling macro is trusted
• the player is a GM
• the player owns the token

[Merudo]

PR #1941 allows token macros ran via macroLinks to be trusted if they are not Player Editable.

[melek]

They must be set to 'Autoexecute' as well I believe - excited to see this!

[Merudo]

Not sure if I understand the logic of treating macros with Autoexecute differently.

[melek]

I admit I don't either, except to say auto-execute prevents editing by the player in chat before being run.. though I have never ever used a non-auto-execute macro so I'm just going by the Wiki.

[Merudo]

With auto-execute sets to off, clicking on the macro just copy the macro's content to the command box, so it ends up being the same as typing the code directly into the chat.

[melek]

So it will become untrusted when copied to a player's chat box and run anyway, it sounds like!

[Phergus]

Tested changes. Provided use case works as expected now.