Authors CurseForge

I would like to extend the LDB spec for displays that would like to add support for secure stuff (mostly buttons). But Im just a plugin author, not a display author (yet), so implementation need to be discussed. Here is how I see it:

The secure object requires 2 DO's attributes, both set by the plugin at DO's creation time:
- one string (DO.secureTemplate) that hold a list of secure templates. It will be used by the display when calling CreateFrame to create the button. This is the attribute of choice for the display to check if we have to deal with secure stuff.
- one function (DO.OnCreate) that will be called by the display once it has set everything, to let the plugin implements the secure templates. Function definition: function( DO, button ). The DO argument is also interesting for plugins that want to create multiple blocks and don't know what block is entered; with that it could set cross references between DOs and buttons, and more.

The function attribute may also be used by non secure objects as a way to get cosmetical informations (ie: a plugin could retrieve the font to apply it on its tooltip to look more integrated, and with libTooltip coming soon that may be interesting).

These 2 attributes don't require any callback registrations, as it is only used to initialize the button.

@Tristanian: IMHO there's no need for exemples, reading comments from FrameXML\SecureTemplates.lua and associated files, and, why not, the new secure system with wrappers and snippet of code here, will highlight possibilities, then it's up to the author to find what he want to do with all that. Think of possible combat management if you want.

The important part is how scripts/attributes/wrappers are handled, who use what, etc.

If it helps displays, we could set the "type" attribute to something like "secure". But the plugin will still have to provide the secure templates so that could be redundant, not to mention that "type" attributes may not be all exclusive.

(more to come ?)

I'm seeing the type attribute for exactly this type of thing. If the Display doesn't check the type then it's the Display's problem. Just pick a type and go to town imo, publish what you expect the spec to be for that type.

Imo :

1) DO.type = "secure button" (suggest something else if you want to)

2) DO.secureTemplate - a table of templates I guess or ?

I guess it won't be a problem to use this anyway but I'd prefer a type check as well to easily distinguish between buttons tied to secured templates and regular DO buttons.

3) DO.OnCreate ( object, frame) I guess.

Since I'm not that familiar with secure templates, I guess you need to enlighten me. Are you setting any sort of script handlers on this func or just attributes/initialization so to speak. When I was talking about an example, I meant a plugin example, looking at code would simplify this a lot :p

Aye the frame should be fine, we can work with that I guess and potentially use secureTemplate attrib as a "reference" for any future checks (if needed).

Here is the *alpha* plugin I use to test secure stuff: http://perso.orange.fr/aranarth/wow/addons/Ara_Broker_Poisons-r2.zip (only tested with wotlk beta client).

Currently, it doesnt provide an alternative for non-"secure compliant" displays, and simply doesn't show any menu OnEnter.

It requires the display to use "secureTemplate" and "OnCreate" (I already provided implementation samples in previous posts). The difficult part is to not override the secure button with conflicting scripts (like OnEnter, if Funky can confirm :p) that's where you check for the presence of "secureTemplate" on the DO to not apply these scripts (or add wrappers/snippet ? to dig). I need more tests now to give more info.

Be sure to buy some poisons, or bring oils (or warlock stones) to populate the plugin's buff menu (you can check the list of supported consumables in the code).

@Funky: the config menu doesnt taint anymore on right click. The only thing I found that taint is when you check/uncheck the option to show/hide the buff frame while in combat. It just needs to be grayed out.

