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 (96032ac) to head (dd5aaa8).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4235      +/-   ##
==========================================
+ Coverage   86.09%   86.11%   +0.02%     
==========================================
  Files         131      131              
  Lines       14171    14171              
  Branches       35       35              
==========================================
+ Hits        12200    12203       +3     
+ Misses       1767     1765       -2     
+ Partials      204      203       -1

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

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

docs/proposals/authentication-filter.md

+
+## Introduction
+
+This document focus expliclty on Authentiaction (AuthN) and not Authorization (AuthZ). Authentiaction (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 focus expliclty on Authentiaction (AuthN) and not Authorization (AuthZ). Authentiaction (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".

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

salonichf5 · 2025-11-06T18:57:13Z

docs/proposals/authentication-filter.md

+	Secret string `json:"secret"`
+
+	// Key is the key within the Secret that contains the htpasswd data.
+	// Default: "htpasswd".
+	//
+	// +optional
+	Key *string `json:"key,omitempty"`
+
+	// Realm used by NGINX auth_basic; helps with logging and WWW-Authenticate.
+	//
+	// +optional
+	Realm *string `json:"realm,omitempty"`
+
+	// OnFailure customizes the 401 response for failed authentication.
+	//
+	// +optional
+	OnFailure *AuthFailureResponse `json:"onFailure,omitempty"`


nginx directives should be specified for the cases that apply.

Good idea. I'll make that change.

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

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.

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


		## Introduction

		This document focus expliclty on Authentiaction (AuthN) and not Authorization (AuthZ). Authentiaction (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 focus expliclty on Authentiaction (AuthN) and not Authorization (AuthZ). Authentiaction (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 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`

	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.

	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

Uh oh!

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!

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!

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!

salonichf5 Nov 6, 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!

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

codecov bot commented Nov 6, 2025 •

edited

Loading

shaun-nx Nov 7, 2025 •

edited

Loading

salonichf5 Nov 6, 2025 •

edited

Loading