|
09/16/19, 09:04 AM | #1 |
Update 5.2
The next update "Dragonhold" is now available on the PTS.
New API Version: 100029 PTS Dev Guild We have created guilds on the EU and NA server for all addon developers, which get copied over during the PTS cycle for a new update, so we can test guild related things, ask for help with testing or just chat. If you need an invite, ask here or over on our Gitter channel. You are also free to join them on the live servers so you don't always have to be reinvited when the PTS is wiped. Links
I'll edit the OP with more useful information as you post it and add the links as they become available. Last edited by sirinsidiator : 10/21/19 at 03:55 PM. |
|
![]() |
09/22/19, 09:52 AM | #2 |
LibAddonMenu-2.0 currently fails to load properly on PTS, here is a fix provided by Votan:
Change the following in LAM function "CreateAddonSettingsMenuEntry" in file LibAddonMenu-2.0.lua: After this line: ZO_GameMenu_AddSettingPanel(panelData) Add: Code:
KEYBOARD_OPTIONS.controlTable[panelData.id] = {} |
|
![]() |
09/27/19, 02:39 PM | #3 |
This patch also includes a change to the Lua security system. Now when you register a callback for a script handler, event, or update it will run that callback as insecure code even if the code itself is secure. This only impacts registering existing secure closures (not addon created closures), so it should have little impact overall.
|
|
![]() |
10/21/19, 12:24 PM | #4 | |
![]()
Can you provide an example or two of code affected by this change? And a new resolution for these cases? EDIT: Errors without pointing at which addon generated them, as I try to open a container. EDIT2: Chip, is there an official recommendation on how to replace our old code with new code that is "secure" now? Why make this change without informing us further? The following code from one of my addons is now "insecure" and raises the above unuseful error:
Warning: Spoiler
Code:
local function registerHook(inventory) local listView = inventory.listView if listView and listView.dataTypes and listView.dataTypes[1] then local originalCallback = listView.dataTypes[1].setupCallback listView.dataTypes[1].setupCallback = function(rowControl, slot) originalCallback(rowControl, slot) ZO_PreHookHandler(rowControl, "OnMouseEnter", Junkee.OnMouseEnter) ZO_PreHookHandler(rowControl, "OnMouseExit", Junkee.OnMouseExit) end end end EDIT3: I am still curious to hear an official response about this issue! In the meanwhile, if this can help other developers, in my case I hooked into the global events:
Warning: Spoiler
Code:
ZO_PreHook("ZO_InventorySlot_OnMouseEnter", function(control) if control and control.dataEntry and control.dataEntry.data then if control.dataEntry.data.bagId and BAGS_TO_HOOK[control.dataEntry.data.bagId] == true then Junkee.OnMouseEnter(control) end end end) ZO_PreHook("ZO_InventorySlot_OnMouseExit", function(control) if control and control.dataEntry and control.dataEntry.data then if control.dataEntry.data.bagId and BAGS_TO_HOOK[control.dataEntry.data.bagId] == true then Junkee.OnMouseExit(control) end end end) Last edited by Phuein : 10/21/19 at 06:51 PM. |
||
![]() |
09/27/19, 03:39 PM | #5 |
I'm not sure what you mean by "This only impacts registering existing secure closures".
I e.g. got the problem on PTS now that my addon FCOItemSaver cannot use a PreHookHandler like OnMouseDoubleClick (called from another prehookhandler "OnEffectivelyShown" of the inventory) on child controls of the inventory anymore as it says it got unsecure 5 steps before. I'm pretty sure I can solve this by changing my code to use some other preHook (which will takes much work and I'm annoyed to have to do this after some patches again and again, but well...) but WHY is it getting insecure if I do the following? 1. ZO_PreHookHandler(ZO_PlayerInventoryListContents , "OnEffectivelyShown", FCOItemSaver_OnEffectivelyShown) 2. In function "FCOItemSaver_OnEffectivelyShown" for each child control of ZO_PlayerInventoryListContents ZO_PreHookHandler(childrenCtrl, "OnMouseDoubleClick", FCOItemSaver_InventoryItem_OnMouseDoubleClick) 3. And after 2. in the same function "FCOItemSaver_OnEffectivelyShown" for each child control of ZO_PlayerInventoryListContents ZO_PreHookHandler(childrenCtrl, "OnMouseUp", FCOItemSaver_InventoryItem_OnMouseUp) This will throw an insecure error if the step 2 is executed -> As you double click an inventory item! But it will not throw an error if I do just the following? 1. ZO_PreHookHandler(ZO_PlayerInventoryListContents , "OnEffectivelyShown", FCOItemSaver_OnEffectivelyShown) 2. In the function "FCOItemSaver_OnEffectivelyShown" for each child control of ZO_PlayerInventoryListContents ZO_PreHookHandler(childrenCtrl, "OnMouseUp", FCOItemSaver_InventoryItem_OnMouseUp) Why is the PreHookHandler of OnMouseDoubleClick raising an insecure code but OnMouseUp doesn't? Because the function UseItem or whatever is called from the vanilla UI double click is secured? |
|
![]() |
10/03/19, 09:19 AM | #6 | |
The following kind of "Post HooK" code, which is used in some addons which got to do with crafting...
currently makes the PickupInventoryItem code insecure... Code:
EsoUI/Ingame/Inventory/InventorySlot.lua:2630: Attempt to access a private function 'PickupInventoryItem' from insecure code. The callstack became untrusted 3 stack frame(s) from the top. stack traceback: EsoUI/Ingame/Inventory/InventorySlot.lua:2630: in function '(anonymous)' |caaaaaa<Locals> inventorySlot = ud, bag = 6, index = 39 </Locals>|r EsoUI/Ingame/Utility/ZO_SlotUtil.lua:14: in function 'RunHandlers' |caaaaaa<Locals> handlerTable = [table:1]{}, slot = ud, handlers = [table:2]{}, i = 1 </Locals>|r (tail call): ? ZO_StackSplitSource_DragStart:4: in function '(main chunk)' |caaaaaa<Locals> self = ud, button = 1 </Locals>|r if you try to drag any item from the crafting table inventory row: Lua Code:
Same for ZO_Enchanting.OnModeUpdated! Error happens at the craftbag as well then as it seems. Hope we can get another working PostHook so addons lik AdvancedFilters and others can work together without problems. In the past it had to be the posthook and to ZO_Smithing and ZO_Enchanting to make them all work together. Edit Info from sirinsidiator for SMITHING
You can also PreHook EACH panel's SetHidden function of the SMITHING variable (like SMITHING.refinePanel or SMITHING.deconstructionPanel) and execute your code there. Attention: But the SetHidden function is called for EACH panel of the crafting table (e.g. refine, create, deconstruction, improve, research, furniture recipes) EACH time you change ANY of them. So if you change from deconstruction to refine, deconstruction will be SetHidden(true), refine will be SetHidden(false) and ALL others will be SetHidden(true) as well! So be sure to check if the isHidden parameter is false to "apply your code at this panel properly", and check which panel you currently are inside your function code. Enchanting Both way unfortunately do not work for ENCHANTING as it does not own any "panels", just ENCHANTING. If your ENCHANTING PostHook of OnModeUpdateddoes not work anymore you can try this tricky solution provided by Shinni e.g. (untested!) Lua Code:
Or use a Zo_PreHook to ENCHANTING.OnModeUpdated with zo_callLater (about 25ms should be enough) to get the correct enchantingMode again. Last edited by Baertram : 10/03/19 at 11:32 AM. |
||
![]() |
10/20/19, 03:47 PM | #7 |
SecurePostHook -> Call code after original function
On PTS Dragonhold 100029:
The following function was added by ZOs to call your code securely AFTER the original function was executed. Lua Code:
Example: Lua Code:
I've also tested this with some of the inventories ChangeFilter functions but I'll get an error then. -> Reported them to Chip in order to see if we can get this solved or if this happens because of other addons maybe using other hooks on the same functions (see below). What I found out as well: If addons which work in the same "regions" (inventory e.g.) do not use the same methods, but on uses the new SecurePostHook and another one uses ZO_PreHook on the same function, they will have problems at drag&drop of the inventory items -> Insecure errors will appear. Tested with FCOItemSaver and AdvancedFilters e.g. FCOIS used ZO_PreHook and AF SecurePostHook already. After changing FCOIS to the same SecurePostHook the errors were gone. I recommand to change your addons, which have created manual PostHook at ZO_Smithing, ZO_Enchanting etc. SetMode/OnModeUpdate functions to be changed to use SecurePostHook now so all addons will work properly together! Or at least build a test version and see if it fixes stuff. Most errors I found were raised as one dragged an item from the inventory, or crafting inventories. Last edited by Baertram : 10/20/19 at 04:46 PM. |
|
![]() |
10/22/19, 08:41 AM | #8 |
You did some PostHooks here by calling the original function before your new code, but you overwrote the inventory functions during inventory build up as it seems.
OldOrigFunc = OrigFunc OrigFunc = First OldOrigFunc, then your code -> During inventory build up -> code get's tainted. What I understood (thanks to sirinsidiator): All addon code altering inventory stuff until the inventory is fully build (and the secure code was finished) will taint the code and issue these error messages now. Not sure why they changed this and how and what, but afai experienced this happens if you build your own "PostHooks" instead of using ZO_PreHook or the new SecurePostHook function! This also could happen if your addon is changed properly and other addons hook the same functions in any old/other/now insecure way, but tainting the code. There is no/maybe no error message if you use the other addon alone. There is no error message if you use your addon alone. But there will be if you use yours with the new code and the other with the old code together... Last edited by Baertram : 10/22/19 at 08:44 AM. |
|
![]() |
ESOUI » Developer Discussions » Tutorials & Other Helpful Info » Update 5.2 |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
![]() |
![]() |
![]() |
|
|