OAuth 2.0で認証してみた。

まずOAuth 2.0は認可フレームワークで認証は直接サポートされない。 だけどユーザー属性参照への認可(アクセストークン)で似たことができる。

実装が簡単なためOAuth 2.0で定義されているAuthorization Code Grantを利用して認証をする人が増えた。 これは野良ハックであって認証として合意は取られていない。 なので認証としての機能拡充や仕様として整理するためにOAuth 2.0上の認証機構OpenID Connect 1.0が定められた(と思われる)。

OpenID Connect 1.0のクライアントは利用するだけなら簡単との事だけど仕様を理解するのにだいぶ時間が掛かりそうだったので OAuth 2.0のハック版の認証を試してみた。

Authorization Code GrantにはセキュリティリスクがありRFC7636で対策が策定されている。 だけどgithubのドキュメントで対応を見つけられず今回は実装していない。

続きを読む

tty をブラウザ経由で利用できるツールはいくつか存在する。 Go実装のyudai/gottyを試してみた。 とてもシンプルで簡易で何かするのに使うくらいだと思われる。

あとからfork版のyubo/gottyを見つけた。 こっちは機能が豊富でパッケージ化も進んでいて扱いやすそう。

続きを読む

GoにExample functionテストがあるの知らなかった。

とりあえずExampleXXXX() って関数名で使える。 キーワードはOutput:, Unordered output: って2つのコメントになる。

ドキュメントによるとExampleテストの関数名で対応する関数やメソッドを解決してGodocのExampleに掲載してくれるらしい。

続きを読む

context について調べたので試しにos.Signal を受け取るとキャンセルを実行するcontext.WithCancelBySignal()を作った。

書いてから振り返るとcontext はトランザクション単位で用いるがos.Signal はプロセス全体に関わるため概念が一致しづらい。 exec.CommandContext()SIGKILL を飛ばしてしまうので子プロセスは直ちに死ぬ。そのままでは使えず相性が悪い。 ただ作ったのでとりあえず残す。

続きを読む

勉強したことのメモ。

context はv1.7から標準パッケージに含まれている。 関連処理をgoroutinによって非同期に実行する事が多いGo言語では対象トランザクションに関連した処理に対して横断的な制御をするのに苦労する。 context パッケージがインタフェースを整えてくれる。

現在は主に2つの機能を提供している。

  • トランザクションの属性情報を共有
  • タスク間の依存関係をツリーを管理(キャンセル(完了)を下流に伝搬させる)

主に、キャンセル通知の伝搬経路としてcontext を捉えると考えやすい。 キャンセル対象は何でキャンセルされず実行するのは何かを分類するとcontext の親子関係のデザインが固まると思う。

またトランザクションは複数プロセス・ホストに関わることもある。 os/execCommandContext()net/httpRequest.WithContext() などがプロセスに閉じこもらないトランザクションの挙動やキャンセル処理に貢献している。 当然だけどプロセスが異なる場合はキャンセル処理を親側が実施する事で伝達されるがcontext のインタフェースとして伝達されるわけではない。

属性情報の共有の方針は賛否両論な2通り出てくると思っている。

  • トランザクション単位の情報(request_id など)を横断的に共有する場合にcontext に含めて持ち回る
  • http.Request をラップしたリクエストやインプットを引数としてドメインレイヤーに渡す

一般的にはinteface{} を嫌うのでデータを入れることは避けられると思われる。 なので気軽にアプリケーションに閉じ込める場合はcontext を利用するよりリクエスト構造体を利用する方が好まれると考えている。

ログ用の情報などアプリケーションと関連しない一般的な横断情報とは何かの合意が取れたり慣例が貯まれば、 ミドルウェアやフレームワークがhttp.Request をラップせず標準ライブラリと同レベルの抽象化を維持できるためcontext に寄せた実装も少しずつ出てくると想像している。

その場合contextをフレームワークやライブラリが利用する構造体にラップすることでユーザーはinteface{} を直接触らない様に提供されるのが原則になると想像している。 どちらの方針を取るにしても、バックエンドへのクライアントなどサービス機能についてcontext とは役割が違うので入れるべきではない。

続きを読む

分散システムを自分で設計・実装できるようになりたいので基本的な分散アルゴリズムを勉強したり実際に書いてみることにした。 教科書に従って書いていて、用語などの前提には触れずメモを残すだけなので読むの辛いと思う。

tl;dr

DHT(Distributed Hash Table)を実現する代表的なアルゴリズムであるChordを実装してみた。

DHTっていうのは構造化オーバーレイネットワークの1つで多数の分散したノード上にハッシュテーブル(set, get)を提供するシステムを指す。 Chordはそのようなサービスを提供するアルゴリズムの1つで、ノードのアドレスとデータのキーを同一のS1集合へ射影することで資源探索を行う。 またノード数Nに対してリソース提供ノードを確定するのに必要なノード数をO(logN) にするように経路表を維持している。

多数のノードがつながりリングが形成されている (ピンク: succ, 青: pred, 点線: fingers)

とりあえず実装したのはRendezvous, Location, Routingのロジック部分で実際の通信やKVSサービスは実装してない。 簡単なコードのテストは書いたが複雑な部分はシナリオを通過したノードがどのようにつながっているかdot形式で出力して可視化した。 論文の他に教科書(Distributed Computing)も参考にした。 詳しい解説スライドも読みました。

続きを読む

プロフィール画像

Masumi Kanai

quantum mechanism and exact-WKB
news site
distributed storage
stream processing

software engineer

Japan