mirror of
https://github.com/Unleash/unleash.git
synced 2024-10-18 20:09:08 +02:00
f5fb7b66d1
## What This PR fixes a bug where fetching a feature toggle via the `/api/admin/projects/:projectId/features/:featureName` endpoint doesn't validate that the feature belongs to the provided project. The same thing applies to the archive functionality. This has also been fixed. In doing so, it also adds corresponding tests to check for edge cases, updates the 403 error response we use to provide clearer steps for the user, and adds more error responses to the OpenAPI documentation. ## Why As mentioned in #2337, it's unexpected that the provided project shouldn't matter at all, and after discussions internally, it was also discovered that this was never intended to be the case. ## Discussion points It might be worth rethinking this for Unleash v5. Why does the features API need the projects part at all when features are unique across the entire instance? Would it be worth reverting to a simpler feature API later or would that introduce issues with regards to how different projects can have different active environments and so on? ### Further improvements I have _not_ provided schemas for the error responses for the endpoints at this time. I considered it, but because it would introduce new schema code, more tests, etc, I decided to leave it for later. There's a thorough OpenAPI walkthrough coming up, so I think it makes sense to do it as part of that work instead. I am happy to be challenged on this, however, and will implement it if you think it's better. ### Why 403 when the project is wrong? We could also have used the 404 status code for when the feature exists but doesn't belong to this project, but this would require more (and more complex) code. We also already use 403 for cases like this for post, patch, and put. Finally, the [HTTP spec's section on the 403 status code](https://httpwg.org/specs/rfc9110.html#status.403) says the following (emphasis mine): > The 403 (Forbidden) status code indicates that the server **_understood the request but refuses to fulfill it_**. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (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 credentials. However, **_a request might be forbidden for reasons unrelated to the credentials_**. As such, I think using 403 makes sense in this case. --- Closes #2337. |
||
|---|---|---|
| .. | ||
| __snapshots__ | ||
| addons | ||
| db | ||
| error | ||
| middleware | ||
| openapi | ||
| proxy | ||
| routes | ||
| schema | ||
| services | ||
| types | ||
| util | ||
| app.test.ts | ||
| app.ts | ||
| create-config.test.ts | ||
| create-config.ts | ||
| default-custom-auth-deny-all.ts | ||
| event-hook.test.ts | ||
| event-hook.ts | ||
| logger.test.ts | ||
| logger.ts | ||
| metric-events.ts | ||
| metrics.test.ts | ||
| metrics.ts | ||
| server-impl.test.ts | ||
| server-impl.ts | ||