feathers service permissions/authentication

[iainkirkpatrick]

involves going over the feathers services of Cobuy, and restricting service methods according to what particular agents should / shouldn't be able to do.

services:

• [x] credentials (cobuy additional hooks)
• [x] notifications
• [x] orderIntents
• [x] orderPlans
• [x] orders
• [x] resourceTypes
• [x] priceSpecs
• [ ] products
• [ ] taskPlans
• [ ] taskWorks
• [ ] tokenConsumes
• [ ] tokens

also consider protections for dogstack-agents services:

• [ ] agents
• [ ] credentials
• [ ] profiles
• [ ] relationships

(i.e. to stop all profiles being available to everyone etc)

should write tests for the protections if it's straightforward enough

[iainkirkpatrick]

notifications / mailer service now has basic protection - disallow all methods except for create, and only allow that if it's the server trying to create a mail. That might need to change in the future (i.e. we might want clients to initiate emails?) but for now it's fine with our current needs

[iainkirkpatrick]

got blocked up with trying to get authentication hook tests working for orderIntents - can't for the life of me get a feathers client going that successfully talks to the test server - pulling the plug for now on testing those kinds of hooks, but leaving test.todos in the code

[iainkirkpatrick]

@agentlewis, couple questions:

• any thoughts on who should be able to create an order? i.e. is it just the admin of the group, or can anyone in the group create an order? (i would assume the latter)
• only the admin of the order can update the order? group admin as well? same for deleting an order?

[danalexilewis]

@iainkirkpatrick good question.

Given we are white labeling cobuy and potentially using it in enterprise solutions the ideal is that these permission levels are configurable via a sys admin panel. Mvp could be a deployment config file.

For tapin:

• sysadmins can do anything except invite another sysadmin (defined in deployment config)
• only sysadmins can create groups and invite group admins and members
• group admins can invite group members
• only group admins can create orders
• and ergo a group admin will always be the order admin.
• however as we want many people to provide support we should make it so all group admins can edit/update an order.

For Cobuy:

• sysadmins can do anything except invite another sysadmins (defined in deployment config)
• any member can create a group and becomes the default group admin/owner
• group admins can set whether group members can create orders
• the member that creates an order is the order admin
• group admins and order admins can edit/update an order.

[danalexilewis]

We should only ever do soft deletes as well. Maybe send them a link via email that takes them back to the order and put a restore button on it?

[iainkirkpatrick]

i realise i never replied to your comments @agentlewis - in short i think a config file would be rad, i initially thought it might be a ton of work but simply having a config server-side for it (i.e. your MVP above) actually might not be tooooo bad... it'd possibly look like a bit JSON file that gives certain hooks (predefined names) to services and their methods

[iainkirkpatrick]

orders now has basic coverage after getting blocked a couple times.

[iainkirkpatrick]

added at least the authenticate('jwt') hook to all other relevant services (not tokenConsumes or credentials). this ticket is taking a while, and it feels like there are more pressing tickets right now - https://github.com/root-systems/cobuy/pull/492 is the PR to merge what i've done so far, but I reckon we keep this ticket open in the backlog to finish things off soon.

[iainkirkpatrick]

per gregs request, creating a new ticket for the remaining service coverage to be completed soon :)