fix: check permissions for order workflow methods

[aldeed]

Impact: minor
Type: bugfix

Issue

Permissions were not checked by three Meteor methods, such that anybody with enough information could set an order or order item status to anything.

Solution

• Check for "orders" permission for the order shop in "workflow/pushOrderWorkflow" and "workflow/pushItemWorkflow" Meteor methods
• Removed the "workflow/pullOrderWorkflow" Meteor method because it isn't used

Breaking changes

A custom plugin that is calling the "workflow/pullOrderWorkflow" Meteor method will break

Testing

Verify that you get access denied when calling "workflow/pushOrderWorkflow" method in an incognito tab, or in a tab where you are logged in as a customer. Example to run in the browser console, replacing with IDs that exist in your DB:

Meteor.call("workflow/pushOrderWorkflow", "coreOrderWorkflow", "processing", { _id: "aHEm8LriEFSnmndbx", shopId: "J8Bhq3uTtdgwZx3rz" }, console.log.bind(console));

Verify that you get access denied when calling "workflow/pushItemWorkflow" method in an incognito tab, or in a tab where you are logged in as a customer. Example to run in the browser console, replacing with IDs that exist in your DB:

Meteor.call("workflow/pushItemWorkflow", "coreOrderItemWorkflow/picked", { _id: "aHEm8LriEFSnmndbx", shopId: "J8Bhq3uTtdgwZx3rz" }, ["27gYhd4rMCX37jGzH"], console.log.bind(console));

[impactmass]

I had this on my TODO for today, but I could not get to it. I'll review tomorrow

[impactmass]

LGTM while testing. Access denied errors thrown as appropriate.

One question: I noticed this workflow/pushCartWorkflow in the workflow.js file. Do we need to have a hasPermission check there too?

[aldeed]

@impactmass Good question about cart workflow methods. The security audit did identify pushCartWorkflow and revertCartWorkflow as insecure, but they are used only by the classic UI checkout, which we are removing soon. So the fix will be to remove those methods when the corresponding UI is removed.

[impactmass]

@aldeed 👍