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

今日のコード

汚くてもどんどん書いていこう

ws chat server

ws chat client