メモ：携帯電話端末からの認証

公開されてる資料をもとにまとめてみました。

■NTT DoCoMo
作ろうiモードコンテンツ | サービス・機能 | NTTドコモ
ここに必要なことはすべて書いてありますね。

◎端末情報の取得方法 → ユーザーエージェントとか参考
1.A要素またはFORM要素に「utn」をくっつける。→utn要素
2.送信時、端末に確認ダイアログが出る
3.アクセス時の、HTTP_USER_AGENT の結果からser/icc を抽出する。
・DoCoMo/1.0の場合(MOVA)

  ereg( "ser([0-9A-Za-z]{11})" , $UserAgent , $ser ) ;  // 11桁。[0-9A-Z] でいい気がする。

・DoCoMo/2.0の場合(FOMA)

  ereg( "ser([0-9A-Za-z]{15})" , $UserAgent , $ser ) ;   // 15桁。[0-9A-Z] でいい気がする。
  ereg( "icc([0-9A-Za-z]{20})" , $UserAgent , $icc ) ;   // 20桁。

ちなみに、utnつけて送るとこんなかんじになります。

■au (KDDI)
環境変数 HTTP_X_UP_SUBNO が送出されているので、それを拾ってきます。
→ KDDI au: そのほかの技術情報 > ユーザーエージェント

HTTP Requestヘッダ情報では、この他にHTTP_X_UP_SUBNOフィールドにてEZ番号が確認できます。
EZ番号は、ユーザの端末操作によって、送出しない設定にすることが可能です。ユーザが「送出しない」設定にした場合、本フィールドは送出されません。

送出されてる例です。

■softbank
HTTP_USER_AGENT に端末シリアル番号がくっついています。
→ユーザーエージェントについて / ソフトバンク
多分これでいいはず・・・。

  ereg( "/SN([0-9A-Za-z]+) " , $UserAgent  , $sno ) ;  // 実機ないからわかりません＞＜

■WILLCOM
資料は見あたらず。

手元にAdvanced/W-ZERO3[es]があったので試してみましたが、そういうものは存在しないようです。
別の認証方法を考えるべきですね。

※2008.08.29追記：お詫びと訂正
例で書いたereg関数の引数の順番間違えてました orz
「正規表現,対象,収容先」が正しいんです。

作りかけとか色々「なまもの注意」置き場

以前から作ってあったけど、とりあえずここに置くことにしました。
まだ何もないよ!!

http://sayama-yuki.sakura.ne.jp/
何か作ったりしたあとに運用開始したら、ここで公開予定。

分散式メッセージングサービス：外向き仕様を考える上で

分散式メッセージングサービスとか考えてみる。の絡みで。
いろいろと必要なことをメモ。

●XMLの仕様
XML基本仕様
→拡張可能なマーク付け言語 (XML) 1.0

●PHPでXMLを扱う
PHP マニュアル
→XML操作
　いろいろあるので、いまホスティングしてるところで使えるのは何かを確認する必要がある。

mixiのOpenID対応

こればかりは絶対にない!と思っていた予想をひっくり返された（笑）。

とりあえず、仕様が公開されてるのでメモ。
mixi Developer Center » mixi OpenID

これを知る上でのOpenID 2.0の仕様は以下を参照。
Final: OpenID Authentication 2.0 - Final

今日、抱えてる大きな仕事が一段落ついたので、だいぶ（頭の中が）楽になりました。
気が向いたら取りかかってみようかと思います。
とあるサイトのブログに実装したら面白そうなので。

分散式メッセージングサービスとか考えてみる。

Twitterとかそのほか色々流行ってますよね。
ついにmixiも真似しはじめたくらいだし。

サーバへの一極集中になっちゃうので、これを分散させる（各個人のサーバで動かす）にはどうしたらいいのかなーと思いまして。
色々考えてみました。漠然と（笑）

●ベース＝ここの前提は変えない
・通信プロトコルはHTTPだけで構成。(UI/API/クライアント間通信すべて)
・ユーザーが簡単に設置(インストール)できること。DBとかは使用しない。
・言語はPHPかなー。rubyでCGIでもいいけど。

●基本構造
・チャットと同じ。

●フォロー
・フォローされた側がフォローした側に(HTTP経由で)データを渡す構造。
・更新されたら(フォローしてる側の)クライアントにXMLで渡す
・クライアントは受け取ったデータが本当にフォローしてる側のものかを確認(照合)

●フォロー処理の問題点
・認証構造。へたするとクラックされてspamを送りつけられる。
・フォローされた数が多くなったら(100超えるとかそんなかんじ)、クライアントへの送信がネックになる
　→中継(hub)サービスの設置と実装が必要?

●中継(hub)サービス
・配信中継するサーバ。1つのサーバからきたメッセージを複数のクライアントに送信。
・本当に中継だけでもいいし、同時にメッセージングサービスを動かして、内部で配信、とやってもOK。
・えっと・・・つまり、うまくやると、違うメッセージングサービスの内容を1つのタイムラインにのっけちゃうことも可能になっちゃうかも。

・・・ここまで書いて。
SMTPとかNNTPとか、なんかそういうのに近いのが浮かびました。
メールだとメーリングリスト配信とかそういうノリ。

正直なところ・・・絶対誰かが既に考えてるよね(^^;
でも、面白そうなんで組んでみるかなー?