Hatena::ブログ(Diary)

gusagiの日記 RSSフィード

2010-12-12

(非フレームワークの)PHPで携帯対応( #phpadvent2010 )

はじめに

この記事は「PHP Advent Calendar jp 2010 : ATND」の12日目です。

昨日はyuyakさんの「PHPマニュアルを読み解く」でした。


PHPで携帯対応とか

最近はフレームワークを利用した開発が主流なこともあり、(CakePHPであればKtai Libraryと言った具合に)フレームワークごとのライブラリで対応することも多いかと思います。

ですが、仕事で自社独自のフレームワークを利用していたり、昔から運用されているシステムだったり、何らかの理由で携帯対応のライブラリが簡単に導入できない場合もあります。

そういった場合に「このあたりを知っておくと何とかなるんじゃない?」的なものを書いてみます。*1


前提条件

前提条件としては、3G以上の携帯前提です。

また、3G以上の携帯に対応させるための基礎知識としては、

にわかりやすくまとまっています。どちらの記事もぜひ参考にしてください。


文字コード

出力する際は、docomoauであればSJIS, SoftBankであればUTF-8とするのが良いようです。

数年前であればSJIS統一で問題なかったのですが、SoftBank3G端末以降だと一部はまる場合があります。逆に、UTF-8で統一してしまうとdocomoの端末やSSL状態のauで問題が出ることがあります。特に、ユーザからの入力が可能なWEBアプリケーションの場合は、絵文字や機種依存文字で抜け落ちが発生することもあるので注意が必要です。

キャリアごとに文字コードを使い分ける方法としては、リクエストを受け取った直後 & 最終出力時に文字コード変換+絵文字変換を行うのが良いでしょう。*2

なお、SJISを使う場合はPHP文字コード変換を行う場合に「SJIS-win」を利用しないと一部の文字が使えなくなりますので注意が必要です。また、HTTPレスポンスヘッダでtypoしたりと、細かい部分でも気を配る必要があります。

一報、内部文字コードは、これから新規に開発するのであればUTF-8にしておくのが一番無難です。これは、文字化け等の問題以外に、セキュリティ的な観点からもです。特に、SJISの場合には5C問題など色々とはまることがあるので注意が必要です。*3


キャリア・機種判定

キャリア判定などは、PEAR::Net_UserAgent_Mobileなどを使うのがお手軽です。ただし、2009年6月が最後のリリースバージョンが最後となっていますので、最新端末に対応させる場合は自分で対応させる必要があるかも知れません。*4

自前でキャリア・機種判定を行う場合は、アクセス元のIPアドレスで判定する方法とユーザエージェントで判定する方法があります。

IPアドレスで判定する場合は、Net_IPv4_NetworkGroupを用いたりsfMobileIPPluginを参考に自前で判定させるのが良さそうです。ただし、IPアドレス情報は自前で管理する必要があります。

携帯以外でもアクセスさせて構わない場合は、ユーザエージェントで判定する方がお手軽です。

ユーザエージェントで判定する方法はインターネット上に多数公開されているので、そちらを参考にしてください^^;


絵文字

PictgramConverterJapanese_Mobile_EmojiText_Pictogram_MobileHTML_Emojiなど、絵文字変換ライブラリが複数公開されていますので、ライセンスや要件に合わせて選択してください。*5

なお、ウノウラボで公開されている文字コードと携帯絵文字については、一度読んでおくことをお勧めします!


デザイン(CSS

基本的には、XHTML+CSSで構築するのがよいでしょう。ただ、docomoiモードブラウザ1.0が外部CSSに対応していなかったり、auの一部端末が子孫セレクタをうまく解釈できなかったりと、PCと同じようにデザインを組むと面倒です。

インラインCSSであれば、3キャリアともにだいたい同じ記述ができるのですが、すべてのテンプレートでインライン形式の記述を行うのは結構骨だと思います。

そのような場合はHTML_CSS_Mobileの導入を検討してみてください。*6

なお、上記で「だいたい同じ」と書いた理由ですが、CSSとして同じ記述をしていてもキャリアや端末によって解釈が異なることが多々あります。特に、文字サイズに関しては、キャリアごとに記述を分ける or テンプレート上の記述を出力時にキャリアごとに書き換えるなどの処理が必要になります。


セキュリティ

携帯対応をさせる際には、セッションに関するセキュリティを必ず意識する必要があります。

というのも、iモードブラウザ1.0はCOOKIEに対応していませんし、auSoftBank端末であってもSSLが絡んだ場合にはCOOKIEの扱いで微妙な挙動をすることもあります*7 とはいえ、無制限にセッションIDをURLに付与すると、今度はセッションIDの漏洩に繋がりセッションハイジャックリスクが上がります。

かと言って、契約者固有ID(正確にはiモードIDだったりサブスクライバIDだったり端末シリアル番号だったり、キャリアごとに呼称が異なるので、文中ではこの表記とします)をセッションID代わりに使用したりすると、どこのサイトでも取得出来る情報を使ってセッション管理するという、とんでもない状態になってしまいます。

基本的には、COOKIEを利用できる端末であれば(SSL時の挙動の対応も実装して)COOKIEセッションを管理し、COOKIEが利用できない一部の端末の場合は生存時間を短くしたりセッションID以外の情報によるチェックを実装した上でのセッションID付与、というのが現実的なラインじゃないかと思います。とはいえ「どの程度なら安全なのさ?」と言われると難しいのですが。。。

また、2009年の半ばくらいからJavaScriptを利用できる端末が増えてきていますが、これによりXSSによるかんたんログインのなりすましなども報告されています。*8

明示的にJavaScriptを利用するのでなければJavaScriptのタグを消去したり、PCサイトと同様にXSSScript挿入攻撃への対応を行う必要があります。


その他

かんたんログイン

携帯サイトログインと言えば「かんたんログイン」が当たり前という印象が強いですが、HASHコンサルティング株式会社による『iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性』や、こちらこちら高木浩光氏が述べているように、契約者固有IDだけでかんたんログインを行うのはセキュリティ上のリスクがあります*9

ユーザの利便性という理由で実装を希望されることも多いと思いますが、その際にはリスクを十分に検討し、できることなら別の手段による利便性の確保を試みてみるのも必要かと思います。

入力モード

入力フォームで「ここは半角英数字のみにしたい」とか「ここは初期は数字のみだけど入力モードを変更したい」といった場合には、id:Yudoufu さんが書いた記事携帯XHTMLでの入力モードのまとめと、ちょっとしたハマりどころについてには一度目を通しておくことをおすすめします。


おわりに

こんな感じで、(まとまりきっていませんが)「このあたりを知っておくと何とかなるんじゃない?」的なものを書いてみました。

最近はスマートフォンが勢いを伸ばしていますが、ガラケー(最近はフィーチャー・フォンと呼ばれることもあるようです)対応もまだまだ必要かと思います。

今回書いた内容がどなたかの参考になれば幸いです^^;

また、参考にさせていただいた方々、本当にありがとうございました!


明日は、id:cakephper さんの担当です。

CakePHPに留まらずアクティブな発信をされているcakephperさんの記事、とても楽しみです。

よろしくお願いします!

*1:あくまで個人的な考えなので「もっとこうした方が良いよ」なツッコミお待ちしてます^^;

*2docomoの場合は、最終出力時にContent-Typeのレスポンスヘッダ送出も必要だったりします

*3HASHコンサルティング株式会社の徳丸氏が公開されているPHPカンファレンス2010 テックデイの資料がわかりやすいです

*4:開発自体はGithub上で続いているようです

*5:以前はMobilePictogramConverterというライブラリも公開されていたんですが、配布サイトがなくなってしまったようです。。。

*6:合わせてHTML_CSS_Selector2XPathが必要です

*7:参考:auのSSLでのCookieの挙動がおかしいau,SoftBankでSSLでCookieセッションを使用する場合の問題点

*8HASHコンサルティング株式会社「Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題」

*9:といいつつ自分のライブラリも利用しているので、時間を取って改修します...orz

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証