haushinka2dx / atmosphere

atmosphere

atmosphere is a asynchronous communication service.

Requirements

• vert.x : 2.0.1.final or higher
• MongoDB : 2.4.1 or higher

Usage

1. Install Vert.x
2. Install mongoDB
3. Clone this repository. git clone https://github.com/haushinka2dx/atmosphere.git path-to-install
4. Change settings. Settings are written in path-to-install/main/core/constants.js
   1. Security facts
      • encryptionPassword : set not simple string
      • encryptionIV : set not simple string
      • encryptionSalt : set not simple string
      • adminUserId : set anything you want
      • adminPassword : set not simple string
   2. Environment facts
      • restAPIHostname : set if you need.
      • restAPIListenPort : set if you need.
      • streamingHostname : set if you need.
      • streamingListenPort : set if you need.
      • persistorHostname : set hostname that mongod is running.
      • persistorPort : set mongod's port number.
      • persistorDbName : set mongod's database's name if you need.
   3. General facts
      • sessionTimeoutMilliseconds : set appropriate time. Default is 5 minites, this is too short for almost cases.
      • authTimeoutMilliseconds : set appropriate time. Default is 5 minites, this is too short for almost cases.
5. Move directory cd path-to-install
6. Run atmosphere ./start.sh

Run Spec(Run Test)

• cd {repository_root}
• Execute a command. ./run-spec.sh

APIs

See wiki page

atmosphere's Issues

Where should the escape logic be executed? Server? Client? Both??

Now, I'm going to add Self-Introduction to user information.
This information is changed by user, so any characters can be included.
And this information is shown in Browser, App, and so on DIRECTLY.

If Self-Introduction contains special characters( html tag, javascript, ...) and show this directly, this is very dangerous(security hole). This problem should be solved.

I think there are two method to solve this problem:

1. Escape information by Server
2. Escape information by Client(Web, App, and so on)

1 is very usefull and sefety, but special characters are various(differ to each client devices). If the device was added, Server's escape logic must be changed.

2 remains security risks, but server should not implement the logic against each client devices.

How do you think?

I currently think 2 is better.

jquery.uploadに対するレスポンスmime-typeをtext/htmlにする

コードを読む限りレスポンスのmime-typeは基本的にapplication/jsonだと思います。
https://github.com/haushinka2dx/atmosphere/blob/vertx2/main/net/http/request_info.js#L339

しかしjquery.uploadでjson指定した場合、mime-typeはtext/htmlにする必要があります。

Note: xml、html以外を指定する場合、ブラウザによってはダウンロードダイアログが表示されてしまうことがあるため、レスポンスのmime-typeをtext/htmlとしてください。
http://lagoscript.org/jquery/upload/documentation

アバター画像変更(changeAvator)では特にmime-typeを上書きはしていないように見えました。
なので修正するのが良いと思います。
ベタ書きでmime-typeを書き換えるか、クライアントから指定できるようにするかなどは考えどころですが。

致命的じゃないので備忘も兼ねてissueに上げておきます。

Conversation timeline API or Search messages API

会話的な流れのメッセージを取得する方法として以下の２つが考えられる。

1. 専用のAPIを用意する
   • メッセージのIDを渡す
   • 以下のメッセージを返す
     • そのメッセージが返信した対象の一連のメッセージ（つまり祖先）
     • そのメッセージに対しての返信のメッセージ（つまり子孫）
2. Search Messages API を使用
   • そのメッセージが返信した対象の一連のメッセージ（つまり祖先）はメッセージの reply_to プロパティの値で検索APIを使って取得
     ** ただし、一度に１つのメッセージしか取得できないので再帰的にAPIを呼び出す必要がある
   • そのメッセージに対しての返信のメッセージ（つまり子孫）は対象のメッセージIDを検索APIを使って取得
     ** ただし、一度に１つのメッセージしか取得できないので再帰的にAPIを呼び出

つまり、サーバー側でやるかクライアント側でやるかということになるんだが、データの持ち方的にどうしても何度も問い合わせが必要になるので、サーバー側でやるのは微妙か？

Implements APIs of Response category

Implements below APIs:

• /messages/respond
• /announce/respond
• /private/respond

Using each APIs, the user respond other favored, usefull, read it later, and so on.

POSTのデータがJSONである理由

今更ですが、POSTのデータがJSONになっている理由って何故でしょうか。

例えばauth/loginはuser_idとpasswordが必要ですが次のようにはならず、

{ user_id: 'admin', password: 'admin' }

次のようになります。

{ '{"user_id": "admin", "password": "admin"}': '' }

(注:node上の出力)

curlの例でいうと、こうではなくて

curl http://localhost:9999/auth/login -X POST -d "user_id=bob" -d "password=bob"

こうしないといけない

curl http://localhost:9999/auth/login -X POST -d '{"user_id": "admin", "password": "password"}'

