ブログ

20181220 で xupdate 管理画面が白紙に

2019-04-05T22:00:00+09:00

ローカル環境で xupdate を使って core をアップデートした後で
本番環境にDBやファイルをアップロードし
本番環境の管理画面から xupdate を呼び出したら
リロードが何度も走ったうえで白紙画面が表示されてしまった


/modules/xupdate/admin/index.php?action=UserPassColumnLenFix&xoops_redirect=....

色々調査したところ以下のような問題であった

20181220 へのアップデートによって？ mainfile.php に以下のコードが挿入される


    // Alrady fixed length of users table pass column of this DB (Auto inserts by X-update)
    define('XCUBE_CORE_USER_PASS_LEN_FIXED', true);

この値がセットされていないと xupdate の管理画面を表示した際に、この更新を行うためのリロードが行われる模様

mainfile.php は動作環境によって異なるので、すでにこの対処が行われたDBで、このコードが追加されていない mainfile.php を使用すると
この更新処理を実行しようとして、失敗してしまうものと思われる

本番環境の mainfile.php に、上記のコードを追加してあげれば治る

xupdate CorePack アップデートで画面が真っ白 2

2018-12-26T18:27:04+09:00

xupdate で以下のアップデートをかけたら画面が真っ白に
CorePack 20180208 → CorePack 20181220

以下の二つのファイルのパーミッションを確認
html/modules/user/preload/Primary/EncryptPassword.class.php
xoops_trust_path/modules/xupdate/admin/actions/UserPassColumnLenFixAction.class.php

xupdate CorePack アップデートで画面が真っ白

2018-11-26T19:31:11+09:00

xupdate で以下のアップデートをかけたら画面が真っ白に
CorePack 20170328 → CorePack 20180208

エラーログを見ると
html/preload/debugOnlyAdmin.class.php
が読み込めてない模様

フォルダを確認すると -rw-r----- というパーミッション
chmod go+r してあげてブラウザをリロード
無事に表示されるようになった

おそらく開発環境の PHPは mod_php で動いているため
パーミッションが足りないのだろう
サーバ環境なら fastCGI なので問題は起きないと思われるが
他のファイルに合わせて -rw-r--r-- にしておくのが吉？

coreserver 移行での不具合

2018-10-29T22:10:00+09:00

ssh オートログインを設定していたのだが以下のエラーが出た


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 It is also possible that a host key has just been changed.
...

サーバが変わったからだが、
ssh-keygen -R "xxx.coreserver.jp"
としてから、再接続で再登録してもなぜか怒られる


Warning: the ECDSA host key for 'xxxxxxxxx' differs from the key for the IP address 'XXX.XXX.XXX.XXX'
Offending key for IP in /home/hoge/.ssh/known_hosts:N

IPアドレスでの登録 known_hosts にあったのか、該当の行を削除したら治った
もう一度 ssh-keygen -R で IPアドレスを指定して実行すればよかったのかも
という訳で、別のマシンから再度試してみた
やっぱり
ssh-keygen -R "XXX.XXX.XXX.XXX"
と IPアドレスを指定したら、問題は消えた

xoops ログインできなくなった!!

2014-07-02T10:49:32+09:00

最近何度かログインをしようとしてうまくいかないことがあった。
user.php の応答がないのだ

そしてついにまったくログインできなくなってしまった。
user.php をコピーした名前を変えた user2.php などを作ってアクセスしてみるもダメ
Delegate の中身に何かがあるのだろうか？

さぁどうしよう。
まずはDBを引き上げてきて、開発環境に同じ状態を構築してみた。
やはりuser.php が応答しなくなった。
ということではソースの問題ではなく、DBの状態ということだ...

user.php は
Legacypage.User.Access Delegate
を呼び出しているだけだ
Legacypage.User デリゲートは
modules/user/kernel/LegacypageFunctions.class.php で定義されている class User_LegacypageFunctions の user メソッドだ。

そこからソースを追って、どんどん調べてみると、
core/XCube_Controller.class.php の executeHeader() 中の _setupBlock() 呼び出し
で落ちているようだ
無理やり _setupBlock() をコメントアウトしてログインし、コメントアウトを元に戻す。

その後管理画面のブロックの管理からブロックを外しながら試してみると google adsense のブロックがあると落ちることが分かった。

しかしなぜそれで落ちるのか？しかも user.php の時だけ？
というのは全く分からなかった。

仕方がないので、user.php では、該当のブロックが表示されないようにすることで回避した。

TOKENがおかしい?!

2014-06-12T22:00:00+09:00

xoopsX で新たに作ったサイトで chrome や FireFox で新規登録しようとすると


照合用のワンタイム・チケットが見つかりませんでした。
ほとんどの場合は操作手順の関係でワンタイム・チケットが消費されただけですが、
CSRF攻撃を受けた可能性もあります
（この操作は本当にあなたが望んだ操作ですか？）　
操作内容をしっかり確認し、もう一度操作を行ってください。

と表示されて、登録ができないという状況が発生。
IEでも最初の一回目は同様のメッセージが出たり出なかったり...
新規登録に限らず、トークンがすべてだめのようだ。

