Bundle: an application service tagged with an alias the bundle already uses is replaced by the bundle's service

Đang mở
#769 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
backend, devtools

Hướng nghiên cứu

Start with HeaderCheckerCompilerPass, ClaimCheckerCompilerPass, and AlgorithmCompilerPass, then trace how their factories register aliases. Check how duplicate aliases from one service differ from aliases claimed by different services, and review the compatibility plan for the 4.3.x and 5.0.x branches. Done means duplicate claims are reported with both service names while repeated tags from the same service remain accepted, with the stated deprecation and exception behavior documented.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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; for header checkers since 3.0.6.

Description

HeaderCheckerCompilerPass, ClaimCheckerCompilerPass and AlgorithmCompilerPass emit one add($alias, $service) call per tag. The factory keeps the last service added under an alias, and the passes never check whether the alias is already taken. The application's services are defined before the bundle's, so an application service tagged with an alias that the bundle also uses (exp, iat, nbf, or an algorithm name such as RS256) is replaced by the bundle's own service, and the container compiles without any message. A service tagged by a bundle registered after JoseFrameworkBundle wins instead: the load order decides.

Example: the bundle has no option for the $protectedHeaderOnly argument of its time checkers, so the application declares its own checker:

services:
    app.protected_exp_header_checker:
        class: Jose\Component\Checker\ExpirationTimeChecker
        arguments: { $clock: '@Psr\Clock\ClockInterface', $protectedHeaderOnly: true }
        tags:
            - { name: 'jose.checker.header', alias: 'exp' }

jose:
    checkers:
        headers:
            api: { headers: ['exp'] }

jose.header_checker.api holds the bundle's ExpirationTimeChecker, whose protectedHeaderOnly() is false: a JWS in a JSON serialization that carries exp only in its unprotected header passes check($jws, 0, ['exp']). Under any other alias, the application's checker is used and that token is refused. Claim checkers behave the same way, and an algorithm service built with other constructor arguments and tagged with its standard name is replaced by the bundle's default instance in every loader, decrypter and builder.

Before 0.2.0 the factories refused an alias that was already registered (The alias "%s" already exists.).

How to reproduce

Boot a kernel with the configuration above and compare $container->get('jose.header_checker.api')->getCheckers()['exp']->protectedHeaderOnly() (false) with the same configuration where the tag alias is exp_protected and the list says ['exp_protected'] (true).

Possible Solution
  • Workaround: use an alias of your own, as the documentation does for custom checkers and algorithms, or redefine the bundle's service under its own id (the class name, e.g. Jose\Component\Checker\ExpirationTimeChecker).
  • In the three compiler passes, report an alias claimed by two different services, naming both; one service tagged twice with the same alias stays accepted.
  • As for #756: a deprecation in 4.3.0 and an exception in 5.0.0, since containers that compile today with a duplicated alias, including deliberate overrides by a later bundle, would otherwise stop compiling.
  • Document that aliases are unique, and how to replace a service of the bundle.
Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-635NQ9DS). Companion to #756 (one checker per name in a manager). AlgorithmManager likewise keeps only the last algorithm of a given name, without notice.

Ngôn ngữ chính
PHP
Star
954
Fork
119
Merge trung bình
48 phút
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của web-token/jwt-framework

Tất cả issue của web-token/jwt-framework

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.