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

Signed queries

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
javascript, postgresql
領域
api, backend-api-design, security

調査の方向性

この issue では、ファイル、テスト、エントリーポイントが指定されていません。まず既存の query のハッシュ化とストレージの設計を確認し、次に署名付き query、JWT 検証、有効期限、capabilities、ロール処理がプロジェクトに適合するかを判断してください。完了とみなすには、合意された設計と実装範囲が必要ですが、issue ではそれらの基準が定義されていません。

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

説明

enhancement

An idea that may lead nowhere but I had to get it down so we can think/talk about it...

tldr; What if we signed queries instead of/in addition to storing them? It would completely decouple the client build from the server.

If we zoom way out what is the purpose of hashing? Well it serves multiple purposes:

  • It obscures the query from an attacker
  • It is more efficient to send over the wire than a full query
  • It allows us to guarantee provenance

The final one is arguably the most important. It isn't really a problem for an attacker to know what the query is, at least our security defenses shouldn't rely on that fact. And there are other ways to optimize network efficiency. But the most important part of hashing a query is to guarantee provenance.

We've said it many times, but technically you could use a uuid in place of a hash and it would work, because we really just need a way to know we authored the query, not an attacker.

But then we have this problem, we need to store the queries. And we need to do that centrally. And that means hashql is more convenient in some dev workflows than others. If you use microservices, or you have a clear division between frontend and backend, it may not be so simple to store queries in the database at build time. This problem becomes even more difficult the larger the company gets.

But if instead, we signed the hash either with public key encryption, or a shared secret etc, the server could execute queries from remote distributed sources with guaranteed provenance.

We could use JWT's. This would give us a standard format where we could include expiry, capabilities, postgres role information and the query. Then that JWT can be stored directly in the client side build, and sent to the server. The server verifies the signature and the expiry and then executes the query with the encoded role.

You could make quite sophisticated systems in a large company to have complete control over execution and scope. E.g. you could give the marketing frontend team a different secret to an admin dashboard frontend team. And so even if the JWT accesses a table / schema / role that they shouldn't you can easily restrict access.

Another benefit would be, with a standard token format you could ship a standard server module/middleware that consumes these tokens and executes them once verified without any glue code (other than connection details). The JWT can include the role to use, server settings, timeouts, etc. It all comes down to how much you trust the signature, but for a lot of use cases that should suffice.

主要言語
JavaScript
スター
78
フォーク
5
30日以内にマージされた PR はありません

環境構築

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

はじめの一歩

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

porsager/HashQL のほかの issue

porsager/HashQL の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

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

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