Button Verb Permissions

ID:151768
 
May 1 2009, 5:07 pm (Edited on May 1 2009, 5:23 pm)
I'm just curious, with the BYOND 4 interface features, how do yall handle permissions with verbs you use on buttons?

You can hide them, but if a player has access to an input control that doesn't have a verb tied into it, they can still type it out in there.

You could make a lengthy system for adding and removing verbs as needed.

You could add a permission check proc at the beginning of each verb that checks to see if a certain window is visible or not. (This is the method I use)

Are there any other methods that I haven't thought of? What do yall think about each method?

As for me. I feel hiding verbs is just security by obscurity, and not really secure at all. If a player were to figure out that all my interface verbs began with "dmf", they'd easily be able to use them when they're not supposed to.

The method of adding and removing them as needed works well, but if you've got an interface-heavy game with dozens of buttons and are constantly opening and closing windows, it can really become bothersome.

The permission proc method seems to work well, but I really wish there were some sort of built-in method instead. Perhaps a "parent window" setting, that could accept a single window name or list of multiple windows.
May 1 2009, 5:28 pm
For buttons with verbs I do not want players to know about:

At runtime, you can winset() the (hidden) verb names in, if you do not want others to find out (not visible by modifying the skin).

In the said verbs, it is a really good idea to verify the conditions it should work in, in case someone typed in the verb.

:D
May 1 2009, 6:41 pm
I actually don't use verbs that much for interface controls, except when I don't care at all if the user is able to manually type it in.

Mostly I tend to set the commands of buttons to a nice byond:// URL and use Topic() to handle it all. I could send it to a central interface object or an object derived of such an interface object (where the child inherits the parent Topic()'s permission handling).

byond:// links even seem to work properly in input elements, although it is discouraged to do so (you can add your own arguments).
May 1 2009, 8:30 pm
Can always put a check to see if the window is shown, or wether the button is in the client.screen and visible.
May 1 2009, 9:12 pm
In response to Mysame
Yeah, that's what I do. Kinda like this:

client/verb
    dmfLoadChar()
        set category=null
        if(perm("login")) return
        //do stuff

client/proc
    perm(window)
        if(winget(src, window, "is-visible")=="false") return 1


But after reading GhostAnime and Android Data's replies, I'm thinking about changing my methods slightly... too tired to experiment with it now, perhaps later.
May 1 2009, 9:26 pm
In response to Zagreus
In addition to using Topic() for buttons, when needed I also save a list of windows that are currently supposed to be open on the client level.

That way, I can track which windows are open and which ones aren't. Even if a user is allowed to open a window by themselves without server intervention, I can reload the list of windows if the "is window open?" check has failed. If the check succeeds, I don't even need to talk to the client. And if the window was closed, and it needs to be noted, I can always use the on-close parameter to notify the server.

It's all about efficiency.
May 1 2009, 10:32 pm
In response to Android Data
Android Data wrote:
Even if a user is allowed to open a window by themselves without server intervention...

They can do that?

Darn... that pretty much ruins my method.
May 2 2009, 12:44 am
In response to Android Data
Apart from being less conventional, that's almost no different from using a hidden verb, so I don't really see why you'd want to do that. Well, I don't see how it offers anything more in terms of security/permissions.
(While it may be a little more flexible with arguments, if you require that you can simulate the same with verbs, or client/Command())
May 2 2009, 3:41 am
In response to Zagreus
Zagreus wrote:
They can do that?

It depends. If client.control_freak is enabled, you obviously control everything about the skin. If it's disabled, someone can venture inside the skin file and modify it, allowing them to open random windows.

Checking solely if a window is open isn't really enough. What you should instead be looking for is a list of windows the user can open in their current situation. If administrators are able to open up a window which contains an input element that will announce something to the world, you should check if the user is an administrator and if that feature is available to them.

I don't recommend enabling client.control_freak as this will just break BYOND's user-friendliness (lack of O&M pisses me off in games, especially the ones with poor skin designs, although in rare circumstances it can be helpful).

Besides, apart from the user modifying your skin you might have provided a window that opens up automatically for the user anyway. All it takes is a .winset command to open up a window and mess with controls, and that command is sure handy at times since it avoids additional network traffic.