fix(cloudformation): provision AWS::ApiGatewayV2::Authorizer and wire Route.AuthorizerId

[rogueserenity]

Summary

Fixes #1758.

CloudFormationResourceProvisioner had no case for AWS::ApiGatewayV2::Authorizer (only AWS::ApiGateway::Authorizer, the v1/REST type, added in #796 for #788). The v2 resource fell through the default branch and was never provisioned — apiGatewayV2Service.createAuthorizer was never called, so apigatewayv2 get-authorizers came back empty regardless of what the template declared. provisionApiGatewayV2Route also never read AuthorizerId off the template at all, even though ApiGatewayV2Service.createRoute/updateRoute already handle it. Net effect: a CloudFormation-managed HTTP API v2 JWT authorizer silently degraded to AuthorizationType: NONE in practice — a route configured with AuthorizationType: JWT and a real AuthorizerId still let every request through unauthenticated, because neither the authorizer nor the route's link to it were ever persisted.

What changed

• New case "AWS::ApiGatewayV2::Authorizer" in CloudFormationResourceProvisioner, plus provisionApiGatewayV2Authorizer, modeled on the neighboring provisionApiGatewayV2Route/Integration/Stage methods. Maps the CFN PascalCase properties (Name, AuthorizerType, IdentitySource, JwtConfiguration.Audience/Issuer, AuthorizerUri, AuthorizerPayloadFormatVersion, AuthorizerResultTtlInSeconds, EnableSimpleResponses) onto the existing ApiGatewayV2Service.createAuthorizer/updateAuthorizer camelCase request shape.
• provisionApiGatewayV2Route now reads AuthorizerId from the template and passes it through, so a route's Ref to an authorizer resource actually resolves to something and gets persisted.
• No delete case was added for AWS::ApiGatewayV2::Authorizer — consistent with the existing v2 Route/Integration/Stage types, none of which have a case in delete(...) either, since that method's signature (resourceType, physicalId, region) has no apiId to scope the lookup.

Test plan

• New integration test createStack_apiGatewayV2AuthorizerIsProvisionedAndWiredToRoute in CloudFormationIntegrationTest: deploys a template with an AWS::ApiGatewayV2::Api + Authorizer + Integration + Route (AuthorizerId: !Ref Authorizer), then asserts GetAuthorizers returns the authorizer with the right JwtConfiguration, and GetRoutes shows the route's AuthorizerId resolved to that authorizer's real id.
• Ran the full CloudFormationIntegrationTest suite (90 tests) plus RouteAuthorizerIdResponseTest and IntegrationConnectionTypeAndAuthorizerSimpleResponsesTest (the existing v2 authorizer/route regression coverage) — 100/100 pass, no regressions.
• Also manually reproduced the bug against floci/floci:latest (1.5.30) via docker run + the AWS CLI before writing the fix, confirming get-authorizers returned {"Items":[]} and an unauthenticated request to the route returned 200 instead of 401.

[greptile-apps]

Greptile Summary

This PR closes #1758 by wiring AWS::ApiGatewayV2::Authorizer into the CloudFormation provisioner (create/update/delete), fixing the missing AuthorizerId on provisionApiGatewayV2Route, and adding $request.querystring.* identity-source support to the JWT enforcement path. All three changes are necessary together: without the provisioner case the authorizer was never created; without the route fix the link was never persisted; without the querystring path any authorizer configured that way would still 401.

• CloudFormationResourceProvisioner: adds provisionApiGatewayV2Authorizer (maps all CFN PascalCase properties onto the service's camelCase request, handles scalar or array IdentitySource), a scoped delete(StackResource, region) case that reads ApiId from stored attributes, and passes authorizerId through in provisionApiGatewayV2Route.
• ApiGatewayExecuteController: extends extractToken / enforceJwtAuthorizer to accept UriInfo and extract tokens from $request.querystring.* sources, alongside the existing $request.header.* path.
• Tests: four new CloudFormationIntegrationTest cases (provision + GetAtt wiring + scalar IdentitySource + delete) and a new HttpApiJwtAuthorizerQuerystringTest unit covering the querystring token extraction path.

Confidence Score: 5/5

Safe to merge — all three changed code paths (authorizer provisioning, route wiring, querystring token extraction) are narrow, well-tested, and consistent with existing patterns.

The provisioner additions follow the same shape as the neighbouring Route/Integration/Stage methods; the delete case stores and reads ApiId through the existing attribute map; the resolveIdentitySource helper correctly handles the scalar-vs-array CFN ambiguity that broke things before; and the querystring extraction in ApiGatewayExecuteController is a straightforward extension of the header path. Both concerns from the previous review round are addressed.

Files Needing Attention: No files require special attention.

Important Files Changed

Filename	Overview
src/main/java/io/github/hectorvent/floci/services/cloudformation/CloudFormationResourceProvisioner.java	Core fix: adds provision/delete cases for AWS::ApiGatewayV2::Authorizer and wires AuthorizerId into the Route provisioner; the new resolveIdentitySource helper correctly handles both scalar and array CFN forms.
src/main/java/io/github/hectorvent/floci/services/apigateway/ApiGatewayExecuteController.java	Extends JWT enforcement to support $request.querystring.* identity sources by threading UriInfo through enforceJwtAuthorizer and extractToken; change is minimal and consistent with the existing header path.
src/test/java/io/github/hectorvent/floci/services/cloudformation/CloudFormationIntegrationTest.java	Adds four integration tests covering authorizer provisioning, Ref and Fn::GetAtt wiring, scalar IdentitySource, and scoped delete against an out-of-band API; IdentitySource is now asserted in GetAuthorizers responses.
src/test/java/io/github/hectorvent/floci/services/apigatewayv2/HttpApiJwtAuthorizerQuerystringTest.java	New regression test for querystring-based JWT token extraction; validates that a valid token in the query string is accepted (502, not 401), a missing token is rejected (401), and a header-only token does not satisfy a querystring identity source.

_{Reviews (8): Last reviewed commit: "chore: retrigger CI" | Re-trigger Greptile}

[rogueserenity]

Good catch — fixed in f252ba5.

resolveStringListOrEmpty silently returned an empty list for a scalar-string IdentitySource, which is stricter than ApiGatewayV2Service.createAuthorizer/updateAuthorizer themselves (they already accept identitySourceRaw instanceof String). Added a local resolveIdentitySource that accepts both forms, matching the service layer, plus a regression test for the scalar case and a stronger assertion on the existing test (it wasn't checking IdentitySource at all before).

One correction on the framing: the AWS docs for AWS::ApiGatewayV2::Authorizer.IdentitySource list the type as "Array of String" and the only example uses array syntax — so the array form is the documented one, not the scalar. The bug is real regardless (the service layer's own leniency should carry through), just wanted to flag that for the record.

[rogueserenity]

@hectorvent can you approve this one for CI? I have a follow up to this one once it merges to fix the SAM side of this.

[rogueserenity]

@hectorvent ready for you to review/merge as you have time. Thanks!

[abanna]

@rogueserenity thanks for building out the CloudFormation support here. Could we put AuthorizerId in the resource attributes as well as the physical ID? Ref works, but Fn::GetAtt Authorizer.AuthorizerId does not, so route templates receive the literal string and fail later. A small GetAtt route case would cover it.

[rogueserenity]

Fixed in def4f3b — provisionApiGatewayV2Authorizer now also stores r.getAttributes().put("AuthorizerId", authorizer.getAuthorizerId()) alongside the physical id, following the same pattern every other resource type already uses (S3, SQS, VPC, etc.) to make GetAtt resolvable. Fn::GetAtt Authorizer.AuthorizerId reads that attributes map, which was never populated before — only Ref (which reads the physical id) worked.

Added createStack_apiGatewayV2RouteResolvesAuthorizerIdViaGetAtt, a variant of the existing wired-route test that uses Fn::GetAtt instead of Ref for the route's AuthorizerId, asserting it resolves to the real id rather than the literal placeholder string. Verified the test actually catches the regression by temporarily removing the attribute and confirming it fails.

[abanna]

Thanks for adding that and for the regression coverage. Fn::GetAtt should work properly now.

[abanna]

One runtime follow-up: HTTP API JWT authorizers support $request.querystring.* sources too, but the runtime only passes header information into token extraction. A template using a query-string token will 401 even with a valid JWT. Could we pass query parameters through and add a quick execution-level test?

[rogueserenity]

Fixed in 34d238b — extractToken only ever received HttpHeaders, with no query-parameter access at all, so any IdentitySource like $request.querystring.token was silently unusable and a request using it always 401'd. Threaded UriInfo through enforceJwtAuthorizer/extractToken (it was already available one call site up, in dispatchV2) and added a $request.querystring. branch mirroring the one enforceRequestAuthorizerV2 already has for Lambda REQUEST authorizers.

Added HttpApiJwtAuthorizerQuerystringTest — an execution-level test hitting a real JWT-protected route with the token only in the query string (asserting it gets past authorization), plus checks that a request with no token anywhere 401s, and that a token in the Authorization header alone doesn't satisfy an authorizer configured for a querystring-only identity source. Verified the primary case fails without the fix.

[abanna]

Nice, thanks for wiring that through the execution path and adding the test. This handles the query-string JWT case I was concerned about.

[abanna]

One cleanup detail: the generic delete path does not know about this resource. If ApiId comes from a parameter rather than a stack-owned API, deleting the stack reports success but leaves the authorizer behind. Could we retain the API ID on the resource and add a scoped delete path for it?

[rogueserenity]

Fixed in def4f3b — added a scoped case for AWS::ApiGatewayV2::Authorizer in delete(StackResource, region), following the same shape already used for AWS::EKS::Nodegroup (a resource needing more context than type+physicalId to delete). ApiId is now stored as a resource attribute during provisioning and read back here to call apiGatewayV2Service.deleteAuthorizer(region, apiId, physicalId) directly — previously the generic type/physicalId switch had no case for this type at all and silently no-op'd.

Added deleteStack_apiGatewayV2AuthorizerOnNonStackOwnedApiIsRemoved, which deliberately creates the API out-of-band (not as a stack resource) so AWS::ApiGatewayV2::Api's own cascading delete can't be the thing removing the authorizer — that's exactly the scenario you flagged, and it isolates the new scoped delete path as the only thing that could make the test pass. Verified it fails without the fix.

[abanna]

Thanks for tracking the API ID and covering the external API case. This looks right now.

[hectorvent]

Hello @rogueserenity,

Thanks for the PR!

Could you please update the commit history to remove the Co-authored-by: Claude <...> line from the commit message? We prefer to keep the attribution focused on human contributors for this project. Once that's cleaned up, I'm happy to take another look!

[rogueserenity]

Done — history rewritten in e9b3553 to drop the Co-Authored-By: Claude ... trailers. Sorry about that.

Only the two commits that carried it were touched (34d238b0 → 5939b6f1 and def4f3b6 → fda5cfce); the rest were unchanged apart from new SHAs from the rewrite. Merge topology is preserved and the tree is byte-identical to what you last reviewed — git diff against the old head is empty, so nothing about the change itself moved.

Audit for the record:

git log --pretty='%(trailers:key=Co-Authored-By,valueonly)' upstream/main..HEAD

comes back empty across all 7 commits. CI is re-running now.

[rogueserenity]

@hectorvent this is ready for you to merge

[abanna]

Heads up before this gets merged — GitHub reports the branch as conflicting with main (mergeable: CONFLICTING, mergeStateStatus: DIRTY), so it can't go in as-is despite the green checks.

Exactly one file collides, and it's right here. main has since gained an AWS::Events::Rule case in delete(StackResource, region) in the same spot this PR adds its AWS::ApiGatewayV2::Authorizer case — both immediately after the AWS::EKS::Nodegroup block, and both ending on the same shared return; } lines, which is what makes git treat it as a conflict rather than two independent insertions.

The resolution is to keep both blocks, each closing with its own return;:

if ("AWS::Events::Rule".equals(resourceType)) {
    deleteEventBridgeRuleSafe(resource.getPhysicalId(),
            resource.getAttributes().get("EventBusName"), region);
    return;
}
if ("AWS::ApiGatewayV2::Authorizer".equals(resourceType)) {
    String apiId = resource.getAttributes().get("ApiId");
    ...
    return;
}

Worth resolving deliberately rather than by reflex: because that trailing return; } is shared context, taking either side wholesale still compiles and CI still goes green — it just silently drops the other side's delete path, either main's custom-bus rule cleanup or the authorizer cleanup this PR exists to add. That failure is invisible until a stack delete leaves something behind.

I checked the rest of the merge and nothing else collides: resolveOptional, resolveStringListOrEmpty, and the createAuthorizer / updateAuthorizer / deleteAuthorizer signatures are all unchanged on main, so no other fixups should be needed after resolving this hunk.

The three things I raised earlier — the AuthorizerId attribute, the $request.querystring.* identity source, and this scoped delete — all look right at e9b35533.

[rogueserenity]

Conflict resolved. Ready for merge.

[hectorvent]

Thanks @rogueserenity @abanna

[hectorvent]

🎉 This PR is included in version 1.6.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