サーバー側がJSONで処理したいところまでは分かりますが、
通常のPOSTデータを受け取ってサーバー内でJSONに変換して処理を進めるのではなく、
クライアント側がJSONを送る理由って何だろうなと思いまして。

きっかけとしては、nodeのポーティング周りで前者の方が都合いい場面があったので 😉
(後者の場合はまずやり方を考えるand調べないといけない)

Encrypt password

Enhance security of password. However the method of encryption is not determined.

References

• http://d.hatena.ne.jp/penult/20120612/1339515650
• http://webos-goodies.jp/archives/how_to_use_goog_crypt.html
• http://blog.f-secure.jp/archives/50668446.html
• http://pajhome.org.uk/crypt/md5/sha512.html

util系のjsライブラリを使いたい気がします

underscore.jsとかのutilライブラリを使うといいんじゃないかなーと思いました。
非依存ですので、クライアント側はもちろんAPI側でも使える気がします。

Notification to Smart Phone App

Add function to notify to smartphone application.

• android: use Google Cloud Messaging
• iOS: use Apple Push Notification Service

メッセージをキャンセルしても通知される

メッセージが通知されるまでの5秒間の間にメッセージを削除してもメッセージ通知がされてしまう。
（という現象が見えたということであり確定ではない）

OAuth Provider

Add function for OAuth Provider.

Enable to access from everywhere(add Access-Control-Allow-Origin into response header)

ユーザーに関連するデータの扱いに関して

問題

• ユーザーに関連するデータ(メッセージなど)は、多くがusernameとひもづいている
• user#destroyはuserコレクションから一致する__id_のデータを消すだけ
  • メッセージとかは残るはず

なので以下の手順で本来見えてはいけないデータが見えたり操作できたりする気がします。
試してはいません。

1. AさんがBobという名前で登録
2. 色々操作
3. Aさんが退会するのでユーザー(Bob)削除
4. BさんがBobという名前で登録
5. Aさん時代のBobの履歴が見える

対策案

• 論理削除にする
  • 一度登録された名前はそのユーザーが退会しても使えない
• 物理削除するときに関連データもちゃんと消す
  • MongoDBはトランザクションがないと思うので微妙
• usernameではなく_idで関連づけさせる
  • 既存のアレコレに影響あり

どのテストフレームワークを使うか

以下の3つからどれを使うか悩んでいます。

• qunit
• jasmine
• mocha

インストール要件、CUI実行方法、テストの記述方法などが異なります。
何か希望ってあったりしますか？
ちなみに私はqunitしか実際に使ったことはありません。

記述方法だけ見るとmochaが一番好みで、インストール含め導入のしやすさだとqunitがbestかなーと思っています。

特に希望なければ、私の独断と偏見で決めまっす

Implements APIs on SockJS

Implements APIs on SockJS. Specifically, the candidates of APIs are below:

1. Notify updates of Messages, Monolog, Announce, and Private
2. Notify who respond to your Messages, Announce, and so on

Whether to separate the destination of messages and announcements

Currently, messages are stored to "messages" collection, and announce is stored to "announce" collection. This is difficult to combined timeline of both. It is easy if both information are stored to same collection.

Implements API to obtain messages addresses to me(mentions_timeline in Twitter)

Implements API to obtain messages addresses to me(mentions_timeline in Twitter)

API name: /messages/tome

Including below messages:

• message's addresses contains me

Module化の挑戦

modularization ブランチを切りました。

確認済み

• 起動できる
• タイムライン表示

未対応

• 静的ファイルが取得できない(アバター画像出ない)

課題

• Mac OSXだとauto-redeployが効かない？
  • https://groups.google.com/forum/#!topic/vertx/PJBwXab4iPI

Implements API to edit user belongings to groups

group is similar to MailingList.

• create group
• remove group
• add group(s) to user's information
• remove group(s) from user's information

Add avator definition into user information

• add avator url(or image path) to user information
• add API to handle(edit) avator url

also, requires to determine a place to store avator images.

Pivot framework

Current framework is Vert.x.

Vert.x is good but is not major, so the libraries for Vert.x are not many.
Our goal is growth of atmos.

Should we change framework?

Candidates:

1. node
2. play(scala)
3. others

Do you think about this issue?

Multi Login

Currently, atmosphere uses mod-auth-mgr for user authorization.
mod-auth-mgr is very good mod, however this mod does not allow a user keeps more than one sessions.
In atmosphere, this restriction causes the problem that a user can not access to atmosphere using some devices (ex. browser, smartphone) at same time.

For Multi Login, there are some ways to resolve this problem:

1. Implements original authorization function
2. Modify mod-auth-manager (means send pull-request)

I think No.2 is good, because the multi login function will be welcomed by not only us but also many other people.

Add response information to timline's each object.

to be written.