Linuxを使ってみる

とあるディレクトリ以下のファイルへアクセスする際、ログインさせたい。
ディレクトリ以下が静的なページなら、PHPで認証後そのページを読み込んで表示させる方法がある。
あるいは拡張子phpにしておいて、先頭で認証ロジック呼ぶ。
が、ファイルにはPDFもあるという。
となると、思いつくのはBasic認証しかなく（いろいろ調べたけれど、他にはなかった）。

簡単に使うには .htaccess にBasic認証の記述をし、別途ユーザ（パスワード）ファイルを置く。
今回、ユーザIDとパスワードのほかにも氏名等の情報も保持したいので、会員登録の要求があった場合、ユーザファイルに書き込む＆DBにもその他情報を書き込む、の2本立てかと思っていたのだが、調べるとBasic認証のユーザ情報をPostgreSQLに保持できる方法があった。
Apacheのモジュールで「mod_auth_pgsql」というもの。

http://www.giuseppetanzilli.it/mod_auth_pgsql/
ローカルはApache2だったのでそれ用のtarを落としてきて解凍。インストールはDSOで、INSTALLに書いてあるそのままの手順でOKだった。

DBにはユーザテーブルを作っておく。（最低IDとパスワード）
そして認証をかけたいディレクトリに.htaccessをおき（httpd.confに書いてもいい）、
mod_auth_pgsql用の定義を書く。

AuthName "My PostgreSQL Authenticator"
AuthType basic
Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user postgres
Auth_PG_database www
Auth_PG_pwd_table valid_users
Auth_PG_uid_field user
Auth_PG_pwd_field password
<LIMIT GET POST>
require valid-user
</LIMIT>

まだ試していないが、ログ用のテーブルを作ればログもとれるし、一度認証が通った後にDBアクセスさせたくなければ Auth_PG_cache_passwords を On にすればいいそうだ。
簡単に動いてかなり嬉しかった..

ただ、Basic認証なので（厳密な）ログアウトはできなくて「ブラウザをすべて閉じる」しかないのは欠点。これは仕方ない...

(例2)ログインできない

AUのある機種で、ログインできない、という。
他のキャリアや、AUのほかの機種では問題なくログインできる。

これも試行、試行で....
わかったことといえば

・POSTでhttps://～ へ遷移 → NG
・<a href="https://～">XXX で遷移 → NG

結局、遷移先に到達した時に session_id が変わってしまっていたことが原因だった。セッションIDをhiddenで渡したり、パラメタに明示しても、なので、まさか遷移先でそれが受け取られていないというのには、ほんっとうにこれにはやられた。
AUのサーバを経由する時になにがしかの処理が入ってるのか、どうか....

PG内で header("location:https://～"); とし、セッションIDをパラメタ（クエリ）に含めてやることで、やっとセッションIDが引き継がれた。

※他の<a href="https://～"> は特に問題ないし、
例によって原因は分からないのだが、追求はできませんのでここまで。

※あと、user agent でブラウザが
UP.Browser/6.2.0.9.2 未満の場合はNGで、それ以上はOKだった。

また、この不具合が出る前、別のコーディングの時は UP.Browser/6.2.0.9.2以上の時はNGで 未満がOKというときもあった。...どういうコーディングだったかは、もはや覚えていないのであるが。

ある程度はＰＣだけでもテストできます。ケータイ(モバイル)サイト。
しかし、実機だと予想もつかないところでエラーが発生する。
「同じキャリアでもこの機種だと大丈夫なのにあれはダメ」ということが普通に起こる...

（例1)おちる

メールに記載した、とあるＵＲＬにアクセスすると端末がおちる。ここでいう「おちる」は、勝手に電源が切れて立ち上がる、再起動。何回やっても、100%再起動。機種はVodafone V703SH。同じ3GでもV902Tは無問題。

https://～ だったのが問題か？ いや、別のhttps://～のURLは普通にアクセスできている。
あれやこれやと試してみた。

