Hey all,
As a member of an organization, many of the pipelines and builds you can see may not be accessible to you. For instance, opening a link to a particular build that’s been shared with you, where the pipeline for the build is restricted to teams that you aren’t a member of.
In these cases, a 404 page is loaded. This isn’t incorrect, but I do feel that a user on the inside of an organization should see a 403 instead. The use-case for using 404 when 403 is also technically correct is described in RFC 7231 as whenever a server is unwilling to disclose that the requested resource exists. This makes sense to me regarding the general public-- you want not to expose any information about a private repo to the world. However, I feel that if you’re a member of a given team’s parent organization, I think it makes sense to provide a level of trust where you’re willing to at least disclose that the resource exists.
In particular, I am motivated to ask for this because new users of our Buildkite system are asking our support teams why these 404 links are broken instead of asking for access from the teams that own these resources, and I think the more trusting status would help resolve some of that confusion.
I realize that the way I’ve phrased this makes it sound like an either/or proposition, but in reality I think it would be just as useful for the organization’s administrators to be able to toggle this as a behavior. There’s probably no need to deny them that level of configuration!
Update
For ease of reference, the corresponding entries for 404 and 403, from RFC 7231:
6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different redentials. However, a request might be forbidden for reasons unrelated to the credentials.
An origin server that wishes to “hide” the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.
A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).