Create Organization Security Bug

[kb-0311]

Describe the bug
A clear and concise description of what the bug is.

In the talawa-admin portal the users needs to be a verified SUPERADMIN to get access to the portal logically. In the Dashboard of talawa-admin Portal , there is a create organization function.

In short a user needs to be a super admin to create an organization according to the logic. However, in the backend no check is provided for the user role before creating an organization , thus enabling any one (USER, ADMIN , SUPERADMIN etc )to create an
organization.

This is a security bug.

This is security by obfuscation where capabilities are not presented to the user, but are still available.

To Reproduce
Steps to reproduce the behavior:

1. Sign up as a user in graphql playground
2. get the access token
3. Create and organization through its mutation
4. An org is created

Expected behavior
A clear and concise description of what you expected to happen.
Only super admins should be allowed to create new organizations.
Actual behavior
A clear and concise description of how the code performed w.r.t expectations.
Right now anyone can technically create new organizations.
Screenshots
If applicable, add screenshots to help explain your problem.

Additional details
Add any other context or screenshots about the feature request here.

Potential internship candidates
Please read this if you are planning to apply for a Palisadoes Foundation internship PalisadoesFoundation/talawa#359
//SIgn up as a brand new default user

//Logged in as that user

// Created a brand new organization as userType:USER

[kb-0311]

pls assign this to me

[anshgoyalevil]

@kb-0311 You may resolve this issue using the roleDirective

Just apply the role directive on the createOrganization mutation like so

type Query {
    hello: String @role(requires: "SUPERADMIN")
}

[kb-0311]

@anshgoyalevil Yes but that will not be enough from a modular development perspective imo.

1. The roleDirective will eventually be implemented for every query/Mutation that requires it. But as you can see in all typeDefs the role directive is not implemented for any directive that requires it. So while I am fixing security flaws I need to make sure to implement them one by one to not cause breaking change.
2. There needs to be a thorough approach to how I am fixing security-related bugs consistent with the codebase so that other developers can easily debug and write tests in the future. That is why it is important to add a layer of check in the resolver itself as it has been done for all resolvers till now.

Along with roleDirectives in gql I will also be adding an extra utility superAdminCheck.ts within /utilities just like adminCheck.ts and creatorCheck.ts which currently exists, to add a more modular approach and make this function logically reusable whenever needed.

Also speaking of the roleDirectives, there is a slight mistake with the thrown error->

the error should be 'user.notAuthorised'. 'user.notAuthenticated' is an error thrown by auth directive(which could get very confusing to differentiate the cause of error while manually testing and debugging the app) so will be fixing that too in this same PR. and add this as a constant.

[xoldd]

@kb-0311 You're changing the errors thrown by the server. If the clients check the error for different types to trigger a particular UI behaviour you'll be breaking their functionality. Make sure to remember this.

[kb-0311]

@xoldyckk Yes, I will make sure to change the talawa-admin app and talawa-mobile app accordingly.

[kb-0311]

@xoldyckk could you pls remove the unapproved label too ?