・メール記載のURLをコピペしてブラウザから直接アクセス→NG。再起動
・URLをhttpsでなくhttpに変更してブラウザからアクセス→OK。（httpsが悪いのか？）
・注文キャンセルURL→OK。（→httpsが悪いわけではない）
・テストページにURLへのリンクをはり、そこからアクセス→OK。（????リファラとかチェックしてるのか？）
・メアドを変えたり、URLに他のパラメタをつけてみた→NG。再起動

謎です。
とりあえず4番目の方式だとOKだったので、一枚画面をかませて処理することで決着。理由が分からないからすごーく気持ち悪いけど、機種固有のことなんでこれ以上は一般市民には追求不可能です。

#Voda再起動時に画面に「How Are You?」と出るんですが...
#最悪に決まっとるだろうが、と10回以上心の中でつぶやきました。

SSL電子証明書を、ベリサインで発行していたのです、当初サーバでは。そこではケータイからのアクセスにはなんら問題はなかった。https://～でも。
しかし、サーバ移転に伴い、ジオトラスト社のものに変更したら、、、https://～はアクセス不可になってしまった。
正確にはDocomoはアクセスできるが、「このサイトの安全性が確認できません。接続しますか」と必ず聞かれる。毎回必ず。
Vodaｆｏｎｅは、「エラーが発生しました」となりＮＧ！ ＡＵもアクセスできず。

スタッフ間でいろいろと調べた結果、以下のような情報が。。

----------
http://q.hatena.ne.jp/1124450440
Geotrustは128bit鍵しか提供していませんので、鍵長128bitに対応していない携帯端末ではエラーになってしまいます。

ベリサインの証明書が堅実だといわれる理由は、他社が提供していない56bit（または40bit）鍵にも確実に対応している為だと思います。

PCサイトの場合はジオトラスト社などの証明書でも十分ですが、携帯サイトとなると56bit（または40bit）鍵を提供するベリサイン社を選択するのが堅実だと思います。
----------

ということで、ベリサインを再度申し込み。で、無事に、どのキャリアからもアクセスできるようになりました。

ケータイ(モバイル)サイトを本格的に開発し始めた。実機でテストするにつれ、いろいろとつまづきが...
まず王道、文字化け。

PC向けのサイトを、PHPスクリプト・Smartyファイル・outputのencoding 全て
EUC-JPで作成していて、これはこれで何も問題はなかった。

＜php.ini＞
mbstring.encoding = EUC-JP
mbstring.http_input = auto
mbstring.http_output = EUC-JP
mbstring.internal_encoding = auto

ケータイサイトは同じサーバで、同じく内部エンコーディングはEUCで、入出力のみShift_JISとして開発。
スクリプトの初期に

mb_http_output("SJIS");
ob_start("mb_output_handler");

を指定し、ごく普通の表示ページは問題なし。
しかし、inputなど、formの入力要素が出てきた時に文字化け。
Smarty、HTML_QuickFormを使用していたため、この辺りに問題あるのか？とソースを追ってみたり。
Smartyのoutput_filterで出力コンテンツをSJISにしてみたり、
$_POSTをEUCやらSJISやら、いろいろと変換したり。
しかし、NG。何をどうしても一度Submitした後のエラー表示でQuickFormがセットする inputのvalue値がEUCのまま...（他の表示部はSJIS）

最後の手段、PHPのMLに投げようとメールを書きかけ、phpinfo()をもう一度見てみると

「mbstring.encoding_translation None」

今まで気にしていなかった設定項目が。
「入力される HTTP クエリに関して、 文字エンコーディング検出および内部文字エンコーディングへの変換を行う 透過的な文字エンコーディングフィルタを有効にします。 」

Onにして、Apache 再起動。すると、あっさりと文字化けは解決したのだった。脱力...

これは「他人に客観的に説明しているうちに解決」ということにしておく。