(The initialization process of this "crash dummy plugin" is not easy to follow because I wanted to support AddonLoader. That complicated things. And right now I disabled it on the toc file because of a Blizzard bug with LoadManagers and LoadOnDemand :()

@Tristanian: here is an exemple of a "secureTemplate" value: "SecureActionButtonTemplate,SecureHandlerEnterLeaveTemplate". It is used as 4th argument to CreateFrame. As Funky said, if the attribute is nil, the button will simply be non secure. (EDIT: the forum mangled the secureTemplate !! :p)

Would it be possible to get LDB display addons to implement OnDoubleClick? NRT, a FuBar addon, uses double clicks as a trigger to cause raid attendance to be taken, but when used as an LDB plugin via Fubar2Broker this functionality is lost because both F2B and all displays I've tried (admittedly only ButtonBin and Fortress atm) don't implement OnDoubleClick handlers/events.

Quote from ara2

Here is the *alpha* plugin I use to test secure stuff: http://perso.orange.fr/aranarth/wow/addons/Ara_Broker_Poisons-r2.zip (only tested with wotlk beta client).

Currently, it doesnt provide an alternative for non-"secure compliant" displays, and simply doesn't show any menu OnEnter.

It requires the display to use "secureTemplate" and "OnCreate" (I already provided implementation samples in previous posts). The difficult part is to not override the secure button with conflicting scripts (like OnEnter, if Funky can confirm :p) that's where you check for the presence of "secureTemplate" on the DO to not apply these scripts (or add wrappers/snippet ? to dig). I need more tests now to give more info.

Be sure to buy some poisons, or bring oils (or warlock stones) to populate the plugin's buff menu (you can check the list of supported consumables in the code).

@Funky: the config menu doesnt taint anymore on right click. The only thing I found that taint is when you check/uncheck the option to show/hide the buff frame while in combat. It just needs to be grayed out.

(The initialization process of this "crash dummy plugin" is not easy to follow because I wanted to support AddonLoader. That complicated things. And right now I disabled it on the toc file because of a Blizzard bug with LoadManagers and LoadOnDemand :()

@Tristanian: here is an exemple of a "secureTemplate" value: "SecureActionButtonTemplate,SecureHandlerEnterLeaveTemplate". It is used as 4th argument to CreateFrame. As Funky said, if the attribute is nil, the button will simply be non secure. (EDIT: the forum mangled the secureTemplate !! :p)

Anyway I played around with this "crash dummy plugin" today and unfortunately I wasn't that much impressed. I got it to show (after numerous failed attempts with templates overriding each other). Everything seemed fine until I entered combat and ended up with a very nice 500kb action blocked taint log :p Apparently anchoring the plugin to non-secure buttons that can update their properties (eg width) dynamically, even in combat, was a bad idea, then I implemented a check to screw that specific update and got rid of the taint, until I decided to add something else (non-secure) on the display while in combat. Yep, it "exploded" again (not error, just action blocked). Then, there is the issue with potential script handlers being overridden by the display that uses specific handlers for movement or updating or whatnot. Sure you can probably "wrap" your functions around the existing handlers inherited but imo its a bit "hackish".

Quote from HunterZ

Would it be possible to get LDB display addons to implement OnDoubleClick? NRT, a FuBar addon, uses double clicks as a trigger to cause raid attendance to be taken, but when used as an LDB plugin via Fubar2Broker this functionality is lost because both F2B and all displays I've tried (admittedly only ButtonBin and Fortress atm) don't implement OnDoubleClick handlers/events.

They don't because there is no specific attribute (eg obj.OnDoubleClick) in the spec that dictates the specific script handlers can/should be used. This should be fairly easy to implement though.

Quote from Tristanian

They don't because there is no specific attribute (eg obj.OnDoubleClick) in the spec that dictates the specific script handlers can/should be used. This should be fairly easy to implement though.

Yes, easy to implement but hard to track down every display author and convince them to do it (or even to accept/commit patches from me) :\ I guess I can just try getting it added to ButtonBin, since that's the only LDB display that my gf and I are using. I probably won't bother though since I checked in an alpha of F2B that translates LDB middle clicks to FuBarPlugin double clicks.

It's a joined effort imo. If authors start setting their own OnDoubleClick, displays will update.

No, it's more like a catch-22 in that noone uses it, so noone implements it, so noone uses it, ad infinitum :p

If you implement it and users of your plugin and someone else's display like it, they *will* whine that it doesn't work with said display.

Example: right clicking.

Quote from funkydude

Ara like I said in pm I'm not sure how the secure stuff is supposed to mesh with non-secure when it comes to OnEnter. Since the display addon creates the script, then runs the function, I think what you're trying to do is make your own OnEnter, which is in my opinion the wrong way to do it. The display needs to set it.

That's the interesting point (for me at least :p) where we (I) have to try to find an elegant solution that works for other scripts as you want your OnEnter because it's a part of your display feature, and some secure blocks requires the implementation of SecureHandlerEnterLeaveTemplate with attributes "_onenter" and "_onleave" to show/hide the menu properly in combat (and in my crash dummy plugin it serves as an anchor to pass attributes to the menu since there's 2 blocks for dual wielding capable classes :p).

Quote from Tekkub

If you implement it and users of your plugin and someone else's display like it, they *will* whine that it doesn't work with said display.

Quote from Tekkub

You simply cannot expect the display to handle all your fancy stuffs... but you could use those fancy bits to try to win users for your display.

I think people are naturally lazy, and once they feel comfortable with a display, it's really hard to make them change, not to mention they have a tendency to irrationally defend "their" display, unless the author doesnt look active (like Fortress ?) :p

Anyway, it's always good to plan a (not sure of the word) fallback (be it a shortcut to the missing functions or whatever).

Well that's the beauty of it all. FuBar was created because Titan was becoming stale and didn't do things devs wanted. LDB came about because Fu didn't do things people wanted... Now that transition to a new display can be done without rewriting every plugin out there.

Let people be defensive, let other abandon displays that won't implement the things they want. The competition will make things better for everyone.

Quote from Tristanian

Anyway I played around with this "crash dummy plugin" today and unfortunately I wasn't that much impressed. I got it to show (after numerous failed attempts with templates overriding each other). Everything seemed fine until I entered combat and ended up with a very nice 500kb action blocked taint log :p Apparently anchoring the plugin to non-secure buttons that can update their properties (eg width) dynamically, even in combat, was a bad idea, then I implemented a check to screw that specific update and got rid of the taint, until I decided to add something else (non-secure) on the display while in combat. Yep, it "exploded" again (not error, just action blocked). Then, there is the issue with potential script handlers being overridden by the display that uses specific handlers for movement or updating or whatnot. Sure you can probably "wrap" your functions around the existing handlers inherited but imo its a bit "hackish".

I modified ButtonBin to test. Got the plugin to work, but as you said, ButtonBin was tainting like hell. The resize of anchored blocks makes it unpracticable with secure plugins in the way, as in-combat move/resize/hide/show are controlled. Implementing secure stuff would break too many features, so it's not worth it. The same goes for Fortress (and tekBlocks :p).

It looks like it's preferable to design a secure display from the ground to perfectly fit secure plugins, than trying to add the secure feature to an existing display.

So far, it seems SBC is the only *possible* candidate for secure stuff.

Quote from funkydude

I feel it's best if the display addon set's a secure attribute if the plugin is secure. then run OnEnter, and do normal things if it's not.

Do you mean you will code a secure version of your OnEnter script ?

I looked a bit into wrappers (never used them so far) and the ability to set a "pre" and "post" snippets seems good. Display would use the "pre" snippet since it's the one that can override/alterate the default script (if any, and if it's possibly tainting) and the plugin would use the "post" snippet.

Possible problem is post snippets no being executed if there's no associated script to begin with. I will try that tomorrow. (Don't forget secure templates aren't just OnEnter/OnLeave but almost everything else, so that solution may not be for the best.)


A wonderful guide to the new secure system I strongly encourage developers to read in their spare time: http://www.iriel.org/wow/docs/SecureHeadersGuide%20-%20pre1.pdf.