考え直さないといけない。

現状のカケラの樹では、OpenIDログイン時に次のような処理をしてる。

1. OpenIDがログインフォームに入力され、submitされる
2. 入力されたOpenIDがはてな、livedoor、TypeKeyかをチェック
3. OpenID providerに認証要求
4. 認証が成功して帰ってきた次点で、OpenIDをバラしてサービス名*1とユーザ名*2を取得、ユーザ情報生成
5. ユーザページ*3を開く

こうやって、ユーザページのURIに生のOpenIDが出ないようにしてるんだけど、この方法はOpenIDからユーザ名が分かることを前提としてる。今サポートしてるOpenID provider*4は偶然みんなその形だから良かったんだけど、今回Yahoo!が提供を始めたOpenIDはこんな形。

https://me.yahoo.co.jp/a/XXXXXXXXXXXXXXXXXXXXX

XXXXXXX……のところは乱数で生成された文字列だそう。ユーザ名はわからない。けど、OpenIDとしては何の問題もない。そもそもカケラの樹の設計、前提がおかしかったわけ。
だからこういうOpenIDにも対応できるようにするには、ちょっと改修が必要なわけだけどどうすればいいか。方法はいくつか考えられる。

OpenIDをそのままユーザ名として使う

「ようこそ、http://www.hatena.ne.jp/yune_kotomi/さん」という感じ。自サービスでのユーザページのURIは

http://kakera.tarenari.jp/user/show/http://www.hatena.ne.jp/yune_kotomi/

のようにする。

デメリット

• 見た目が悪い

OpenIDとユーザ名の対応を自サービス側で行う

昨日紹介したSpringnoteのように、OpenIDログイン後、初回ログインならスクリーンネームをユーザに聞く。決まったら、以後はその名前で表示とかURIの生成を行う。

デメリット

• 初回ログイン時にスクリーンネーム確定の操作がワンクッション入る
• スクリーンネームはサービス上で一意である必要があるので、OpenID provider側のアカウントで使えていた名前が使えない可能性がある(はてなの"yune_kotomi"がスクリーンネームに"yune_kotomi"を使うと、その後ログインしたlivedoorの"yune_kotomi"はそのスクリーンネームが使えない)
  • URIにスクリーンネームを使わなければ重複を許しても問題ないが、ユーザページのURIが分かりづらくなる

OpenID Simple Registration Extensionでニックネームを得る

OpenID provider側にそのユーザのニックネームなどを問い合わせる仕組みがある。

デメリット

• 旧仕様のOpenID provider相手には使えない
• Y!は新仕様だけど、この拡張仕様には対応しないので使えない

*1:hatena/livedoor/typekey

*2:"yune_kotomi"のような

*3:/user/show/hatena/yune_kotomiのようなパス

*4:はてな/livedoor/TypeKey