[backend] Introduce @ff GraphQL directive to restrict access based on feature flag value (#15330)

[fellowseb]

Proposed changes

• Introduces new GraphQL directive to restrict access to endpoint based on Feature Flag values.

Example:

type Query {
  doSomething: String! @ff(flags: ["SOME_FLAG", "SOME_OTHER_FLAG"])
}

This definition will make queries to doSomething throw if neither one of the feature flags is set.

• Adds a softFail option that will resolve to null instead of returning an error:

type Query {
  doSomething: String @ff(flags: ["SOME_FLAG", "SOME_OTHER_FLAG"], softFail: true)
}

This can be helpful for queries happening super early, even before (or while) retrieving the FFs in the frontend.
Is used for the custom views feature as the new customViewsDisplayContext query is used in the RootPrivateQuery that itself fetches the FFs.

• Does a little refactoring of the authDirective
• Due to Dual Package Hazard issues happening when running vitest in the backend I had to add an alias to force using the CJS version.

Related issues

• Fixes Introduce new GraphQL directive to restrict access to endpoint based on Feature Flag #15330

Checklist

• I consider the submitted work as finished
• I tested the code for its functionality
• I wrote test cases for the relevant uses case (coverage and e2e)
• I added/update the relevant documentation (either on github or on notion)
• Where necessary I refactored code to improve the overall quality

Further comments

TODO if/when merged:

• Update docs in Notion
• Update MD files

[codecov]

Codecov Report

❌ Patch coverage is 88.09524% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 33.13%. Comparing base (b7ced05) to head (ba8cbc1).

Files with missing lines	Patch %	Lines
...pencti-graphql/src/graphql/featureFlagDirective.ts	93.75%	2 Missing ⚠️
...ti-platform/opencti-graphql/src/graphql/graphql.js	0.00%	1 Missing ⚠️
...atform/opencti-graphql/src/graphql/loggerPlugin.js	0.00%	1 Missing ⚠️
...orm/opencti-graphql/src/graphql/telemetryPlugin.js	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #15331      +/-   ##
==========================================
+ Coverage   25.84%   33.13%   +7.29%     
==========================================
  Files        3155     3156       +1     
  Lines      214056   214090      +34     
  Branches    35929    39123    +3194     
==========================================
+ Hits        55314    70939   +15625     
+ Misses     158742   143151   -15591     

Flag	Coverage Δ
opencti-client-python	45.59% <ø> (ø)
opencti-front	2.87% <ø> (ø)
opencti-graphql	69.10% <88.09%> (+17.23%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Copilot reviewed 22 out of 23 changed files in this pull request and generated 2 comments.

[lndrtrbn]

I think it would be preferable, for easy review and maintenance, to avoid refactoring stuff not related to a new feature in the same PR but make a dedicated one instead (referring to the authDirective).

Do you think it could be interesting to also add an option that allows to change the "all flags must be present" to "at least one"?

[fellowseb]

Do you think it could be interesting to also add an option that allows to change the "all flags must be present" to "at least one"?

I don't really see the case where you would want all flags to be present TBH 🤔. This can be added later if people have the need.

I think it would be preferable, for easy review and maintenance, to avoid refactoring stuff not related to a new feature in the same PR but make a dedicated one instead (referring to the authDirective).

Removed the refactoring.

[fellowseb]

@SouadHadjiat you mentioned using UnsupportedError instead of ForbiddenAccess : I still think ForbiddenAccess makes more sense given it's a client error (403) whereas UnsupportedError is a server error. UnsupportedError is used for cases where the server doesn't support cases either because of domain logic ('Can apply avg on non numeric attribute') or other reasons independant from the user.