shahar1 opened a new pull request, #69706:
URL: https://github.com/apache/airflow/pull/69706
## Summary
Upgrades Flask-AppBuilder from `5.2.1` to `5.2.2` (latest on PyPI, released
2026-06-23). Follows the same shape as #66841.
## What 5.2.2 changes and how it maps to Airflow
FAB 5.2.2 carries four security-relevant fixes to the security manager
(parts of which Airflow vendors in `override.py`) plus a dependency-cap change:
| FAB 5.2.2 change | Airflow impact |
|---|---|
| **#2465** — raise Flask-Limiter upper bound `<4` → `<5` | Unblocks
Flask-Limiter 4.x. Airflow's own pin stays `>3`; `uv lock` keeps the resolved
version at **3.12** (minimal resolution), so this PR does not actually move
Flask-Limiter. See compatibility note below. |
| **#2469** — escape LDAP filter metacharacters in `_search_ldap` |
**Already present** in `override.py` (Airflow was ahead — it also validates
balanced parentheses). No change. |
| **#2435** — `add_register_user` uses `uuid4` instead of `uuid1` |
**Already present** in `override.py`. No change. |
| **#2470** — anchor OAuth email-whitelist regex to end of string | Lives in
FAB's `AuthOAuthView.oauth_authorized`, which Airflow's `CustomAuthOAuthView`
calls via `super()`. **Inherited automatically.** No change. |
| **#2468** — warn when Azure OAuth JWT signature verification is disabled |
See follow-up below. |
No new **public** FAB security-manager methods were added, so
`test_fab_alignment.py` passes with only the `EXPECTED_FAB_VERSION` bump.
## Flask-Limiter compatibility note
FAB lifting its cap merely *unblocks* Flask-Limiter 4.x; `uv lock` keeps
3.12. To be safe I verified Airflow's vendored Flask-Limiter usage in
`providers/fab/src/airflow/providers/fab/www/security_manager.py` against
Flask-Limiter **4.1.1**:
- `from flask_limiter import Limiter` and `from flask_limiter.util import
get_remote_address` — both still valid (4.0 prefixed *internal* submodules with
`_`, but `util` remains public).
- `Limiter(key_func=...)`, `limiter.init_app(...)`, and `limiter.limit(...)`
with all the kwargs Airflow passes (`per_method`, `methods`, `error_message`,
`exempt_when`, `override_defaults`, `deduct_when`, `on_breach`, `cost`) — all
present in 4.1.1.
So even if a future resolution picks Flask-Limiter 4.x, no vendored-code
change is required.
## Changes
- `providers/fab/pyproject.toml` — `flask-appbuilder==5.2.1` → `==5.2.2`
-
`providers/fab/tests/unit/fab/auth_manager/security_manager/test_fab_alignment.py`
— `EXPECTED_FAB_VERSION` → `"5.2.2"`
- `uv.lock` — re-resolved (flask-appbuilder only; Flask-Limiter stays 3.12)
- `generated/provider_dependencies.json` (+ `.sha256sum`),
`providers/fab/README.rst`, `providers/fab/docs/index.rst` — regenerated by
prek (the docs-index regeneration also dropped a stale release-time-only tail
block that had drifted on `main`)
## Validation
- `test_fab_alignment.py` — all 7 alignment tests pass with
`flask-appbuilder==5.2.2` installed.
- `providers/fab/tests/unit/fab/auth_manager/security_manager/` — all 40
unit tests pass.
- `override.py` and the vendored `www` security manager import cleanly under
FAB 5.2.2.
- Full `pre-commit` prek stage green.
## Follow-up (not in this PR)
FAB #2468 adds a `log.warning` when Azure OAuth JWT signature verification
is disabled. Airflow's `_decode_and_validate_azure_jwt` deliberately deviates
from FAB (manual base64 payload decode; `verify_signature` defaults to
`False`), and FAB's warning text references FAB's own roadmap ("a future major
release will change the default to `True`"), which doesn't fit Airflow's
deviation. Whether Airflow should emit its own equivalent warning — arguably
more important here since verification is off by default — is a behavioral
security change that belongs in a focused change, not this dependency bump.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Opus 4.8)
Generated-by: Claude Code (Opus 4.8) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
