Recap and Feedback
We followed sign-in from password verification to a session, then used the resolved account to decide which changes were permitted. In the notes and marketplace workflows, identity, request protection and resource permissions worked together: a valid session alone did not authorize an edit.
Meaningful tests reached the rule they intended to check. An ownership test used a valid session, origin and CSRF token, then compared stored state before and after a denied edit. A permitted request checked that the operation could also succeed.
Data crossed other boundaries too. Public-output schemas restricted exposed fields, while SQL parameters and text rendering kept values from becoming executable syntax. Typed clients helped callers construct requests; server validation protected the operation regardless of the caller.
For your own notes, choose one operation. Explain how the caller is identified and which permission rule applies, then describe how you would check both acceptance and unchanged state after rejection.
Use the feedback form below to describe what helped your learning and what needs clarification.
Reflection and feedback
0 / 5 points
Consider the following statements and answer them based on your experiences from studying the materials and working on the assignments in this part. When answering the numeric statements, answer them so that value 1 means that you strongly disagree with the statement, and value 7 means that you strongly agree with the statement. Please be as honest as possible when answering. The feedback will be used to improve the course.
Part 6 follows these interactions into layout, keyboard access and recovery feedback. As we improve the interface, the server continues to enforce the same request and permission rules.