4 ms·

If only there were a separate error code to specifically indicate an authentication problem that could be returned...

ossreality 12y ago
I'm all in favor of nitpicking some of Docker's awfulness, but returning a 400 for Bad Auth instead of 404 will leak information.
yrro 12y ago
Github don't use the error code because to do so would leak information about the names of private repositories.
- derefr 12y ago
  It would be more correct, then, to signal an authentication error for all nonexistent-and-or-private repos. After all, you aren't authorized to know whether a repo exists by that name or not... whether or not one actually does. (This would also imply that organization owners (and Github CSRs and ops staff) would simply bypass that check, falling through to a check only for existence, where it would be appropriate to return 404. A similar reasoning is behind why you get a 403, not a 404, when you try to get the index of an empty S3 bucket. Sure, it doesn't exist—but you're also not allowed to know that.
  - jacques_chester 12y ago
    Showing 404 to hide the existence of a resource is specifically called out as a suitable use in the RFCs: 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. http://tools.ietf.org/html/rfc7231#section-6.5.4 http://tools.ietf.org/html/rfc7231#section-6.5.4
    - vacri 12y ago
      This being said, 403 is also valid in that same RFC, and makes more sense. "You are not authorised to know the status of this item" is more informative and less misleading than "This item doesn't exist". Everything should be auth-restricted by default (deny-by-default), except for items intentionally made public. In my example above, a 403 gives the correct nature of the fault without revealing any hidden information, whereas a 404 is demonstrably misleading.
      - jacques_chester 12y ago
        A 403 only works in the case that you have an all-or-nothing authentication scheme. A 403 for a resource that exists but is unauthorised leaks the information that the resource exists. Many Github customers don't want people to be able to guess at their private repos, and the 404 is the only code that is legitimately able to express the union of "not here" and "not here because you're not allowed to know it's here".
        vacri 12y ago
        Not at all. If I have a private repo "foo" and a public repo "bar" and no others, given an unauth'd request: > request "foo" => 403 > request "bar" => 200 > request "baz" => 403 > request "qux" => 403 The unauth'd requester can't tell that foo exists and baz and qux do not.
        jsprogrammer 12y ago
        Right, but if someone requests: > request "lkj3fla3kjf1ljf3jf" Which doesn't exist anywhere, it makes no sense to return 403.
        jacques_chester 12y ago
        Now you're breaking 403, which is not meant to signal the non-existence of a resource. That's what 404 is for. The "hiding the existence of resources" purpose has to be carried by something. The RFC says it's carried by 404, and that's that.

I'm all in favor of nitpicking some of Docker's awfulness, but returning a 400 for Bad Auth instead of 404 will leak information.

yrro 12y ago

Github don't use the error code because to do so would leak information about the names of private repositories.

derefr 12y ago
It would be more correct, then, to signal an authentication error for all nonexistent-and-or-private repos. After all, you aren't authorized to know whether a repo exists by that name or not... whether or not one actually does. (This would also imply that organization owners (and Github CSRs and ops staff) would simply bypass that check, falling through to a check only for existence, where it would be appropriate to return 404. A similar reasoning is behind why you get a 403, not a 404, when you try to get the index of an empty S3 bucket. Sure, it doesn't exist—but you're also not allowed to know that.
- jacques_chester 12y ago
  Showing 404 to hide the existence of a resource is specifically called out as a suitable use in the RFCs: 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. http://tools.ietf.org/html/rfc7231#section-6.5.4 http://tools.ietf.org/html/rfc7231#section-6.5.4
  - vacri 12y ago
    This being said, 403 is also valid in that same RFC, and makes more sense. "You are not authorised to know the status of this item" is more informative and less misleading than "This item doesn't exist". Everything should be auth-restricted by default (deny-by-default), except for items intentionally made public. In my example above, a 403 gives the correct nature of the fault without revealing any hidden information, whereas a 404 is demonstrably misleading.
    - jacques_chester 12y ago
      A 403 only works in the case that you have an all-or-nothing authentication scheme. A 403 for a resource that exists but is unauthorised leaks the information that the resource exists. Many Github customers don't want people to be able to guess at their private repos, and the 404 is the only code that is legitimately able to express the union of "not here" and "not here because you're not allowed to know it's here".
      - vacri 12y ago
        Not at all. If I have a private repo "foo" and a public repo "bar" and no others, given an unauth'd request: > request "foo" => 403 > request "bar" => 200 > request "baz" => 403 > request "qux" => 403 The unauth'd requester can't tell that foo exists and baz and qux do not.
        jsprogrammer 12y ago
        Right, but if someone requests: > request "lkj3fla3kjf1ljf3jf" Which doesn't exist anywhere, it makes no sense to return 403.
        jacques_chester 12y ago
        Now you're breaking 403, which is not meant to signal the non-existence of a resource. That's what 404 is for. The "hiding the existence of resources" purpose has to be carried by something. The RFC says it's carried by 404, and that's that.