Skip to content

fix: Shibboleth SP の属性の受け付けを SP のログインスクリプトからの要求に限る - #1929

Merged
ivis-miyachi merged 2 commits into
develop_v2.1.0from
fix/shib-sp-login-source
Sep 29, 2026
Merged

ivis-miyachi merged 2 commits into
develop_v2.1.0from
fix/shib-sp-login-source

Conversation

@mhaya

@mhaya mhaya commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

概要 (Summary)

  • weko-accounts: Shibboleth SP の属性を受け取る shib_sp_login に、送信元のアドレスを確認するデコレータ shib_sp_source_required を付ける。許可するアドレスは新しい設定 WEKO_ACCOUNTS_SHIB_SP_ALLOWED_ADDRS(既定 127.0.0.1 / ::1)。それ以外は属性を読む前に 403
  • nginx(weko.conf / weko-ams.conf / weko-ams-restricted.conf): location = /weko/shib/login を追加し、GET / HEAD 以外はループバックアドレスからの接続だけを許可する
    • 判定には $realip_remote_addr(real_ip で書き換える前の接続元)を使い、WEKO へ渡す REMOTE_ADDR も同じ値にする。$remote_addr で判定すると、信頼するプロキシのアドレスから X-Forwarded-For にループバックを入れた要求を通してしまうため
  • nginx/login.py / nginx/login.php: 送り先をループバックアドレス(https://127.0.0.1)にし、Host ヘッダに公開ホスト名を入れる(開発環境の docker-compose 向け。k8s の本番は Deployment の hostAliases で公開ホスト名が 127.0.0.1 に解決されるため、従来のスクリプトのままでもループバックで送られる)
  • 背景: SP の属性の受け付けが、SP のログインスクリプト以外からの要求も受け付けていた
  • 挙動の変化: ループバック以外から /weko/shib/login への POST は 403 / GET(ログイン後の確認画面)と他の /weko/shib 配下は従来どおり / SP のログインスクリプトからの POST は従来どおり
  • デプロイ時の注意: 既存環境で nginx の設定だけを更新する場合、ログインスクリプトがループバックで送っていないと Shibboleth ログインが通らなくなる。k8s の本番は hostAliases によりループバックで送っているので、nginx の設定の更新だけでよい

関連Issue / チケット (Related Issues)

  • 非公開(API 台帳とチケットで管理。docs/RULE.md §1 により、番号と修正内容をここで結び付けない)

変更タイプ (Type of Change)

  • 🚀 新機能追加 (Feature)
  • 🐛 バグ修正 (Bug Fix)
  • 🔒 セキュリティ修正 (Security Fix)
  • 🚫 機能のクローズ・非公開化・削除 (Feature Deprecation/Disable)
  • ⚠️ 破壊的変更・データ移行を伴う修正 (Breaking Change / Migration)
  • 📚 仕様書・マニュアル・APIリストの更新 (Documentation)

🤖 0. CI 自動チェック (API Inventory Drift)

PR ごとに WEKO3 コンテナを起動し、url_map のダンプ・台帳との突き合わせ・変更行の
到達可否測定を自動実行する。結果は PR コメントと Actions の artifact
(api-inventory-summary) に出る。

このリポジトリは public のため、台帳もベースラインも同梱していない。
実データはプライベートリポジトリ RCOSDP/weko-secret にあり、CI は Secret 経由で取得する。
以降この文書では、そこを単にプライベートリポジトリと呼ぶ。

台帳はブランチごとに内容が違うため、CI は weko 側と同名のブランチを
プライベートリポジトリから探して使う(head → base → 既定ブランチ の順)。
採用されたブランチ名は PR コメントの冒頭に出るので、件数を読む前にそこを見ること。
対応ブランチが無い場合は既定ブランチと比較され、コメント冒頭に警告が出る。
その件数は当てにならないので、PASS でも「確認済み」と読まないこと。
詳細: tools/api-inventory/ci/README.md §3a

  • CI が PASS している、または FAIL の各項目に対処済み
    • Unit Tests は PASS。API Inventory Drift は PR 作成後に実行中(結果を見て更新する)
      Secret (API_INVENTORY_REPO / API_INVENTORY_SSH_KEY) が未設定のリポジトリ、
      および fork からの PR では、このジョブは何もせずスキップされる。

API を追加・変更した場合(必須)

  • プライベートリポジトリ側の作業ブランチを、この PR のブランチと同名で切った
    • 未作成。経路の追加・削除は無いが、認可の変化を台帳に反映するため、この PR と同名で作成する
      この PR が fix/issue62569 → develop_v2.0.4 なら、プライベート側も
      fix/issue62569 → develop_v2.0.4。同名にしておけば台帳 PR が未マージでも
      CI がそれを見るので、2つの PR のマージ順を気にしなくてよい。
  • プライベートリポジトリの api_snapshot.json を更新し、対応する PR を出した
    • 経路の追加・削除は無い。Drift の結果(認可デコレータの差分)を見て更新する
      export WEKO_API_INVENTORY_DIR=/path/to/weko-secret
      ./install.sh
      python3 tools/api-inventory/scripts/snapshot.py --out "$WEKO_API_INVENTORY_DIR/api_snapshot.json"
      更新しないと CI が落ちる。公開リポジトリのコード変更とは別の PRになる。
  • プライベートリポジトリの weko3_api_list_full.tsv に行を追加・更新し、
    • 行の追加は無い。該当行の所見・対応状況はプライベートリポジトリ側で更新する
      build_checklist.py で 24 列版を再生成した(未収載だと reconcile が FAIL する)
  • 台帳・スナップショット・実測結果をこの公開リポジトリにコミットしていない
    (git status に *.tsv / api_snapshot.json が出ていないこと)

FAIL したときの対処(要約)

まず PR コメント冒頭の台帳ブランチを見る。警告が出ていれば、件数を追う前に
プライベートリポジトリ側の対応ブランチを用意すること(比較相手が違うので件数に意味がない)。

ジョブが落ちる条件は 3 つある。PR コメントのどのセクションに件数が出ているかで切り分ける。

落ちた場所 落ちる条件
ベースラインとの差分 (drift.md) G1〜G7 のいずれかに該当
台帳との突き合わせ (reconcile.md) A + B + C + D + E の合計が 1 件以上
変更行の到達可否測定 (probe) G8 / G9 に該当(結果は artifact に含めないので Actions のログで件数を見る)
検出 意味 対処
G1 / G2 新規経路に認証系デコレータが無い / 認証系デコレータが削除された 実装を直す。意図的な公開なら台帳に根拠を書いてベースライン更新
G3 認証・認可デコレータのコメントアウトが増えた 原則やり直し。残す場合は理由をコード中のコメントに明記する
G4 *_PERMISSION_FACTORY / CSRF 保護 等が危険側の値に変わった 原則やり直し
G5 ModelView の can_delete / can_export が False → True 意図的なら台帳の data_op を更新
G6 静的解析で属性が取れない経路が追加された 台帳に行を追加してレビューする(外部ライブラリ由来など)
G7 依存パッケージの更新で経路が増減した 増えた経路は台帳に追加。消えた経路は行を削除するか allow に登録
G8 台帳で data_op が作成/更新/削除の経路に、未認証で到達した 原則やり直し。意図的な公開なら台帳の根拠を更新。data_op の記載誤りなら台帳を直す
G9 台帳では遮断なのに実測で到達(認可の回帰) 原則やり直し
reconcile A / E 実機にあるが台帳に無い(A: URI 単位 / E: 同一 URI の endpoint 単位) 台帳に行を追加する
reconcile B 台帳にあるが実機の url_map に無い 理由を確認し、正当なら allow に登録する
reconcile C / D メソッド・app 列の記載誤り 台帳を実機に合わせる

reconcile B のうち、実機に存在しないことが正当な行(プラグイン未登録・config で無効等)は
プライベートリポジトリの reconcile_allow.json に理由付きで登録する。理由なしの登録は不可。
登録済みの行は B'(既知・許容)として集計され、E'(endpoint が実機に無い)と併せてゲート対象外になる。

W1〜W6 は WARN でゲートは通るが、レビューでは見ること
(ModelView の追加 / 実装本体の変化 / HTTP メソッド・URL の変化 / 監視対象 config の変化 /
依存パッケージの版の変化)。特に W6(依存の版)は、ベースラインを CI と異なる環境で作ると
毎回出続けて形骸化するため、ベースラインは install.sh で作った環境から生成する。

CI の出力は件数のみ。該当した経路名は Actions には出ないので、プライベートリポジトリ側の
完全版レポート(--summary-only なしで再実行したもの)で確認すること
(このリポジトリは public で、ログ・artifact・PR コメントは誰でも読めるため)。


🔒 1. セキュリティ & API アクセス制御チェック (必須)

認証・認可 (Authentication & Authorization)

  • 新規/変更された Blueprint・View・REST リソースに適切なデコレータ / Permission を設定している
    • 例: @login_required, @pass_record, need(...), Invenio Access Action
    • /api/* では Permission.require(http_exception=403) を使うこと。
      @login_required は API アプリに security.login が無いため 401 ではなく 500 になる
    • CI: G1 / G2 が自動検出(デコレータの有無・削除)
  • 状態変更・破壊的メソッド (POST / PUT / PATCH / DELETE) の権限が正しく制限されている
    • CI: G8 が変更行を未認証で実測(使い捨て環境なので --allow-writes 付きで
      GET / HEAD 以外も叩く)
  • 未ログイン(Anonymous)状態でアクセスした際、意図しないデータ取得・変更が拒絶される
    • CI: G8 / G9 が変更行を実測。ただし測定対象は変更行のみ、かつ既定プロファイルで
      起動した経路のみ。ワークフロー系など未解決プレースホルダの行は skip される
  • 認可を config の permission factory に委ねている場合、None で無効化していない
    • CI: G4 が *_PERMISSION_FACTORY 等を監視

機能クローズ・非公開化の場合 (Feature Disable)

  • UI(画面・ボタン)の非表示だけでなく、バックエンド API(ルーティング・View)も完全に遮断されている
  • 無効化状態で直接 API を叩いた場合、404 Not Found または 403 Forbidden が返ることを確認した

🧪 2. テストコード観点チェック (pytest / Invenio Test Suite)

権限・異常系テスト (Negative & Authorization Tests)

  • 未認証アクセス (Anonymous): トークン/セッションなしのリクエストで 401 Unauthorized または 403 Forbidden / 404 Not Found が返ることを検証するテストがある
  • 権限不足ユーザー (Forbidden): 閲覧権限のみのユーザーが更新/削除 API を叩いた際に 403 になるテストがある
  • 無効化/非公開機能の遮断テスト: 対象機能が無効化されている場合、エンドポイントが 404 / 403 を返すテストがある

境界値・入力バリデーションテスト (Boundary & Validation)

  • 不正なパラメータ(巨大ファイル、異常な MIME タイプ、無効な JSON/XML スキーマ、SQLi/XSS ペイロード等)で適切に 400 Bad Request / バリデーションエラーが返るテストがある

データ整合性・トランザクションテスト (Integrity & Rollback)

  • ファイルストレージ(S3/ローカル)書き込み失敗時や DB エラー時に、中途半端なレコードやゴミファイルが残らずロールバックされるテストがある

🛡️ 3. データ保護 & 破壊的変更防止チェック (Data Safety)

  • 物理削除・上書きの安全性:
    • ファイル・アイテム・メタデータの完全削除/置換処理に、意図しない一括削除や別レコードへの誤適用リスクがない
    • 論理削除、バージョン管理、バックアップ等のロールバック機構が考慮されている
  • トランザクション整合性:
    • DB 更新とストレージ操作がアトミックに管理されている

⚙️ 4. マイグレーション & システム影響チェック (Invenio / WEKO3 Stack)

データベース (DB / Alembic)

  • invenio alembic upgrade(適用)および downgrade(ロールバック)スクリプトを作成・検証した
    • 該当なし(DB の変更なし)
  • 既存データに対する破壊的変更(カラム削除、型変更、NOT NULL 制約追加等)の移行スクリプト/データパッチを用意した

検索インデックス (Elasticsearch / OpenSearch)

  • マッピング定義変更の有無を確認した
    • 確認済み。マッピングの変更なし
  • インデックス再作成(Reindex)やエイリアス切り替え手順を準備・検証した

設定 & 非同期処理 (Config / Celery / Cache)

  • invenio.cfg / 環境変数のデフォルト値を設定した
    • WEKO_ACCOUNTS_SHIB_SP_ALLOWED_ADDRS(既定 ['127.0.0.1', '::1'])を weko_accounts/config.py に追加
  • Celery タスクのシグネチャ変更によるキュー滞留・不整合が発生しない
  • キャッシュ(Redis/Memcached)のパージが必要か確認した

📚 5. ドキュメント・仕様書更新チェック (weko-document)

  • API インベントリ: ツールは本リポジトリの tools/api-inventory/、
    台帳・調査記録はプライベートリポジトリ(public リポジトリには置かない)。
    §0 のチェック項目で対応済みなら、ここは確認のみ。
    • エンドポイントの追加・変更・廃止、メソッド、認証・認可要件、リクエスト/レスポンス仕様を更新した
    • 調査記録(weko3_api_auth_findings.md)もプライベートリポジトリに置く。台帳は二重管理しない
  • WEKO3 機能仕様書:
    • 対象機能の仕様追加・変更・クローズ(非公開化)内容を反映した
  • 各種マニュアル (管理者 / 利用者マニュアル):
    • 画面導線・操作手順・権限仕様の変更を反映した
  • 更新不要な場合(理由): API の仕様(経路・パラメータ・応答形式)は変わらない。受け付け元の制限は API 台帳(プライベートリポジトリ)で更新する。運用手順(nginx 設定の更新)は本 PR の概要のデプロイ時の注意を参照

📋 6. 動作検証エビデンス (Verification Evidence)

テスト実行結果

weko-accounts  tests 全103件 passed
  (許可されない送信元は属性を読む前に 403、許可するアドレスが設定に従うこと、を追加)
nginx(ビルド済みイメージにこの設定を載せ、本番と同じ real_ip の設定で確認):
  信頼するアドレスからの POST                         403
  同上 + X-Forwarded-For: 127.0.0.1                  403
  同上 + X-Forwarded-For: 127.0.0.1, 203.0.113.5     403
  信頼するアドレスからの GET                          200
  ループバックからの POST(ログインスクリプトと同じ経路) 200, REMOTE_ADDR=127.0.0.1
  ループバックからの POST + X-Forwarded-For           200, REMOTE_ADDR=127.0.0.1
  nginx -t: weko.conf / weko-ams.conf / weko-ams-restricted.conf いずれも ok
GitHub Actions Unit Tests / UI Tests  success

CI の成果物 (artifact: api-inventory-summary)

ファイル 内容
drift.md ベースラインとの差分(件数のみ)
reconcile.md 台帳と実機の突き合わせ(件数のみ)

明細(該当した経路名・実測結果)は公開できないため artifact に含めていない。
プライベートリポジトリ側で同じコマンドを --summary-only なしで実行して確認する。

手動で確認したこと

  • 比較として、$remote_addr で判定する設定では、信頼するアドレスから X-Forwarded-For: 127.0.0.1 を付けた POST が通ってしまうことを確認した(そのため $realip_remote_addr で判定している)
  • 未確認: 実際の Shibboleth ログイン(IdP → SP → ログインスクリプト → WEKO)の通し確認

🤖 Generated with Claude Code

Summary by Sourcery

Restrict Shibboleth SP attribute submissions to trusted loopback or configured source addresses.

Bug Fixes:

  • Restrict Shibboleth SP attribute intake to requests originating from configured trusted addresses, preventing unauthorized requests from supplying identity attributes.

Enhancements:

  • Align nginx routing and login scripts to use the connection's loopback address for Shibboleth login posts while preserving the public host via the Host header.
  • Use the pre-real-IP connection address for nginx and WEKO authorization checks to prevent spoofed X-Forwarded-For values from bypassing the restriction.

Tests:

  • Add coverage for rejecting disallowed Shibboleth sources before attribute parsing and honoring configured allowed addresses.

mhaya and others added 2 commits September 28, 2026 23:11
SP の属性は、Web サーバ上のログインスクリプト(secure/login.py, login.php)が
WEKO へ送る。その受け付けを、送信元のアドレスで限定する。

- weko-accounts: 受け付けるアドレスを WEKO_ACCOUNTS_SHIB_SP_ALLOWED_ADDRS
  (既定 127.0.0.1 / ::1)に限るデコレータを付ける。それ以外は 403
- login.py / login.php: 送り先をループバックアドレスにし、Host ヘッダに
  公開ホスト名を入れる
- nginx: /weko/shib/login への GET 以外をループバックアドレスからだけ許可する
  (weko.conf / weko-ams.conf / weko-ams-restricted.conf)

既存の環境では、login.py / login.php と nginx の設定を同時に更新すること。
どちらかだけでは Shibboleth ログインが通らなくなる。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
real_ip は信頼するプロキシ(プライベートアドレス)からの接続について
X-Forwarded-For で $remote_addr を書き換える。そのため $remote_addr で
ループバックかを判定すると、信頼するアドレスから X-Forwarded-For に
ループバックを入れた要求を通してしまう。

/weko/shib/login の判定を $realip_remote_addr(書き換える前の接続元)で
行い、WEKO へ渡す REMOTE_ADDR も同じ値にする。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sourcery-ai

sourcery-ai Bot commented Sep 29, 2026 •

Copy link
Copy Markdown

Reviewer's Guide

Shibboleth SP 属性の受け付けをログインスクリプト由来のリクエストに限定するため、アプリケーションと nginx の双方で送信元を検証し、スクリプトはループバック経由で POST するよう変更しています。

Sequence diagram for restricted Shibboleth attribute submission

sequenceDiagram
    participant SP as ShibbolethLoginScript
    participant N as Nginx
    participant W as WEKO

    SP->>N: POST /weko/shib/login via 127.0.0.1
    N->>N: Check request_method and realip_remote_addr
    alt Loopback POST
        N->>W: Forward request with REMOTE_ADDR=127.0.0.1
        W->>W: shib_sp_source_required
        W->>W: Read Shibboleth attributes
        W-->>SP: Login response
    else Non-loopback POST
        N-->>SP: 403 Forbidden
    end
Loading

Flow diagram for Shibboleth login request authorization

flowchart TD
    A[POST /weko/shib/login] --> B{Method is GET or HEAD?}
    B -->|Yes| C[Forward to WEKO]
    B -->|No| D{realip_remote_addr is 127.0.0.1 or ::1?}
    D -->|No| E[403 Forbidden]
    D -->|Yes| F[Forward with REMOTE_ADDR=realip_remote_addr]
    F --> G{request.remote_addr is allowed?}
    G -->|No| E
    G -->|Yes| H[Read Shibboleth attributes]
Loading

File-Level Changes

Change Details Files
Shibboleth SP 属性を送信元アドレスで二重に制限する認可を追加
  • 許可アドレス設定(既定は IPv4/IPv6 ループバック)を追加
  • 属性解析前に許可リスト外のリクエストを 403 で拒否するデコレータをログインエンドポイントへ適用
  • 許可・拒否時の属性解析呼び出しを検証するテストを追加
modules/weko-accounts/weko_accounts/config.py
modules/weko-accounts/weko_accounts/utils.py
modules/weko-accounts/weko_accounts/views.py
modules/weko-accounts/tests/test_views.py
nginx で Shibboleth ログイン POST の接続元をループバックに限定し、WEKO に同じ接続元を渡す構成へ変更
  • 完全一致の /weko/shib/login location とメソッド別の拒否マップを追加
  • real_ip 書き換え前の $realip_remote_addr で判定し、REMOTE_ADDR として uWSGI へ渡す
  • GET/HEAD と既存の /weko/shib 配下の挙動を維持
nginx/weko.conf
nginx/weko-ams.conf
nginx/weko-ams-restricted.conf
Shibboleth ログインスクリプトの送信先をループバックへ変更し、公開ホスト名を Host ヘッダで維持
  • Python/PHP スクリプトから 127.0.0.1 のログインエンドポイントへ POST
  • 元の公開ホスト名を Host ヘッダに設定して開発環境の名前解決変更に対応
nginx/login.py
nginx/login.php

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@coderabbitai

coderabbitai Bot commented Sep 29, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: c8a5972e-f6af-4a50-a469-c686468e79e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Needs a human reviewer. This changes the authentication trust boundary: any request accepted from an allowed address can supply Shibboleth attributes that determine the logged-in user, so an incorrect address or proxy configuration could permit account impersonation from the moment it ships. Reverting removes the new check and routing, but cannot undo any authenticated actions performed while a forged identity was accepted.


Sourcery is free for open source - if you like our reviews please consider sharing them ✨

@qodo-code-review

Copy link
Copy Markdown

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

@github-actions

Copy link
Copy Markdown

API インベントリ差分(件数のみ)

台帳ブランチ: develop_v2.1.0

明細は公開できないため件数のみ表示しています。該当箇所はプライベートリポジトリ側の台帳・レポートで確認してください。

ベースラインとの差分

API インベントリ差分レポート

  • 旧: b572c442d v2.0.4-577-gb572c442d (profile=default) endpoints=933 (外部ライブラリ由来 359)
  • 新: 834c9fb78 v2.0.4-611-g834c9fb78 (profile=default) endpoints=933 (外部ライブラリ由来 359)

判定: ✅ PASS (FAIL 0 / WARN 0)

サマリ

分類 件数
ADDED 0
REMOVED 0
RULE_CHANGED 0
METHODS_CHANGED 0
AUTH_CHANGED 1
IMPL_CHANGED 0
ATTRS_UNKNOWN_NEW 0
ModelView 追加 0
ModelView 削除 0
ModelView フラグ変化 0
config 変化 0
コメントアウト認証の増加 0
依存パッケージの版変化 0

変化はありません。


台帳との突き合わせ

スナップショット ↔ インベントリ 突き合わせ

  • リビジョン: 834c9fb78 v2.0.4-611-g834c9fb78 経路URI=913
  • 台帳: 行=1053 URI=924

件数のみ。詳細はプライベートリポジトリ側の完全版レポートを参照。

判定: ✅ 一致 (0件)

検出 件数
A. インベントリ未収載(抽出漏れ) 0
B. 実機に無い(未説明) 0
B'. 実機に無い(既知・許容) 11
C. メソッド不一致 0
D. app列の不一致 0
E. endpoint 未収載 0
E'. endpoint が実機に無い(参考) 1

ソース由来の経路検知

ソース由来の経路検知

  • 解析対象: /home/runner/work/weko/weko
検知源 件数
route 286
expose 206
add_url_rule 75
rest_config 28
modelview 23
entry_point 115
計 733

判定: ✅ 全検知が台帳に対応 (0件)

検知源 検知 台帳に対応 未収載 既知・許容
route 286 286 0 0
expose 206 206 0 0
add_url_rule 75 71 0 0
rest_config 28 26 0 2
modelview 23 23 0 0
entry_point 115 115 0 0

add_url_rule(**rule) 形式の config 駆動一括登録が 4 箇所。個々の経路は rest_config 側で検知する。

参考: 静的検知と結びつかなかった台帳行

  • 全体: 170 / 1053 行
  • うち実ファイルを持つ行: 24(pip・framework・ModelView 総称表記を除いた数)

@ivis-miyachi
ivis-miyachi merged commit c0ecb36 into develop_v2.1.0 Sep 29, 2026
158 of 159 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants