↓このモジュールを使ってみた。
どこでもSSL SSL/非SSL自動切替版 anywhereSSL
●不具合が1点。
サイズの大きいページが出力されない。
→内部的に使用している preg_replace の長さ制限にひっかかっていた。
この関数のマニュアルページのコメントを参考に、include/buffering.inc.php を以下のように修正した。
(修正前)
$buf = preg_replace( $pattern, $replacement, $buf );
(修正後)
$iSet= 0; // Count how many times we increase the limit
while( $iSet< 10 ) {
$sNewText= preg_replace( $pattern, $replacement, $buf ); // Try to use PREG
if( preg_last_error()== PREG_BACKTRACK_LIMIT_ERROR ) { // Only check on backtrack limit failure
ini_set( 'pcre.backtrack_limit', (int)ini_get( 'pcre.backtrack_limit' )+ 30000 ); // Get current limit and increase
$iSet++; // Do not overkill the server
} else { // No fail
$buf = $sNewText; // On failure $sNewText would be NULL
break; // Exit loop
}
}
●もう1点。表示上の不具合ではないが、SEOでNGなんだそうで。
Cookieに情報を書き込むため、初回アクセス時、同じURLにリダイレクトしている。
この時にステータスが302となるが、検索エンジンでは拾ってくれなくなる。
→ とりあえずリダイレクトを外してみた。運用後1ヶ月弱だが、今のところは不具合はない。
include/precheck.inc.php 下記、一番下、headerをコメント化。
//*****************************************************************/
// ログイン処理時のみ、XOOPS_ROOT_PATH/include/checklogin.phpをinclude
//*****************************************************************/
if ( ($_SERVER['SCRIPT_FILENAME'] === XOOPS_ROOT_PATH .'/user.php') &&
($_SERVER['REQUEST_METHOD'] === 'POST') &&
(!empty($_POST['op']) && $_POST['op'] === 'login') ) {
include_once( XOOPS_ROOT_PATH.'/include/checklogin.php' );
exit;
}
//header( "Location: " .$current_url );
このモジュール、あまり情報がないようです。使われていないのか...? xoops SSL化のスタンダードってなんだろう。
.htaccessに以下のように書けばOK。
ErrorDocument 503 /maintenance.html
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !=/maintenance.html
RewriteRule ^.*$ - [R=503,L]
</IfModule>
<?php●.htaccessの設定。
header ('HTTP/1.0 503 Service Temporarily Unavailable');
include(dirname(__FILE__) . '/index.html');
?>
RewriteCond %{REQUEST_URI} !\.css$
RewriteCond %{REQUEST_URI} !\.js$
RewriteCond %{REQUEST_URI} !\.jpg$
RewriteCond %{REQUEST_URI} !\.gif$
RewriteCond %{REQUEST_URI} !\.png$
RewriteCond %{REQUEST_URI} !\.swf$
RewriteCond %{REMOTE_ADDR} !=192.168.0.1 #(管理者のIPアドレス)
RewriteCond %{REQUEST_FILENAME} !503.php
RewriteRule ^.*$ /maintenance/503.php [R,L]
テンプレートのあちこちでページタイプを表示させてやっと分かった。
query_post()を使って、あるカテゴリ下の最新記事を取得していたのだが、これ以前ならhome、これ以降はarchiveとなってしまう。
なんじゃそりゃ。
もしやと思い、その後に空の条件でquery_post()を発行したらhomeに戻ってた。
外から使える関数でページタイプ変わってちゃいかんでしょーー! 内部処理ダメダメ。。
※WordPress 2.9
(追記2010/4/6)
条件をデフォルトに戻すのは以下になるらしい。
query_posts($query_string);
公開されていないグローバル変数を開発に使わなければ実用的にならないシステムっていうのもなんだかな...
簡単に使うには .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認証なので(厳密な)ログアウトはできなくて「ブラウザをすべて閉じる」しかないのは欠点。これは仕方ない...
]]>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)おちる
メールに記載した、とあるURLにアクセスすると端末がおちる。ここでいう「おちる」は、勝手に電源が切れて立ち上がる、再起動。何回やっても、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回以上心の中でつぶやきました。
スタッフ間でいろいろと調べた結果、以下のような情報が。。
----------
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 再起動。すると、あっさりと文字化けは解決したのだった。脱力...
これは「他人に客観的に説明しているうちに解決」ということにしておく。
]]>open sslはすでにはいっていたため、Apacheの再構築から。
(Apacheソースのディレクトリに移動後)
$make clean
$./configure --enable-so --enable-rewrite --enable-ssl --with-ssl
$make
$su
#make install
この後、サーバ証明書の作成。(本の通りなので略... そのうち必要性が出てきたら書くことにする)
]]>