Various fixes #6
Conversation
Project Service expects Milestone Templates to be stored inside "milestoneTemplates" so "milestoneTemplate" has been renamed to be plural.
- Unlike in Project Service endpoints, in this processor we should let create members with any roles because Project Service may create members with any roles implicitly, when accepting invitations. - Also, updated the list of possible user roles, with recently added new roles.
maxceem
changed the title
| PROJECT_MEMBER_ROLE.ACCOUNT_MANAGER, PROJECT_MEMBER_ROLE.COPILOT, PROJECT_MEMBER_ROLE.OBSERVER).required() | ||
| // unlike in Project Service endpoints, in this processor we should let create members with any roles | ||
| // because Project Service may create members with any roles implicitly, when accepting invitations | ||
| role: Joi.string().valid(_.values(PROJECT_MEMBER_ROLE)).required() |
There was a problem hiding this comment.
@maxceem can it create any security loop hole? I mean if some one is able to raise the bus event with data which is not allowed by the project service, then if we don't have checks here, it might get through. However, on second thoughts, I think sending events to bus is not possible without authentication so we should be safe. What do you think?
There was a problem hiding this comment.
In my opinion, this place doesn't bring an additional security loop. If someone happens to be able to send arbitrary messages to the Bus Api or Kafka, he could do much bigger harm than adding a member: removing or updating projects or any other arbitrary data which we store in ES. Also, he can still update or remove members.
We may still think if there is any chance someone could gain access to the Bus Api or Kafka because if so, it gives almost full control over the data we have inside ES.
fix: "Cannot read property 'hits' of undefined" in Project Service
fix: member role validation on create and update