Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

feat(vault): server-side pinning broker routes

オープン
#45 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
54/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
next.js, typescript
領域
api, backend, security

調査の方向性

Start by locating the existing /api/vault/pin* and /api/vault/quota/* route handlers, the session authentication and user-scoping code, and the Pinata and Lighthouse service adapters. Then read the route handler tests and run them to understand the current conventions. Done means adding authenticated broker routes for pin, unpin, and quota, with mocked-provider tests for success, auth, size limits, and typed errors that do not leak tokens.

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

説明

enhancement helia storage tier-2

Summary

Add session-authenticated routes that perform pin, unpin and quota calls to Pinata and Lighthouse on the server, so provider credentials never reach the browser.

Estimated size: M

Motivation

Provider tokens are currently shipped to every browser as NEXT_PUBLIC_* variables.

Current state in this repo

  • services/pinata.ts reads NEXT_PUBLIC_PINATA_JWT and services/lighthouse.ts reads NEXT_PUBLIC_LIGHTHOUSE_KEY in the browser.
  • /api/vault/pin* and /api/vault/quota/* only record audit data; they do not call the providers.

Proposal

  • Add /api/vault/broker/pin, /unpin and /quota route handlers, authenticated with the existing session and scoped to the user.
  • Read credentials from server-only env vars (for example PINATA_JWT, LIGHTHOUSE_API_KEY); choose the provider by request parameter.
  • Enforce a request body size limit and basic rate limiting.
  • Additive only: leave the browser adapters untouched in this PR (they switch over in the follow-up).

Acceptance criteria

  • Unauthenticated requests get 401.
  • A pin, unpin and quota call succeeds through the broker against mocked providers.
  • No provider secret is read from a NEXT_PUBLIC_* variable on the broker path.
  • Errors from the provider are mapped to typed responses without leaking tokens into logs.

Out of scope

  • Switching the browser adapters over (separate issue).
  • New providers.

Dependencies

  • None; can be picked up independently.

Testing plan

  • Route handler tests with mocked provider HTTP; auth and size-limit cases.

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
平均マージ
6時間 54分
マージ済み PR(30日)
7

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

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

QMeshPy/distributed-quantum のほかの issue

QMeshPy/distributed-quantum の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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