Filter instance list and APIs by user's organization [OC-5076]
Add filter on API to only show instances owned by the organization the user belongs to.
Testing:
First test:
- Create a new organization ("test")
- Create a user that belongs to that organization ("test_user")
- Create an instance were the owner is the organization you just created
- Check the list of instances, make sure that the instance you created is showed when you are logged in with that user
Second test:
- Create a new organization that has is_admin = True ("test_admin")
- Create a new user that belongs to that organization ("test_user_admin")
- Login with that user
- Check that /instances lists all the instances that are defined on the application, even if they don't belong to this organization
Third test:
- Update is_admin value on "test_admin" organization to False
- Check that the list of instances doesn't include the first instance you created that belongs to the organization "test"
Reviewers:
2nd part
The 2nd part of the PR, from @Clemente and with @rocioar reviewing, finishes this feature and adds the filter to other places. Not moving this to another PR, since it's the same feature and we won't need 2 branches.
My changes add:
- fix some typos from previous commits
- introduces new permission system:
- There's a new explicit permission
manage_own
which means you're an instance manager and can see your own instances -
manage_all
is deleted, and the way to check who's an all-powerful admin is to checkUser.is_superuser
- Tests have been rewritten to take that into account, and to check both su and non-su instance managers
- Tests answer with 403 when you don't have the
manage_own
permission and try to manage instances
- There's a new explicit permission
- the creator (user) and the organization are shown in the Ocim UI
- the OpenStackServer API is now disabled for non-superusers, because it's not used in the UI, and in particular it's not used by sandbox or trial users. I avoided adding an unneeded complex filter and tests („a non-admin instance manager can only see OpenStack VMs belonging to appservers belonging to instances belonging to the user's organization“).
- it fixes a bug in the code, that makes it fail (error 500) on our stage and production servers when you open
/api/v1/pr_watch/
, because we have some watched pull requests without an associated instanceFile "/var/www/opencraft/pr_watch/serializers.py", line 52, in to_representation output['instance_id'] = obj.instance.ref.id # The API must only expose InstanceReference IDs, not Instance ID AttributeError: 'NoneType' object has no attribute 'ref'
- the pr_watch API is now available to instance managers only
- the pr_watch API is now filtered so that an instance manager can only see PRs from their organization. Superusers can still see all PRs
- added new tests:
- check that a non-su instance manager can't see instances from another organization
- same, but for appservers belonging to an instance which belongs to another organization
- pr_watch available for instance managers only
- pr_watch shows only PRs related to your organization
- make sure that anonymous/staff can't click the blue button to spawn server
- check that a user can't spawn servers for another organization
- check that unauthorized users can't activate/deactivate servers
- check that a user can't activate/deactivate servers for another organization
- a basic user can't see instance logs
- a basic user can't see appserver logs
- a user can't see instance logs from another organization
- a user can't see appserver logs of instances from another organization
- the instance list in the API can't be seen by anonymous or basic user
- many new tests for the case when a user doesn't have an organization: he should see no PRs, no instances, no servers, no server logs, no instance logs, no active/inactive button, etc.
Testing instructions
- test some or all of features promised above
- test that if a sandbox user is given access to
/api/
, they won't be able to view information that doesn't belong to them, and they won't be able to change information that doesn't belong to them - test that the creator/owner appears in the UI
- test the redirection from / to the right place in many cases: super-users and manage_own go to the instance list, the rest go to the registration page
- read the tests, check that all the needed ones are there, or try the same scenarios in the browser: e.g. create appservers belonging to instances from different organizations and check the they're filtered (except to superuser)
- test that a WatchedPullRequest without an instance is displayed in the pr_watch API with
null
as instance_id, instead of crashing. Or trust the fix - check that all APIs are filtered by organization
- check that all APIs to manage instances deny access to users without manage_own (e.g. to a beta test user)
- a user wiht manage_own but without an organization should not be able to do much (see instances, spawn servers, activate/deactive, …)
- try to hack into the system, e.g. by taking some AJAX APIs and changing some numbers