THINK FIRST·CODE LATER

← All labs

Complete mediation: the access-control check

Problem

Implement StudyBuddy's server-side authorization and check a batch of API requests — every request is checked (complete mediation), and anything not explicitly allowed is denied (fail-safe default).

Input:

USERS
<lines: userId role course1,course2,...>        role: STUDENT, TA, INSTRUCTOR, ADMIN
POSTS
<lines: postId authorId course hidden(Y/N)>
REQUESTS
<lines: userId ACTION postId>                    ACTION: VIEW, EDIT, HIDE, DELETE

Rules (a TA/INSTRUCTOR is "staff" only for courses in their own list):

  • ADMIN → allow everything.
  • VIEW → allow if the user is the author, or staff of the post's course, or (a member of the course and the post is not hidden).
  • EDIT → allow only the author, and only if the post is not hidden.
  • HIDE → allow staff of the post's course.
  • DELETE → allow the author, or staff of the post's course.
  • Unknown user, unknown post or unknown action → deny.

Output per request: userId ACTION postId -> ALLOW or -> DENY (reason) where reason is one of unknown user, unknown post, unknown action, not permitted. Finally Allowed: a, Denied: d.

Input:

USERS
u1 STUDENT CPS4301
u2 STUDENT CPS4301
t1 TA CPS4301
t2 TA CPS3962
POSTS
p1 u1 CPS4301 N
p2 u1 CPS4301 Y
REQUESTS
u2 VIEW p1
u2 VIEW p2
u1 VIEW p2
u2 EDIT p1
t1 HIDE p1
t2 HIDE p1
u9 VIEW p1

Output:

u2 VIEW p1 -> ALLOW
u2 VIEW p2 -> DENY (not permitted)
u1 VIEW p2 -> ALLOW
u2 EDIT p1 -> DENY (not permitted)
t1 HIDE p1 -> ALLOW
t2 HIDE p1 -> DENY (not permitted)
u9 VIEW p1 -> DENY (unknown user)
Allowed: 3, Denied: 4

Write it here or in your IDE, then paste it. Compile and test it yourself before comparing. Your code stays in your browser — it is never sent to or stored on the server.