What you are testing
A and B are two fictional customers. Authentication identifies which customer you are acting as. Authorization decides which records that customer may read or change. A successful login must not let A access B's records.
1. Set up this lesson's data
Click Create workspace. This lesson has its own seeded A and B records. Use the tokens and IDs from this workspace; do not reuse them from the earlier create/read lesson. Wait for Workspace ready.
2. Follow the request guide
The guide shows one request at a time. Click Prepare this request to fill its method, URL, headers and body; inspect those fields and click Send request yourself. Use Next request step after inspecting the response.
- Log in as B with the prepared
b / practice-blogin. Expect 200. Copytokenand paste it into B's login token on the next step. - Find B's ID: read the customer list as B. Find the record with
owner: band copy itsid. The list is only used to find the ID. - Read B's specific record: paste B's ID, prepare and send its GET as B. Expect 200. Click Use this response to keep the before-state evidence.
- Switch to A: send the prepared
a / practice-alogin. Copy A's new token. Keep it separate from B's token. - Find A's ID: read the list with A's token. Copy the ID of the record with
owner: a. Keep B's ID unchanged. - Read A's specific record: send its GET as A. Expect 200 and
owner: a. Keep this response as A's own-record evidence. This confirms A's token works. - Try reading B's record as A: use A's token but B's exact ID. Expect 404. Keep this denied-read response.
- Try changing B's record as A: use the same token and B ID with PATCH and a valid name-only body such as
{"name":"Unexpected change"}. Expect 404 again. Keep this denied-write response. - Read B again as B: switch back to B's token and read the same B ID. Expect 200. Compare the record with the selected before-state response in step 3. Its name and other fields must be unchanged.
Why 404 can be the expected result
This API deliberately hides records owned by another customer. For A trying to access B's real record, 404 is the documented access denial. A random nonexistent ID would not prove ownership protection. A 401 means your practice token is missing, expired or invalid; it is not the expected result here.
3. Select four test requests and submit
You need four selected responses: B reads B's specific record before testing (200), A reads A's own specific record (200), A cannot read B's record (404), and A cannot change B's record (404). The login and list requests are preparation. The final B read is for your comparison; the grader also checks that B's stored fields still match the before-state.
Use the response buttons to select evidence, or choose recorded requests in step 3. Expand Inspect selected evidence to review the bodies. Enter the denied-read status and choose why it was denied. Click Submit Answers. A saved 100/100 with green checks means this assignment is complete. When every check passes, use Continue. It opens the next lesson you can submit.
If you need to retry
For 401, return to the matching login step and paste its fresh token. If A can read B's record with 200, check that you really used A's token and B's ID; do not count it as a passing denial. Keep the before-state and use the same B ID for both denied requests. Do not reset or change B's record before checking. Reset clears data and invalidates tokens. Reload clears the guide's working tokens and IDs, while saved evidence remains inspectable.
Optional self-review
Why test both read and write permissions? Why compare B's data after a denied write? What is the difference between 401 and this API's concealed-resource 404? No written self-review is required to finish.