いろいろ試してみると、どうもこのサイトのために作ったテーマのせいらしいことが分かった。
標準のテーマなら新規登録できるのだが、テーマを変えると問題が起こる。
何か、大事なものを入れ忘れているのか？

まずは状況確認...

新規登録画面を出して、ソースを開き、フォームの変数 module.user.UserRegisterEditForm.TOKEN の value を確認する。
うーむ、値は入っているようだ。

では次に、その時のセッション変数の値を確認するために phpMyAdmin で xxxxx_session テーブルの中身を開き、sess_data の module.user.UserRegisterEditForm.TOKEN の値を見る。

こちらにも値は入っているが、フォーム変数に設定されている値とは違う値になっている！！！？？？

どういうことだ？
この時点でかなりパニック

うーーーー。
とにかくテーマに問題があるのだから、theme.html を直すしかない...
ということで、コードをどんどん削っていく。
いくら削っても変わらない...
最後の最後↓を削ったらビンゴ！

うーん
どういうことだろう？
href="" なので、該当のURL に対して2度アクセスしてしまったということだろうか？
理屈からするとあり得そう。
1度目にアクセスしたときに TOKENが作られて FORM に埋め込まれる。
href="" でもう一度リクエストがきて、再度 TOKENが作られて、その値でDBの値が上書きされるためにTOKENの値がミスマッチになるということだ。

chrome のネットワークモニターで見ても2度目のアクセスは出てこないのが気になるが、
favicon のアクセスは通常のアクセスとは別に行われているようで、それは link 要素で指定した場合でもそうなのかもしれない。
fiddler あたりで確認すればわかるのだろうが、理屈があっているので良いことにする。

とにかくこれにて一件落着。勉強になりました。

それにしてもデザイナーさん！
こういう技術力を試すような罠を入れておくのはお願いだからやめてください<(_ _)>0

altsys? テンプレート編集で勝手にエスケープ文字列が入ってしまう！

2014-05-05T22:40:00+09:00

altsys でテンプレートの編集をしているときに、なぜか勝手にエスケープ文字列が付加されていたことがあった。

"'\

チケットタイムアウトしてしまった時に、そのまま repost をすると、上記の文字の前に \ が付加されてしまうようだ。
そのために、テンプレートが正しく動作しなくなることがあるので注意！

コメントのネスト表示がカスタマイズできない？

2012-11-18T22:10:00+09:00

XCL 2.2 で、ブログなどのコメント表示欄をカスタマイズしてみたときに、うまくカスタマイズできない所があって悩んでしまった...

コメント表示欄は、legacy_comments_xxxx.html あたりにある。
altsys のテンプレート管理から、互換モジュールを開く。

まずは、コメント表示欄のコメントの登録日時を日付だけの表示に変えるために、legacy_comment.html を開き


<{$comment.date_posted}>

を


<{$comment.date_posted|date_format:"%x"}>

に変えてみた。
これで、ほとんどのコメント表示は直ったのだが、なぜかネスト表示にしたときの返信だけは治らなかった。

色々悩んだのだが、結論から言うと、legacy_comments_nest.html の


<{include file="db:system_comment.html" comment=$reply}>

を


<{include file="db:legacy_comment.html" comment=$reply}>

に変えることで、正しく表示することができた。

キャッシュに注意

この試行錯誤をしているときに、いくら変更してもうまく動作しないことがあった。
もしかしてキャッシュされている？
ということで、altsysの「高度なテンプレート管理」で、「コンパイル済テンプレートキャッシュ」の削除を行うことで、変更を反映させることができた。

Smarty にクロスサイトスクリプティングの脆弱性

2012-10-17T12:57:46+09:00

Smarty にクロスサイトスクリプティングの脆弱性が見つかった

- Smarty 3.1.11 およびそれ以前
- Smarty 2.6.26 およびそれ以前

JPCERT コーディネーションセンター Weekly Report
XCL に使われている Smarty は xoops_trust_path/libs/smarty にあり、
2.2.1 同梱の Smarty.class.php を見ると


var $_version = '2.6.26'

となっていた。

更新が必要だろう。

Smarty 2.6.27 (Sep 25th, 2012) のダウンロードは↓から
Download | Smarty

■XCLへの導入

上記でダウンロードしたファイル(.zip版)を一時的に展開する。

% unzip Smarty-2.6.27.zip
% (cd Smarty-2.6.27/libs/; tar -cf - .) | (cd xoops_trust_path/libs/smarty; tar -xf -)

上書きでインストールしないといけないのは、XCL がプラグインを追加しているため。

関連記事
管理画面トップに Smartyのバージョンを表示する

xcl 2.2.0 コメントの管理のjavascript

2012-06-03T22:40:00+09:00

多分2.2.1 のβではすでに直っていると思うが...

allbox チェックボックスの javascript


onclick="with(document.smilesform){for(...

のsmilesform は commentlistform でなければいけない

修正ファイルの場所は
modules/legacy/admin/templates/comment_list.html