Restricting Access
Get started with writing the tests for user code, making design decisions, and the tests pass.
Having the required login for our application, we’ve solved part of the potential security problem. The next problem involves limiting a user’s access to projects the user is associated with.
Getting started with test
Let’s start with an integration test. The test needs as its “given” a project and at least two users: one who has access and one who does not. The “when” action is an attempt to view the project show page, and the “then” specification is the successful or unsuccessful page view. We might test a couple of other security aspects, such as whether the index list of projects is filtered by what projects the user is part of, whether a user can edit or create a project, and so on. But this set of tests will give the basic idea:
rsync -avr --progress /usercode/* /usr/local/educative/gatherer --exclude course-content --exclude execute1.sh --exclude execute.sh --exclude __ed_script.sh --exclude __ed_stderr.txt --exclude __ed_stdout.txt cd /usr/local/educative/gatherer bundle exec rspec
The tests both create a project, log in as a user, and visit the project page. In the first test, we also add the user to the project. In the second test, we assert that the user goes anywhere but the actual project page. Both tests fail at the moment.
Design decisions
In writing these tests, we have a new concept to represent in the code: the combination of a user and a project. This requires us to make a design decision. As we write the test, we’re making a claim ...