Progress作業メモ
TODO
- 認証token発行API、hapi
- token認証をチャットサーバーに追加、ws
- ルーム機能をつくる、ws
認証token発行API
昨日できていたらしい
token認証をチャットサーバーに追加
token認証できた
ルーム機能
今の実装は、毎回jwtをdecodeする必要があるけど、jwtそのものをキーとしてhashを作ればその必要はなくなる。以下の様なユーザーリストを保持。
明日以降のTODO
- 画面の簡単なデザイン
- angular.jsでチャット画面
- angular.jsでProgressの実装
users {
token1: {
user: userName,
room: roomNo,
ws: ws
},
token2: {
user: userName,
room: roomNo,
ws: ws
}
}
また、room別のユーザーリストも別途作るようにする。
rooms {
room1: {
users : [
{
user: userName,
ws: ws
},
{
user: userName,
ws: ws
}
]
},
room2: {
...
}
}
これでOK! これらのhashは特にredisに持たせる必要はない。serverが落ちるとコネクションも全て切れるので、hashはサーバーと同じ寿命があれば良い。
wsserver.js
apiserver.js
Progress作業メモ
TODO
- wsチャットサーバ、ws
- 認証token発行API、hapi
- token認証をチャットサーバーに追加、ws
wsチャットサーバ
- webにあるサンプルみたいなのはできた。
- wsの認証&idとconnectionのhashをどこで作るか考えた。
パフォーマンス的には、handleUpgrade()をoverrideするのが良いと思った。ただ大変そうなので、カスタム認証用に用意されているverifyClient()に書けばいい。と思ったら、verifyClient()が呼ばれる段階では、connection(コード上はclient)が作られてない。なので結局、'connection'eventで拾う。まとめ。認証はverifyClient()に書く。idとconnectionとのhashは、'connection'イベント処理に書く。
Handshakeリクエスト時にブラウザ上のjsが変更できるHTTP Headerは、resource-name/pathと、WebSocket-Protocolだけらしい。酷い。tokenは、WebSocket-Protocolに突っ込むのがいいのか、parameterとして送るべきか。大差ない。どっちでも送れた。やった。
明日以降TODO
- 認証token発行API、hapi
- token認証をチャットサーバーに追加、ws
- ルーム機能をつくる、ws
今日のコード
汚くてもどんどん書いていこう