Enhancement Proposal: Authentication Filter #4235

shaun-nx · 2025-11-06T18:19:55Z

Proposed changes

Status set to Implementable after merging #4136

This document proposes a solution for enabling Authentication use cases through NGINX Gateway Fabric.

Closes #4052

Checklist

Before creating a PR, run through this checklist and mark each as complete.

I have read the CONTRIBUTING doc
I have added tests that prove my fix is effective or that my feature works
I have checked that all unit tests pass after adding my changes
I have updated necessary documentation
I have rebased my branch onto main
I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.

NONE

codecov · 2025-11-06T18:22:38Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.11%. Comparing base (d9846a4) to head (bf3ed2b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4235      +/-   ##
==========================================
+ Coverage   86.08%   86.11%   +0.03%     
==========================================
  Files         132      132              
  Lines       14342    14342              
  Branches       35       35              
==========================================
+ Hits        12346    12351       +5     
+ Misses       1791     1789       -2     
+ Partials      205      202       -3

☔ 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.

docs/proposals/authentication-filter.md

salonichf5 · 2025-11-06T18:52:47Z

docs/proposals/authentication-filter.md

+const (
+	AuthTypeBasic AuthType = "Basic"
+	AuthTypeJWT   AuthType = "JWT"
+)


we should specify the nginx modules these constants associate with

Do you mean we should add a comment or rename the constants to reflect the module?

No the nginx module should be added as reference in the comment

// NGINX module: https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html

salonichf5 · 2025-11-06T18:55:37Z

docs/proposals/authentication-filter.md

+// BasicAuth configures HTTP Basic Authentication.
+type BasicAuth struct {
+	// Secret is the name of the Secret containing htpasswd data.
+	// The Secret must be in the same namespace as this filter.


why does it have to be in the same namespace? we can always resolve the secret in different namespace, unless there is another limitation assumed?

Can we follow the ReferenceGrant pattern for accessing Secrets in another namespace?

This comment was mostly to reflect security constraints. I noticed I didn't make note of it elsewhere in the proposal though. Mainly, we want to make sure that the AuthenticaitonFilter can only reference secrets in the same namespace by default, and like @sjberman said we can support integration with ReferenceGrant to support cross-namespace where needed.

I'll add a section to the proposal to cover that.

@sjberman @salonichf5 The Security Considerations section should be updated now to talk about namespace isolation as well as cross-namespace support with ReferenceGrant

Can we remove or amend this comment to reflect this?

The spec should use the Gateway API's ObjectReference type instead of two separate Secret and SecretRef fields.

@ciarams87 I'll amend the comment around this.

@sjberman good catch. The BasicAuth spec should just have a secretRef field so that it can work with reference grants.

I think he meant using the secretRef type as SecretObjectReference

docs/proposals/authentication-filter.md

salonichf5 · 2025-11-06T20:13:45Z

docs/proposals/authentication-filter.md

+	// Default: File.
+	//
+	// +optional
+	// +kubebuilder:validation:Enum=File;Remote


same comment as below for specifying defaults and enum

As I think about it, it might not make sense for something like this to have a default. Users should probably be very explicit about which mode they want to set. What do you think?

salonichf5 · 2025-11-06T20:14:35Z

docs/proposals/authentication-filter.md

+	Path string `json:"path"`
+
+	// Levels specifies the directory hierarchy for cached files.
+	// Example: "1:2".


like 1: is for most frequently used?

This specifies the directory depth of the cache file. In the case where you have a proxy_cache_path configuration like this:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;

The file names in a cache will look like this: /data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c

From the docs:

The levels parameter defines hierarchy levels of a cache: from 1 to 3, each level accepts values 1 or 2.

salonichf5 · 2025-11-06T20:15:09Z

docs/proposals/authentication-filter.md

+type JWTTokenSource struct {
+	// Read token from Authorization header. Default: true.
+	//
+	// +optional


set defaults using kubebuilder: default

If this is an optional field though, it shouldn't have a default.

docs/proposals/authentication-filter.md

salonichf5 · 2025-11-06T20:24:29Z

docs/proposals/authentication-filter.md

+### Auth failure behaviour
+
+3xx response codes should not be allowed and AuthenticationFilter.onFailure must not support redirect targets. This is to prevent to prevent open-redirect abuse.
+
+401 and 403 should be the only allowable auth failure codes.
+


did not see this as a rule at API level, we will allow this at API spec level?

We could likely add it at a CEL validation level. What are your thoughts? I've typically seen these kind of things handled by controller level validation, but it feels like CEL validation would be better if we want to reject the resource.

yeah I think we can have CEL validation to allow 401 and 403 to simplify things in the later step

ciarams87

These are mostly focussed on typos I spotted while doing a first pass, I haven't fully absorbed the content yet

ciarams87 · 2025-11-07T14:20:22Z

docs/proposals/authentication-filter.md

+
+## Introduction
+
+This document focuses expliclty on Authentication (AuthN) and not Authorization (AuthZ). Authentication (AuthN) defines the verification of identiy. It asks the question, "Who are you?". This is different from Authorization (AuthZ), which preceeds Authentication. It asks the question, "What are you allowed to do".


Suggested change

This document focuses expliclty on Authentication (AuthN) and not Authorization (AuthZ). Authentication (AuthN) defines the verification of identiy. It asks the question, "Who are you?". This is different from Authorization (AuthZ), which preceeds Authentication. It asks the question, "What are you allowed to do".

This document focuses explicitly on Authentication (AuthN) and not Authorization (AuthZ). Authentication (AuthN) defines the verification of identity. It asks the question, "Who are you?". This is different from Authorization (AuthZ), which preceeds Authentication. It asks the question, "What are you allowed to do".

ciarams87 · 2025-11-07T14:22:01Z

docs/proposals/authentication-filter.md

+## Use Cases
+
+- As an Application Developer, I want to secure access to my APIs and Backend Applications.
+- As an Application Developer, I want to enforce authenticaiton on specific routes and matches.


Suggested change

- As an Application Developer, I want to enforce authenticaiton on specific routes and matches.

- As an Application Developer, I want to enforce authentication on specific routes and matches.

ciarams87 · 2025-11-07T14:22:24Z

docs/proposals/authentication-filter.md

+## API, Customer Driven Interfaces, and User Experience
+
+This portion of the proposal will cover API design and interaction experience for use of Basic Auth and JWT.
+This portioan also contains:


Suggested change

This portioan also contains:

This portion also contains:

ciarams87 · 2025-11-07T14:22:51Z

docs/proposals/authentication-filter.md

+
+1. The Golang API
+2. Example spec for Basic Auth
+    - Example HTTPRoutes and NINGX configuration


Suggested change

- Example HTTPRoutes and NINGX configuration

- Example HTTPRoutes and NGINX configuration

ciarams87 · 2025-11-07T14:23:17Z

docs/proposals/authentication-filter.md

+3. Example spec for JWT Auth
+    - Example HTTPRoutes
+    - Examples for Local & Remote JWKS configration
+    - Example NINGX configuration for both Local & Remote JWKS


Suggested change

- Example NINGX configuration for both Local & Remote JWKS

- Example NGINX configuration for both Local & Remote JWKS

ciarams87 · 2025-11-07T14:36:34Z

docs/proposals/authentication-filter.md

+
+### Key rotation
+
+Users sholud be advised to regularly rotate their JWKS keys in cases where they chose to reference a local JWKS via a `secrefRef` or `configMapRef`


Suggested change

Users sholud be advised to regularly rotate their JWKS keys in cases where they chose to reference a local JWKS via a `secrefRef` or `configMapRef`

Users should be advised to regularly rotate their JWKS keys in cases where they chose to reference a local JWKS via a `secrefRef` or `configMapRef`

ciarams87 · 2025-11-07T14:37:09Z

docs/proposals/authentication-filter.md

+### Auth failure default headers
+
+Below are a list of default defensive headers for authentication failure reponses.
+We may choose to include these headers by default for improved robustness in auth falure responses.


Suggested change

We may choose to include these headers by default for improved robustness in auth falure responses.

We may choose to include these headers by default for improved robustness in auth failure responses.

ciarams87 · 2025-11-07T14:39:15Z

docs/proposals/authentication-filter.md

+add_header Content-Type "text/plain; charset=utf-8" always;
+add_header X-Content-Type-Options "nosniff" always;
+add_header Cache-Control "no-store" always;
+add_header Pragma "no-cache" always;


I had to look this up, I had never seen it before. It's been superseded by Cache-Control, I don't think we would need it, it's legacy from HTTP/1.0

ciarams87 · 2025-11-07T14:41:54Z

docs/proposals/authentication-filter.md

+This allows users to reference an external authentication services, such as Keycloak, to handle the authentication requests.
+While this API is available in the experimental channel, it is subject to change.
+
+Our decision to go forward with our own `AuthenticationFilter` was to ensure we could quckly provide authenticaiton to our users while allowing us to closley monitor progress of the ExternalAuthFilter.


Suggested change

Our decision to go forward with our own `AuthenticationFilter` was to ensure we could quckly provide authenticaiton to our users while allowing us to closley monitor progress of the ExternalAuthFilter.

Our decision to go forward with our own `AuthenticationFilter` was to ensure we could quickly provide authentication to our users while allowing us to closely monitor progress of the ExternalAuthFilter.

To be clear, this proposed AuthenticationFilter is to supply different auth methods than provided in the ExternalAuth filter, and is technically unrelated.

@sjberman that's not entirely true. If we went forward with ExternalAuth filter, we could build out an external auth service that uses NGINX. It wouldn't prevent us from supplying those auth methods.

But that is unrelated to this AuthenticationFilter. This filter is to configure our NGINX data plane to perform native auth, without the need for an external entity. The ExternalAuthFilter is for just using an external entity for auth, whatever that entity may be (it wouldn't be our direct NGINX data plane, but it could be an external NGINX instance).

These are two different solutions for implementing auth for the user, and are not technically related to each other. I only mention this because this sentence in the doc implies that this Filter is being implemented as a workaround to the ExternalAuth filter, but it's really not, it's a different auth solution. Just being pedantic.

ciarams87 · 2025-11-07T14:42:23Z

docs/proposals/authentication-filter.md

+
+### Documenting filter behavour
+
+In regards to documentation of filter behavour with the `AuthenticationFilter`, the Gateway API documentation on filters states the following:


Suggested change

In regards to documentation of filter behavour with the `AuthenticationFilter`, the Gateway API documentation on filters states the following:

In regards to documentation of filter behaviour with the `AuthenticationFilter`, the Gateway API documentation on filters states the following:

sjberman

I'll do a more thorough review once I'm back online full time.

sjberman · 2025-11-07T15:14:03Z

docs/proposals/authentication-filter.md

+// BasicAuth configures HTTP Basic Authentication.
+type BasicAuth struct {
+	// Secret is the name of the Secret containing htpasswd data.
+	// The Secret must be in the same namespace as this filter.


The spec should use the Gateway API's ObjectReference type instead of two separate Secret and SecretRef fields.

sjberman · 2025-11-07T15:17:49Z

docs/proposals/authentication-filter.md

+    //
+    // +optional
+    // +kubebuilder:default=401
+    // +kubebuilder:validation:XValidation:message="statusCode must be 401 or 403",rule="self == null || self in [401, 403]"


Can you use an Enum on an integer instead of CEL? I haven't tried this, maybe it only works for strings.

Not sure. I'll see if it's possible though.

i think you should be able to since they resolve as strings?

sjberman · 2025-11-07T15:20:04Z

docs/proposals/authentication-filter.md

+	// Example: "auth_jwt_key_cache 10m;".
+	//
+	// +optional
+	KeyCache *string `json:"keyCache,omitempty"`


This can use the Duration type that we have defined.

Sounds good. Out of curiosity, why do we have our own Duration type?

It allows us to perform validation on the format of it.

sjberman · 2025-11-07T15:20:19Z

docs/proposals/authentication-filter.md

+	// Example: "auth_jwt_key_cache 10m".
+	//
+	// +optional
+	KeyCache *string `json:"keyCache,omitempty"`


This can use the Duration type that we have defined.

docs/proposals/authentication-filter.md

sjberman · 2025-11-07T15:22:36Z

docs/proposals/authentication-filter.md

+
+### Attachment
+
+Filters must be attached to a HTTPRoute at the `rules.matces` level.


Suggested change

Filters must be attached to a HTTPRoute at the `rules.matces` level.

Filters must be attached to a HTTPRoute at the `rules.matches` level.

sjberman · 2025-11-07T15:24:45Z

docs/proposals/authentication-filter.md

+Detailed header breakdown:
+
+- Content-Type: "text/plain; charset=utf-8"
+  - This header explicitly set the body as plan text. This prevents browsers from treating the response as HTML or JavaScript, and is effective at mitigating Cross-side scrpting (XSS) through error pages


Suggested change

- This header explicitly set the body as plan text. This prevents browsers from treating the response as HTML or JavaScript, and is effective at mitigating Cross-side scrpting (XSS) through error pages

- This header explicitly set the body as plain text. This prevents browsers from treating the response as HTML or JavaScript, and is effective at mitigating Cross-side scrpting (XSS) through error pages

sjberman · 2025-11-07T15:25:08Z

docs/proposals/authentication-filter.md

+
+### Validation
+
+When referencing an `AuthenticationFilter` in either a HTTPRoute or GRPCRoute, it is important that we ensure all configurable fields are validated, and that the resulting NGINX configuration is correct and secure


Suggested change

When referencing an `AuthenticationFilter` in either a HTTPRoute or GRPCRoute, it is important that we ensure all configurable fields are validated, and that the resulting NGINX configuration is correct and secure

When referencing an `AuthenticationFilter` in either a HTTPRoute or GRPCRoute, it is important that we ensure all configurable fields are validated, and that the resulting NGINX configuration is correct and secure.

sjberman · 2025-11-07T15:25:28Z

docs/proposals/authentication-filter.md

+
+We should validated that only one `AuthenticationFilter` is referenced per-rule. Multiple references to an `AuthenticationFilter` in a single rule should result in an `Invalid` HTTPRoute/GRPCRoute, and the resource should be `Rejected`.
+
+an `AuthenticationFilter` that sets a `onFailure.statusCode` to anything other than `401` or `403` should be rejected. This relates to the "Auth failure behaviour" section in the Security Condierations section.


Suggested change

an `AuthenticationFilter` that sets a `onFailure.statusCode` to anything other than `401` or `403` should be rejected. This relates to the "Auth failure behaviour" section in the Security Condierations section.

An `AuthenticationFilter` that sets a `onFailure.statusCode` to anything other than `401` or `403` should be rejected. This relates to the "Auth failure behaviour" section in the Security Considerations section.

sjberman · 2025-11-07T15:26:34Z

docs/proposals/authentication-filter.md

+This allows users to reference an external authentication services, such as Keycloak, to handle the authentication requests.
+While this API is available in the experimental channel, it is subject to change.
+
+Our decision to go forward with our own `AuthenticationFilter` was to ensure we could quckly provide authenticaiton to our users while allowing us to closley monitor progress of the ExternalAuthFilter.


To be clear, this proposed AuthenticationFilter is to supply different auth methods than provided in the ExternalAuth filter, and is technically unrelated.

sjberman · 2025-11-10T20:13:02Z

docs/proposals/authentication-filter.md

+	StripAuthorization *bool `json:"stripAuthorization,omitempty"`
+}
+
+// HeaderValue defines a header name and a value (may reference NGINX variables).


(may reference NGINX variables)
Are users defining these variables? What types of variables might they want to use?

I ask because for our other header filters, we currently don't support this. Though we may at some point.

sjberman · 2025-11-10T20:17:16Z

docs/proposals/authentication-filter.md

+	// +optional
+	SecretRef *NamespacedSecretKeyReference `json:"secretRef,omitempty"`
+
+	// MountPath is the path where NGF will mount the data into the NGINX container.


Should a user have any control over this? I'm not sure they should or why they would need to.

That's a good point. It's probably more secure and less error prone for us to default this directory.
As I think about that, we will want to ensure we can write to this directory when readOnlyRootfileSystem is enabled.

sjberman · 2025-11-10T20:17:34Z

docs/proposals/authentication-filter.md

+	// Example: "/etc/nginx/keys".
+	MountPath string `json:"mountPath"`
+
+	// FileName is the file name of the JWKS within the mount path.


Same comment as MountPath.

sjberman · 2025-11-10T20:21:13Z

docs/proposals/authentication-filter.md

+### Auth failure default headers
+
+Below are a list of default defensive headers for authentication failure reponses.
+We may choose to include these headers by default for improved robustness in auth failure responses.


We may choose to include these headers by default

That decision should be made as part of this design.

What are your thoughts on them? Do they seem overkill or would they work as secure default headers?

I'd like to read more about these and understand them better. Do you have some resources on them?

sjberman · 2025-11-11T17:56:42Z

docs/proposals/authentication-filter.md

+	// Exactly one of ConfigMapRef or SecretRef must be set.
+	//
+	// +optional
+	ConfigMapRef *NamespacedObjectReference `json:"configMapRef,omitempty"`


Do we not need a Key from the ConfigMap like we do for Secret?

Also, do we need to support ConfigMap? What if we just supported Secret?

That's true. It may be easier to just support Secrets. It would be more secure by default too.
I added this mostly to give users flexibility. After you asked this, I looked around for some use cases where someone might choose ConfigMapRef over SecretRef.

I found these reasons why a user might choose ConfigMapRef over SecretRef for JWKS:

Non-sensitive data: Verification keys are public. Storing them in a Secret implies sensitivity that doesn’t exist unless you’re handling private/decryption keys (e.g., for auth_jwt_type=encrypted or nested). For public-only JWKS, ConfigMap is appropriate.

Authoring convenience: ConfigMap stores raw JSON under data, while Secret requires base64-encoding. This avoids encoding errors and makes it simpler to read, diff, lint, and template the JWKS.

GitOps friendliness: Public configuration can be safely committed to source control and templated with Helm/Kustomize. Secrets generally shouldn’t be committed to VCS.

Operational visibility: Raw JSON is easier to inspect with kubectl for debugging and audits. No decoding step is needed to verify content.

RBAC/Policy simplification: Many clusters restrict Secret access more tightly. If your controller/policy allows reading ConfigMaps more readily than Secrets, using ConfigMap avoids broader secret-read permissions.

Avoiding unnecessary “secret” handling: Secrets may be encrypted at rest and trigger compliance pipelines and secret scanners. ConfigMaps avoid that overhead for public material.

I think for a first pass, we just support Secret. And I think we can use a more generic object reference than SecretRef and ConfigmapRef. That way if we add ConfigMap support, we can reuse the existing object reference.

sjberman · 2025-11-14T20:20:02Z

docs/proposals/authentication-filter.md

+	// Read token from a cookie. Default: false.
+	//
+	// +optional
+  // +kubebuilder:default=false


Is this an optional field? If so, it shouldn't have a default.

Same comment for the rest of these fields.

shaun-nx added 2 commits November 6, 2025 18:16

Add Implementable Proposal for AuthenticationFilter

d91a5f4

Update auth header code block

9047c3e

shaun-nx requested review from a team as code owners November 6, 2025 18:19

github-project-automation bot added this to NGINX Gateway Fabric Nov 6, 2025

github-project-automation bot moved this to 🆕 New in NGINX Gateway Fabric Nov 6, 2025

github-actions bot added the documentation Improvements or additions to documentation label Nov 6, 2025

Fix pre-commit and lint errors

c937366

salonichf5 requested changes Nov 6, 2025

View reviewed changes

github-project-automation bot moved this from 🆕 New to 🏗 In Progress in NGINX Gateway Fabric Nov 6, 2025

shaun-nx added 7 commits November 7, 2025 09:08

Update Golang API with defaults and CEL validation with kubebuilder

1b8bac2

Add additional defaults and CEL validations

2f143e9

Merge branch 'main' into proposal/authentication-filter

61f479c

Fix typos

47ff38b

Update comments in GolangAPI to decribe relative NGINX directives

40b8224

Update API and Security Considerations for ReferenceGrant integration

24966b8

Merge branch 'main' into proposal/authentication-filter

ecceb93

shaun-nx requested review from salonichf5 and sjberman November 7, 2025 14:18

Fix pre-commit errors

da1b17e

ciarams87 requested changes Nov 7, 2025

View reviewed changes

sjberman reviewed Nov 7, 2025

View reviewed changes

shaun-nx added 3 commits November 7, 2025 15:38

Fix typos and grammer

38dd8f7

Update BasicAuth AIP and examples to use secretRef

e362745

Update KeyCache to use v1alpha1.Duration

dd5aaa8

shaun-nx requested review from ciarams87 and sjberman November 7, 2025 16:21

sjberman reviewed Nov 10, 2025

View reviewed changes

sjberman reviewed Nov 11, 2025

View reviewed changes

Merge branch 'main' into proposal/authentication-filter

bf3ed2b

sjberman reviewed Nov 14, 2025

View reviewed changes


		## Introduction

		This document focuses expliclty on Authentication (AuthN) and not Authorization (AuthZ). Authentication (AuthN) defines the verification of identiy. It asks the question, "Who are you?". This is different from Authorization (AuthZ), which preceeds Authentication. It asks the question, "What are you allowed to do".

	This document focuses expliclty on Authentication (AuthN) and not Authorization (AuthZ). Authentication (AuthN) defines the verification of identiy. It asks the question, "Who are you?". This is different from Authorization (AuthZ), which preceeds Authentication. It asks the question, "What are you allowed to do".
	This document focuses explicitly on Authentication (AuthN) and not Authorization (AuthZ). Authentication (AuthN) defines the verification of identity. It asks the question, "Who are you?". This is different from Authorization (AuthZ), which preceeds Authentication. It asks the question, "What are you allowed to do".

	- As an Application Developer, I want to enforce authenticaiton on specific routes and matches.
	- As an Application Developer, I want to enforce authentication on specific routes and matches.

	- Example HTTPRoutes and NINGX configuration
	- Example HTTPRoutes and NGINX configuration

	- Example NINGX configuration for both Local & Remote JWKS
	- Example NGINX configuration for both Local & Remote JWKS


		### Key rotation

		Users sholud be advised to regularly rotate their JWKS keys in cases where they chose to reference a local JWKS via a `secrefRef` or `configMapRef`

	Users sholud be advised to regularly rotate their JWKS keys in cases where they chose to reference a local JWKS via a `secrefRef` or `configMapRef`
	Users should be advised to regularly rotate their JWKS keys in cases where they chose to reference a local JWKS via a `secrefRef` or `configMapRef`

	Our decision to go forward with our own `AuthenticationFilter` was to ensure we could quckly provide authenticaiton to our users while allowing us to closley monitor progress of the ExternalAuthFilter.
	Our decision to go forward with our own `AuthenticationFilter` was to ensure we could quickly provide authentication to our users while allowing us to closely monitor progress of the ExternalAuthFilter.


		### Documenting filter behavour

		In regards to documentation of filter behavour with the `AuthenticationFilter`, the Gateway API documentation on filters states the following:


		### Attachment

		Filters must be attached to a HTTPRoute at the `rules.matces` level.

	- This header explicitly set the body as plan text. This prevents browsers from treating the response as HTML or JavaScript, and is effective at mitigating Cross-side scrpting (XSS) through error pages
	- This header explicitly set the body as plain text. This prevents browsers from treating the response as HTML or JavaScript, and is effective at mitigating Cross-side scrpting (XSS) through error pages


		### Validation

		When referencing an `AuthenticationFilter` in either a HTTPRoute or GRPCRoute, it is important that we ensure all configurable fields are validated, and that the resulting NGINX configuration is correct and secure


		We should validated that only one `AuthenticationFilter` is referenced per-rule. Multiple references to an `AuthenticationFilter` in a single rule should result in an `Invalid` HTTPRoute/GRPCRoute, and the resource should be `Rejected`.

		an `AuthenticationFilter` that sets a `onFailure.statusCode` to anything other than `401` or `403` should be rejected. This relates to the "Auth failure behaviour" section in the Security Condierations section.

Enhancement Proposal: Authentication Filter #4235

Are you sure you want to change the base?

Enhancement Proposal: Authentication Filter #4235

Conversation

shaun-nx commented Nov 6, 2025

Proposed changes

Checklist

Release notes

Uh oh!

codecov bot commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaun-nx Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ciarams87 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Nov 6, 2025 •

edited

Loading

shaun-nx Nov 7, 2025 •

edited

Loading