Bump flask-appbuilder to 5.2.2

[shahar1]

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?

• Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines