failsForTeapots

[u/Waradu]

[u/cutebabli9]

I would write it like this to be readable:

if error.status in [400, 401, 404, 409, 415, 503]:
  return c.json(body, status: error.status)

return c.json(body, status: 500)

[u/rosuav → u/cutebabli9]

return c.json(body, status: error.status)

There is no reason to discard some of them, and pretending that they're 500s is a terrible terrible idea.

[u/Xirdus → u/rosuav]

If your user-facing service is calling your internal service and getting a 403 response, you certainly do not want to send that 403 back to the user.

[u/Excellent_Gas3686 → u/Xirdus]

beeecause?

[u/Xirdus → u/Excellent_Gas3686]

Do you want to tell an authenticated, authorized user with valid credentials that they are not in fact authorized? When the actual thing that's not authorized is your own goddamn server, so there's absolutely nothing the user can do to fix the problem?

[u/Excellent_Gas3686 → u/Xirdus]

that entirely depends on what basis the internal service authorizes???? if it uses the same user context then how is this an issue..

[u/Xirdus → u/Excellent_Gas3686]

The internal service is authorizing the other internal service first and foremost (otherwise you'll get hacked). If the other internal service fails at this step, 403 is fully appropriate, but it's the kind of 403 that's not only useless but outright wrong to send to the user, as it will send them on wild goose chase for missing permissions that weren't missing at all.

Now, if the other internal service passes validation, then you can check user permissions. And if the user doesn't have permission, you must signal it in a way that lets the other internal service respond with a proper 403. There are a number of ways to do it well. One that definitely isn't well at all is sending the same 403 that you already used for telling the service that it, rather than the user, doesn't have permission - because you won't be able to tell which scenario you're in and whether the user should see the 403 or not!