Validate connection port is within valid TCP/UDP range (1-65535)#68541
Draft
Aydeing wants to merge 3 commits into
Draft
Validate connection port is within valid TCP/UDP range (1-65535)#68541Aydeing wants to merge 3 commits into
Aydeing wants to merge 3 commits into
Conversation
Connections previously accepted any integer for the ``port`` field without bounds checking. Add range validation (1-65535) on write paths: - ``airflow.models.connection.Connection`` constructor and ``from_json`` via a new ``_validate_port`` static method. SQLAlchemy's ``@reconstructor`` does not call ``__init__``, so DB loads of legacy rows with out-of-range port values are unaffected. - ``airflow.sdk.definitions.connection.Connection`` via an attrs field validator and explicit range check in ``from_json``. - ``ConnectionBody`` REST API request schema via ``Field(ge=1, le=65535)``. - ``--conn-port`` CLI argument now uses ``type=int`` so argparse rejects non-integer input early; range is enforced by the model. Port 0 is rejected: ``port`` is optional, so ``None`` is the no-port sentinel and 0 has no valid use case. Response models (execution API ``ConnectionResponse``, generated SDK datamodels, ``schema.json``) are intentionally left unchanged so existing installations with persisted invalid port values continue to load through the read paths without errors. Closes apache#68382
Cover all four enforcement points changed by the port validation: - ``airflow.models.connection.Connection``: accepted values (1, 22, 5432, 65535, ``None``), rejected values (0, -1, 65536, 99999), the same matrix for ``from_json``, and a test that asserts a legacy DB row with an out-of-range port still loads via the ``@reconstructor`` ``on_db_load`` path without raising. - ``airflow.sdk.definitions.connection.Connection``: same accept/reject matrix for the constructor and ``from_json``. - REST API ``POST /connections``: ``test_post_should_respond_422_for_out_of_range_port`` for 0, -1, 65536, 99999. - ``airflow connections add`` CLI: rejects out-of-range port values and rejects non-integer ``--conn-port`` input at argparse time.
|
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes: #68382
Airflow stores a
portfield on connections but never validates that the value is a valid TCP/UDP port number. This adds port range validation (1–65535) on write paths only, so existing persisted connections with now-invalid port values continue to load via the ORM without errors — addressing the maintainer review concern about not breaking existing installations.Where validation is enforced (create/update paths)
airflow.models.connection) —_validate_port()static method called in__init__andfrom_json(). SQLAlchemy's@reconstructordoes not call__init__, so DB loads are unaffected.airflow.sdk.definitions.connection) — attrs@port.validator+from_json()validation.ConnectionBody) — PydanticField(ge=1, le=65535).--conn-port) — changedtype=str→type=intfor argparse type checking; range validated by the model constructor.What is intentionally NOT validated (read/response paths)
To avoid breaking existing installations that may have persisted invalid port values:
ConnectionResponse— unchanged.ConnectionResponse— unchanged._generated.py) — unchanged.schema.json) — unchanged.Port 0 is rejected
Per maintainer feedback on the issue: since
portis optional (None= no port), port 0 has no valid use case and is rejected. Range is 1–65535.Tests added
airflow-core/tests/unit/models/test_connection.pytest_port_within_valid_range_is_accepted(1, 22, 5432, 65535) ·test_port_none_is_accepted·test_port_out_of_range_is_rejected(0, -1, 65536, 99999) ·test_from_json_rejects_out_of_range_port·test_orm_load_tolerates_legacy_invalid_porttask-sdk/tests/task_sdk/definitions/test_connection.pyfrom_json)airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_connections.pytest_post_should_respond_422_for_out_of_range_port(0, -1, 65536, 99999)airflow-core/tests/unit/cli/commands/test_connection_command.pytest_cli_connections_add_rejects_out_of_range_port·test_cli_connections_add_rejects_non_integer_portTest plan
None/1/22/5432/65535 accepted, 0/-1/65536/99999 rejected, response schemas tolerate legacy invalid values,from_jsonaccepts"5432"and rejects out-of-range strings.ast.parse.schema.jsonparses withjson.loads.ast.parse.Connection.__new__(Connection); conn.port = 99999; conn.on_db_load()does not raise (legacy data still loads).breeze testing core-testsrun — requires breeze + Docker, not run locally; will run in CI on this PR.prek run --from-ref mainstatic checks — requires prek hooks installed, will run in CI.Notes for reviewers
ARG_CONN_PORTtype changed fromstrtoint: argparse now rejects non-integer strings at parse time with a clearer error than the downstreamValueErrorfromConnection(...). The model still validates the range.newsfragment(e.g.<pr_number>.bugfix.rst) will be added in a follow-up commit once this PR number is assigned, per the PR template guidance.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Sonnet 4.6 following the guidelines