Free tools Windows power users keep installed
One-click scans. No signup required.
A cached “allow” can become a security bug as soon as a document membership is revoked. In Riley Zhu’s Node.js take-home exercise, every request must authenticate the bearer token, check current membership for the requested document, and only then read its contents. A revoke must return 403 on the next request; if the membership service cannot answer, return 503 without reading the file.
What the take-home exercise asks candidates to build
The assignment centers on GET /documents/:id/content. A bearer token identifies the caller, but it does not by itself prove that the caller remains authorized for a particular document. The handler must resolve the token to a user with auth.lookup, ask membership.check(userId, documentId) about current access, and call files.read only after an affirmative membership decision.
As an Amazon Associate I earn from qualifying purchases.
The prompt also sets a strict logging boundary: do not log access tokens, complete Authorization headers, or raw file bytes. The implementation is judged not only on the successful download, but on whether it maintains the authorization invariant under revocation, grants, and membership-service errors. Riley Zhu’s DEV Community assignment is the primary source for the exercise.
Expected responses and side effects
The important contract is the response and whether the handler touched the file store. A denied or indeterminate authorization must never become a file read.
#1 Best Overall
| Request condition | Expected response | File-store effect |
|---|---|---|
| Valid token and current document membership | 200, with the document content |
One read |
| Membership revoked since a prior successful request | 403 |
No additional read |
| Membership granted before this request | 200, with the document content |
One read |
| Unknown bearer token | 401 |
No read |
Membership check throws TimeoutError |
503 |
No read |
Membership check throws UnavailableError |
503 |
No read |
“Next request” is the key timing requirement: neither a previous allow nor a positive-cache TTL may delay the effect of a membership change. If the check times out or the service is unavailable, the handler cannot establish current permission and must fail closed with 503, not fall back to an old allow.
Why a happy-path test is not enough
The public test demonstrates a member’s successful download. It does not revoke membership or take the membership service down, so passing that test alone says little about freshness or outage behavior. The rubric also considers authentication, authorization freshness, side effects, log hygiene, fail-closed handling, and test quality.
Tests should observe both status codes and calls to files.read. In particular, a test that sees 403 but does not assert that no file read occurred can miss a serious ordering error: the handler may have loaded sensitive bytes before deciding to deny access.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Failure patterns the exercise is designed to expose
- Positive TTL caches and response memoization: a previously allowed result or cached response can outlive a revocation.
- Login-time or session grants: treating permission at sign-in as permanent ignores later membership changes.
- Stale-while-revalidate: serving an old allow while checking the source asynchronously violates the next-request contract.
- Fail-open outage handling: allowing access when membership cannot be checked substitutes uncertainty for authorization.
- Weak tests: removing assertions, or sleeping until a cache TTL expires, can make tests pass without proving immediate revoke and grant behavior.
- Credential leakage: logging the bearer token or full authorization header exposes credentials unrelated to the test result.
When can an authorization decision be cached?
For the assignment’s small, deterministic fixture, the direct approach is to check membership on each request. That is the simplest way to make the required state change visible without an additional invalidation mechanism. It is not a claim that every production authorization system must avoid caching.
Rank #3
A cache is defensible only if its freshness and invalidation guarantees preserve the required behavior. A shortcut that stores an allow but has no way to learn about revocation cannot make that stale decision safe. Zhu frames this sharply: “A cache that stores an allow decision without a revocation epoch is not an optimization at all.” That is the author’s characterization of the exercise, not a measured finding or a standards rule.
An adjacent protocol perspective appears in the September 2026 revision -03 of the IETF SAMP Internet-Draft. It describes a trusted decision associated with a particular authenticated operation and a finite validity interval. Where current revocation, approval, delegation, or policy status is required, it calls for configured bounded freshness and a revocation rule; if that required status cannot be established, admission fails closed. This is draft work, not an RFC or settled standards guidance: IETF SAMP draft.
The September 2026 revision -04 of the IETF AADP Internet-Draft offers a related distinction: a token can answer standing identity and scope questions, while a decision for an individual invocation can account for mutable state such as budgets, reservations, approvals, or kill switches. Its guarantees depend on a governed trust boundary and do not cover actions that bypass enforcement or a compromised enforcement point. It, too, is a draft: IETF AADP draft.
What the sample does—and does not—prove
The exercise models membership as an in-process deterministic map. Its generation values are ordinary monotonic integers, not consensus fencing tokens. It does not simulate real identity-provider behavior, replica lag, clock skew, signed tokens, or distribution of revocations across multiple processes. The server also omits TLS, range requests, and an audit-log sink.
Best Value
An optional generation-fingerprint design still calls the membership service on every request, so it does not remove that round trip. The packet’s example therefore supports a direct per-request check for its own fixture, but it cannot establish the performance or correctness of a distributed production design.
Quick Recap
A focused review checklist
- Does the handler reject an unknown token with
401before accessing file contents? - Does it check membership for the specific user and document on each request?
- Does revocation produce
403on the very next request, with no file read? - Does a newly granted membership produce
200on the next request? - Do both membership timeout and unavailability produce
503without a file read? - Do tests assert file-store calls as well as response codes, without waiting for cache expiry?
- Are tokens, full authorization headers, and raw bytes excluded from logs?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
