refactor(vault-pinning): use the broker and remove NEXT_PUBLIC provider credentials
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 67/100
- issue の種類
- リファクタリング
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- javascript, next.js
調査の方向性
Start by reading the Pinata and Lighthouse adapters in services/*.ts and the vault pinning tests in frontend/tests/vault-pinning.test.mjs; check the broker routes from dependency #45. Update the adapters, tests, and docs, and add the production build credential check. Done means the NEXT_PUBLIC_* reads are removed, build output contains no provider credential, and the vault pinning tests pass against the broker.
索引モデルが issue の本文から書いたものです。
説明
Summary
Point the Pinata and Lighthouse adapters at the broker routes and delete the browser-side credentials.
Estimated size: S
Motivation
Finishes the credential-safety work started by the broker.
Current state in this repo
NEXT_PUBLIC_PINATA_JWTandNEXT_PUBLIC_LIGHTHOUSE_KEYare read inservices/*.ts;frontend/tests/vault-pinning.test.mjssetsNEXT_PUBLIC_LIGHTHOUSE_KEY.
Proposal
- Adapters call the broker routes through
fetch. - Remove the
NEXT_PUBLIC_*reads, update tests and docs. - Add a short upgrade note: any provider key that was ever exposed as
NEXT_PUBLIC_*should be rotated.
Acceptance criteria
-
git grep NEXT_PUBLIC_PINATA NEXT_PUBLIC_LIGHTHOUSEreturns nothing. - The production build output contains no provider credential.
- Existing vault-pinning tests pass against the broker.
Dependencies
- #45
Testing plan
- Update
frontend/tests/vault-pinning.test.mjs; add a build-output check for the credential strings.
Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.
- 主要言語
- Python
- スター
- 2
- フォーク
- 4
- 平均マージ
- 5時間 19分
- マージ済み PR（30日）
- 11
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
QMeshPy/distributed-quantum のほかの issue
-
enhancement good first issue helia storage tier-1
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
QMeshPy/distributed-quantum#53 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments research-spike tier-2
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
QMeshPy/distributed-quantum#78 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments research-spike tier-2
難易度 3/5 1〜2日 初心者へのやさしさ 66/100
QMeshPy/distributed-quantum#77 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments tier-2
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
QMeshPy/distributed-quantum#76 ·
メンテナーはふだん 1 日以内に返信
-
documentation good first issue kubo storage tier-1
難易度 2/5 1〜3時間 初心者へのやさしさ 42/100
QMeshPy/distributed-quantum#75 ·
メンテナーはふだん 1 日以内に返信
QMeshPy/distributed-quantum の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
gramaziokohler/compas_timber#870 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
autowarefoundation/autoware_carla_scenario#500 ·
メンテナーはふだん 1 日以内に返信
-
good first issue priority: low size: XS testing
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
cubrid-lab/cubrid-mcp-server#385 ·
メンテナーはふだん 1 日以内に返信
-
good first issue priority: low size: S testing
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
cubrid-lab/cubrid-cookbook-python#447 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100