Skip to content

Comments

feat(domains): add accessMode configuration for API Gateway#13343

Merged
czubocha merged 2 commits intomainfrom
sc-3823
Feb 12, 2026
Merged

feat(domains): add accessMode configuration for API Gateway#13343
czubocha merged 2 commits intomainfrom
sc-3823

Conversation

@czubocha
Copy link
Contributor

@czubocha czubocha commented Feb 11, 2026

Overview

Adds support for accessMode configuration on custom domains, allowing users to set API Gateway endpoint access modes (BASIC or STRICT) for REST APIs managed through API Gateway V1.

Changes

Core Features

  • accessMode Configuration: New optional domain configuration parameter supporting basic and strict values for REST domains with single-level basePath
  • Custom Domain Updates: Implemented updateCustomDomain() method for both V1 and V2 API Gateway wrappers to reconcile configuration drift
  • V1-only Support: accessMode is restricted to REST APIs with single-level basePath; multi-level basePath and HTTP/WebSocket APIs use V2 and don't support this setting

Validation & Error Handling

  • Added validation to prevent accessMode configuration on incompatible domain types (HTTP, WebSocket, multi-level REST)
  • Added validation for enhanced security policies on V2 domains (only TLS_1_0 and TLS_1_2 supported)
  • New error codes for invalid accessMode and incompatible configurations

Explicit Configuration Tracking

  • Tracks hasSecurityPolicyConfigured and hasAccessModeConfigured flags to implement reconciliation semantics: only explicitly configured fields are updated; omitted fields remain unchanged

Performance

  • Lazy evaluation of default API type to avoid unnecessary CloudFormation template introspection

Tests

  • Comprehensive unit tests for V1/V2 update scenarios
  • Domain configuration validation tests
  • Domain info mapping tests
  • Integration test fixture updates

Documentation

  • Updated configuration guide with accessMode examples and security policy notes
  • Added reconciliation behavior documentation

Fixes #13329
Fixes #13332


Note

Medium Risk
Touches custom domain provisioning/update paths and adds reconciliation that can change live API Gateway domain settings; validation reduces misconfig risk but rollout could affect existing domain configurations.

Overview
Adds a new optional custom-domain setting, accessMode (basic/strict), wired to API Gateway v1 domain creation and schema-validated in provider.domain config.

Implements updateCustomDomain() for both API Gateway wrappers and updates the domain creation flow to reconcile existing domains: only explicitly configured securityPolicy and accessMode are updated (including allowing explicit unsetting of accessMode on v1), otherwise existing values are left untouched.

Tightens validation around security settings: API Gateway v2-managed domains only allow TLS_1_2 securityPolicy, and accessMode is rejected for v2-managed domains (non-REST or multi-segment REST basePath) and requires enhanced SecurityPolicy_* on v1. Docs and tests are updated accordingly, with new domain-related error codes.

Written by Cursor Bugbot for commit 05a6001. This will update automatically on new commits. Configure here.

Summary by CodeRabbit

  • New Features

    • Added accessMode configuration for REST custom domains (BASIC or STRICT) with single-level basePath support.
    • Custom domains can be updated in-place when security policy or accessMode are changed; only explicitly configured fields are reconciled.
  • Validation

    • Stronger validation: accessMode disallowed for API Gateway V2; API Gateway V2 requires TLS_1_2 and enhanced security-policy checks.
  • Documentation

    • Updated guides and examples to show accessMode, REST/apiType conventions, and reconciliation/security policy guidance.

@Mmarzex
Copy link
Contributor

Mmarzex commented Feb 11, 2026

Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 11, 2026

📝 Walkthrough

Walkthrough

Adds support to update existing AWS API Gateway custom domains (V1 and V2), introduces accessMode for REST domains with validation and reconciliation rules, updates domain models/provider schema, adjusts domain plugin control flow, and expands documentation and tests.

Changes

Cohort / File(s) Summary
Documentation
docs/sf/providers/aws/guide/domains.md, docs/sf/providers/aws/guide/serverless.yml.md
Documented new accessMode option (REST-only, single-level basePath) and reconciliation/security-policy guidance; switched sample domain apiType values to rest and adjusted related examples.
API Gateway Wrappers
packages/serverless/lib/plugins/aws/domains/aws/api-gateway-v1-wrapper.js, packages/serverless/lib/plugins/aws/domains/aws/api-gateway-v2-wrapper.js
Added updateCustomDomain(domain) to both V1 and V2 wrappers; V1 supports patching securityPolicy and endpointAccessMode, V2 updates securityPolicy via DomainNameConfigurations and validates certificate ARN.
Plugin Core & Validation
packages/serverless/lib/plugins/aws/domains/index.js
Deferred default API type resolution, added usesApiGatewayV2(domain) helper, updated getApiGateway selection, enhanced validations for TLS/securityPolicy/accessMode and adjusted existing-vs-update logging flow.
Globals & Models
packages/serverless/lib/plugins/aws/domains/globals.js, packages/serverless/lib/plugins/aws/domains/models/apigateway-base.js, packages/serverless/lib/plugins/aws/domains/models/domain-config.js, packages/serverless/lib/plugins/aws/domains/models/domain-info.js
Introduced Globals.accessModes; added abstract updateCustomDomain in base model; DomainConfig parses/validates accessMode and exposes flags; DomainInfo maps certificateArn and accessMode from AWS responses.
Provider Schema & Errors
packages/serverless/lib/plugins/aws/provider.js, packages/util/src/errors/index.js
Added accessMode to provider AWS custom domain schema (case-insensitive BASIC/STRICT) and introduced new domain-related error codes and an update-failure code.
Tests
packages/serverless/test/unit/lib/plugins/aws/domains/aws/api-gateway-v1-wrapper.test.js, packages/serverless/test/unit/lib/plugins/aws/domains/aws/api-gateway-v2-wrapper.test.js, packages/serverless/test/unit/lib/plugins/aws/domains/index.test.js, packages/serverless/test/unit/lib/plugins/aws/domains/models/domain-config.test.js, packages/serverless/test/unit/lib/plugins/aws/domains/models/domain-info.test.js
Added/updated unit tests covering create/update flows, accessMode parsing/validation, reconciliation behavior, and DomainInfo mappings.
Integration Fixture
packages/sf-core/tests/integration/simple-nodejs/fixture/package.json
Added fixture package.json setting Node.js module type to CommonJS.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Plugin as ServerlessCustomDomain
    participant WrapperV as APIGatewayV1/V2 Wrapper
    participant AWS as AWS API Gateway SDK

    User->>Plugin: Deploy domain config (name, apiType, securityPolicy, accessMode?)
    Plugin->>Plugin: Determine API type (usesApiGatewayV2)
    Plugin->>Plugin: Check existing domain via SDK
    alt domain exists & configured fields differ
        Plugin->>WrapperV: updateCustomDomain(domain)
        WrapperV->>WrapperV: validate inputs (cert ARN / accessMode / securityPolicy)
        WrapperV->>AWS: UpdateDomainNameCommand / Patch operations
        AWS-->>WrapperV: DomainInfo response
        WrapperV-->>Plugin: DomainInfo (updated)
        Plugin->>Plugin: Log "was updated"
    else domain exists & no drift
        Plugin->>Plugin: Log "already exists"
    else domain missing
        Plugin->>WrapperV: createCustomDomain(domain)
        WrapperV->>AWS: CreateDomainNameCommand
        AWS-->>WrapperV: DomainInfo response
        WrapperV-->>Plugin: DomainInfo (created)
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested reviewers

  • eahefnawy

Poem

🐰 I hopped through configs, files, and tests,
Patching domains where drifted rests,
Security snug, accessMode set,
REST and V2 now safely met,
A little hop — deployments blessed!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title 'feat(domains): add accessMode configuration for API Gateway' accurately describes the primary change: introducing accessMode as a new configuration option for API Gateway custom domains.
Linked Issues check ✅ Passed The PR addresses both linked issues: #13329 (multi-API-type stacks) via lazy defaultApiType evaluation and #13332 (securityPolicy with accessMode) via accessMode support and updateCustomDomain implementations.
Out of Scope Changes check ✅ Passed All changes align with PR objectives: accessMode configuration and validation, updateCustomDomain implementations for V1/V2, domain info mapping, error codes, tests, and documentation are all in scope.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch sc-3823

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@czubocha
Copy link
Contributor Author

