Bundle: checker lists of one service defined in two configurations are merged by position, and a checker is silently lost

オープン
  • 何か問題がありますか？
#758 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
php, symfony
領域
backend, security

調査の方向性

Start by reading the configuration tree definitions for checker aliases, algorithm lists, and serializer lists, then trace how ConfigurationHelper merges configuration from multiple sources. Reproduce the issue with the supplied when@prod configuration and compare debug:config jose checkers across environments. Done means repeated configuration preserves all intended checkers without accidental duplicates, while algorithm and serializer lists retain the safer last-list semantics described in the issue.

索引モデルが issue の本文から書いたものです。

説明

bug
Version(s) affected

All released versions (3.4.x, 4.0.x, 4.1.x, 4.2.x), and the 4.3.x and 5.0.x branches.

Description

The bundle declares its lists of checker aliases with useAttributeAsKey('name'). When the jose configuration of one service comes from more than one place (a when@<env> block, a second file such as config/packages/prod/jose.yaml, or another bundle using ConfigurationHelper), Symfony merges two lists that carry a key attribute key by key. A YAML sequence is keyed by position, so the second list overwrites the first one index by index.

jose:
    checkers:
        claims:
            api:
                claims: ['exp', 'iat', 'nbf']

when@prod:
    jose:
        checkers:
            claims:
                api:
                    claims: ['aud_api']

In prod, jose.claim_checker.api is built from ['aud_api', 'iat', 'nbf']. The expiration check is gone there, while it runs in dev and test. The container compiles without any warning. The typ list of a header checker manager has no key attribute and is appended, so one manager definition merges its two lists in two different ways.

Lists concerned:

  • checkers.headers.<name>.headers, checkers.claims.<name>.claims
  • jws.loaders.<name>.header_checkers, jwe.loaders.<name>.header_checkers
  • nested_token.loaders.<name>.jws_header_checkers and jwe_header_checkers
  • on 4.3.x, selective_disclosure.verifiers.<name>.header_checkers, key_binding_header_checkers and claim_checkers

The algorithm and serializer lists are declared the same way: ['RS256', 'HS256'] followed by ['ES256'] gives ['ES256', 'HS256'].

A checker added to a manager by another bundle through ConfigurationHelper::addHeaderChecker() or addClaimChecker() is lost the same way when the application also configures that manager.

Applications that configure each service in one place are not affected. Where a service is configured in two places with lists meant to add up, a check written in the configuration does not run in the environment that has the second configuration, and the tokens it would reject are accepted there.

How to reproduce

Configure the same checker manager in a when@prod block as above, then compare bin/console debug:config jose checkers --env=dev with --env=prod.

Possible Solution
  • Remove useAttributeAsKey('name') from the checker alias lists, so that a second configuration adds checkers and never removes one, and drop duplicate aliases after the merge (ConfigurationHelper prepends a copy of the first jose configuration, so the same alias can be seen twice).
  • For the algorithm and serializer lists, appending would widen what a service accepts: performNoDeepMerging() (the last list wins) is the safer semantics there.
  • Changelog: a second list now adds to the first one instead of overwriting it by position. This can only add checks, but tokens accepted before may be rejected after the upgrade.
  • Once the lists add up, one manager can receive two checkers for the same claim or header parameter, which #756 is about.
Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-TNDTH33Z).

主要言語
PHP
スター
954
フォーク
119
平均マージ
48分
マージ済み PR（30日）
17

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

web-token/jwt-framework のほかの issue

web-token/jwt-framework の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。