Skip to content

Fix client-trust issues in item usage, sell shops, and qbx medical sync - #31

Open
Brito1227 wants to merge 7 commits into
ProdigyPRP:mainfrom
Brito1227:main
Open

Fix client-trust issues in item usage, sell shops, and qbx medical sync#31
Brito1227 wants to merge 7 commits into
ProdigyPRP:mainfrom
Brito1227:main

Conversation

@Brito1227

Copy link
Copy Markdown
Contributor
  • Replace client-triggered item usage handling with ox_inventory server-side usingItem post-hooks.
  • Validate sell shop distance server-side before opening stashes and before paying item sales.
  • Correct qbx_medical death state sync so died/revived events match isdead/inlaststand metadata.

@PsychoShock

Copy link
Copy Markdown
Contributor

Hey will try to check later this week, thanks for the contribution :D

Comment on lines 287 to +291
itemsRegistry[itemName] = cb

if itemUseHooks[itemName] then
return
end

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before you do itemsRegistry[itemName] = cb just do if cb then return end no?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that would work, since cb being valid doesn't mean the item is already registered. It would return for every valid callback and nothing would get registered.

I kept the hook check separate so the callback can still be updated without registering another hook.

Comment thread modules/fw/nd_core/server.lua Outdated
local item = bridge.inv.getSlot(src, slot)
if not item then return lib.print.debug("Item not found in slot:", slot) end
local function dispatchRegisteredItemUse(success, payload)
if not success or type(payload) ~= "table" or type(payload.item) ~= "table" then

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there even a reason why payload or payload.item wouldnt be a table? I feel this checks are made in the inventory itself, no? I can confirm later.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you're right. I added those checks as a precaution in case the payload was ever unexpected, but since it comes directly from ox_inventory they should be unnecessary. I'll keep the success check though.

Comment on lines 411 to +415
itemsRegistry[itemName] = cb

if itemUseHooks[itemName] then
return
end

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

@PsychoShock

Copy link
Copy Markdown
Contributor

Can you resolve conflict please?

return
end

local hookId = exports.ox_inventory:registerHook("usingItem", nil, {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You cant hardcode ox inventory. Theres nothing else or internal function? Like exports.qbx_core:CreateUseableItem or QBCore.Functions.CreateUseableItem

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ox_core doesn't provide an equivalent usable-item registration function, and there currently isn't an inventory-level adapter for this in prp-bridge. The qbx_core and QBCore functions are framework-specific, so they aren't available when using ox_core.
Would you prefer me to add a generic bridge.inv.registerItemUse function, implement the usingItem post-hook inside the ox_inventory adapter, and make the ox_core/nd_core modules delegate to the selected inventory?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants