9 Matching Annotations
  1. Jan 2022
    1. Next, let’s say that your ticket is correct (so you made through security just fine!) and the gate number in your ticket says “Gate 24” but you walk to Gate 27. The attendant cannot authorize you to go through that gate because it’s not the right gate for your ticket.

      They have these mixed up! (Which is understandable, because 401 is misnamed "Unauthorized but should be named "Unauthenticated")

      Checking if authenticated (which, if it fails the check, should return 401 for authentication error) comes first,

      and then checking if authorized (which, if it fails the check, should return 403 for authorization error)

      See https://hyp.is/wRF7wHopEeynafOqKj81vw/stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses

    2. In other words, an “incorrect ticket” is similar to messing up your credentials: wrong username and/or password and you receive back a 403 Forbidden. Using the correct credentials but trying to access a resource that is not allowed for those credentials returns you a 401 Unauthorized.

      They have these mixed up! (Which is understandable, because 401 is misnamed "Unauthorized but should be named "Unauthenticated")

      Checking if authenticated (which, if it fails the check, should return 401 for authentication error) comes first,

      and then checking if authorized (which, if it fails the check, should return 403 for authorization error)

      See for example https://www.loggly.com/blog/http-status-code-diagram/

    3. You can also think that 403 happens before 401, despite the natural number order: you will not receive a 401 until you resolve a 403.

      They have these mixed up! (Which is understandable, because 401 is misnamed "Unauthorized but should be named "Unauthenticated")

      Checking if authenticated (which, if it fails the check, should return 401 for authentication error) comes first,

      and then checking if authorized (which, if it fails the check, should return 403 for authorization error)

      See for example https://www.loggly.com/blog/http-status-code-diagram/

    4. If the ticket is incorrect or damaged, you cannot even go through the airport security: when they check your ticket, it will be refused. You are Forbidden to enter the boarding area of the airport.

      It depends what we mean by "incorrect"/damaged "credentials ("ticket")...

      A. If they are invalid or incorrect in the sense that we can't authenticate them as anyone (as it sounds like you mean with "incorrect" or "damaged") (they're not a user in our database or the password doesn't match a user in our database), then you should actually use 401, meaning that the client can/should try (again) to authenticate with different credentials.

      B. But if by "incorrect" you mean (as it sounds like you mean with "you cannot even go through the airport security: when they check your ticket, it will be refused") that the credentials were valid enough to authenticate you as someone (a user in our database), but that (known( user has insufficient credentials, then correct, it should be a 403 forbidden.

      It's even easier to explain / think about if you just think of 401 as being used for any missing or failed authentication. See:

  2. Mar 2021
    1. I don't get it. Can someone please explain? I've upgraded my Rails project to Sprockets 4, just to get source maps in production. Instead I got sourcemaps in development?
  3. Jan 2021
  4. Jul 2020
    1. The IAB Transparency and Consent Framework supports both Server-specific consent and Global consent. The former is given by the consumer to a Publisher or Vendor to access their browser and/or perform the requested processing purposes where a Publisher or vendor requires consent for their site

      Consent for the publisher to "access their browser"? Hmm. The Web is a pull-based, client/server, request/response model, not a push model. So it seems odd to me to talk about a publisher needing consent to "access" the user's browser. It is the user's browser (user agent) that made the HTTP request to the publisher's web server. Doesn't the publisher have the right, then, to send a response containing whatever content they wish, since the user requested the content? If the client wishes to filter/block/exclude some of that content, it seems like they have that right, but it seems the responsibility for that is on the client side, not the server side.

      Not that I like ads, but I wonder how much of these new policies are based on a misunderstanding of how web technologies actually work....

      Maybe the distinction is that the publisher of whom you requested content may dynamically load content (ads) from 3rd parties that the user did not specifically request content from? That too is just how the web works, and it is the publisher who controls what other content to load from other domains/sources. But it still may be a worthwhile distinction...?

  5. May 2020
    1. If we already have a shared ssh key to push things up from the server to Gitlab, why do we need to do all this just to get Gitlab to send commands for our server to run?
  6. Mar 2020
    1. Well, the checkbox type has nothing to do with AI, but I’ve read that the type where you have to select “Which picture is …” does collect data to train AIs. It seems dear Dave is confusing between the 2 types.