@cursor review

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5590f74c4e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
docs/sf/providers/aws/guide/domains.md (1)

226-253: ⚠️ Potential issue | 🟡 Minor

Documentation inconsistency: apiType: rest with httpApi event.

Line 232 was changed to apiType: rest, but the function event at line 251 still uses httpApi (which corresponds to HTTP APIs, not REST APIs). REST API events use - http:, not - httpApi:. This will confuse users.

Proposed fix

Either revert apiType back to http:

-    apiType: rest
+    apiType: http

Or change the event to match a REST API:

     events:
-      - httpApi:
-          path: /users
-          method: get
+      - http:
+          path: /users
+          method: get
🤖 Fix all issues with AI agents
In `@packages/serverless/lib/plugins/aws/domains/models/domain-config.js`:
- Around line 15-16: The two boolean flags this.hasSecurityPolicyConfigured and
this.hasAccessModeConfigured should treat null and undefined the same; change
their assignments to check for != null (e.g., set
this.hasSecurityPolicyConfigured = config.securityPolicy != null and
this.hasAccessModeConfigured = config.accessMode != null) so that both null and
undefined are considered "not configured" and avoid mismatches with
_getAccessMode when deciding whether to patch values.
🧹 Nitpick comments (1)
packages/serverless/lib/plugins/aws/domains/index.js (1)

187-209: Validation logic looks correct and produces helpful error messages.

The dynamic error message at line 204 that explains why a domain resolves to V2 (multi-segment basePath vs non-REST apiType) is a nice touch for developer experience.

One observation: the securityPolicy validation (line 188) is gated on hasSecurityPolicyConfigured, but the accessMode validation (line 200) checks domain.accessMode directly. This is fine because _getAccessMode returns undefined when not configured, so the truthiness check works. But for consistency with the explicit-tracking pattern, domain.hasAccessModeConfigured would make the intent clearer:

-      if (domain.accessMode && this.usesApiGatewayV2(domain)) {
+      if (domain.hasAccessModeConfigured && this.usesApiGatewayV2(domain)) {

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 05a6001de3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
docs/sf/providers/aws/guide/domains.md (1)

229-253: ⚠️ Potential issue | 🟡 Minor

Example configuration is invalid — accessMode requires an enhanced securityPolicy.

The example shows securityPolicy: TLS_1_2 with accessMode: strict, but the validation logic in index.js (Lines 211–222) requires securityPolicy to start with SecurityPolicy_ when accessMode is set. This example would throw a DOMAIN_VALIDATION_INCOMPATIBLE_ACCESS_MODE error at runtime. The reconciliation notes section at Line 425 correctly documents this requirement, but the example contradicts it.

Fix the example to use an enhanced security policy
     securityPolicy: TLS_1_2
+    securityPolicy: SecurityPolicy_TLS13_2025_EDGE
     accessMode: strict
🤖 Fix all issues with AI agents
In `@packages/serverless/lib/plugins/aws/domains/index.js`:
- Around line 399-411: The catch currently wraps all errors with a
DOMAIN_CREATION_FAILED/“Unable to create domain” message which is misleading for
failures from apiGateway.updateCustomDomain; update the flow so failures thrown
by updateCustomDomain (called as updateCustomDomain(domain)) produce a distinct
or more accurate error message (e.g., “Unable to update domain” or “Unable to
create or update domain”) before rethrowing, by tracking whether you attempted
an update (set a local flag like isUpdate when calling updateCustomDomain or
inspect whether updatedDomainInfo path ran) and using that flag in the catch to
choose the appropriate error text; ensure domain.domainInfo assignment and
Logging.logInfo remain unchanged and only the error wrapping message is
adjusted.

@czubocha
Copy link
Contributor Author

@cursor review

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

@czubocha czubocha requested a review from eahefnawy February 11, 2026 23:36
@czubocha czubocha merged commit 9279e61 into main Feb 12, 2026
13 checks passed
@czubocha czubocha deleted the sc-3823 branch February 12, 2026 17:16
@github-actions github-actions bot locked and limited conversation to collaborators Feb 12, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

3 participants