カテゴリー: web

トップページ更新

トップページを更新しました。
リンクページに、太陽光発電、MysTilesのアイコンを追加し、ロゴを更新しています。 また、サブページにも太陽光発電、MysTilesを追加しました。MysTilesはタイル型ポータルページであるMyS’Tileのサブセット版です。MyS’Tileは個人ごとのカスタマイズを想定したJavaScriptベースのポータルページです。 phpで書いたものではありません。これを、クラウドサーバに移行して、個別カスタマイズ部分を削除し、一部をphp化しました。何か良いphpで書かれたポータルアプリケーションもあれば、切り替えたいと思います。何か良いものがあればコメントください。

WordPress5.2リリース

以前、脆弱性に関連して取り上げたWordPress5.2が5月8日にリリースされています。

・管理者アカウントでログインすれば新しいバージョンが提供されていることが左上の更新と赤に白抜きの数字で示されます。また、ダッシュボードや更新画面から最新バージョンに更新することができます。更新の前にバックアップするように案内されます。
・投稿者アカウントでログインした場合は、ダッシュボード上部に「WordPress 5.2 が利用可能です。サイト管理者にお知らせください。」と表示されます。
機能強化を行うメジャーバージョンアップやマイナーバージョンアップの場合、不具合が含まれているケースが多々ある。新たに提供されて機能を使いたいなら話は別だが、 必要がない機能しか提供されていないので、バージョンアップは急がなくてもよいでしょう。そこで、1か月程度は保留することにします。あまり放置するとほかの実行基盤のバージョンとの組み合わせで不具合が発生することがあります。そこで、１年以内にはバージョンアップを適用することにします。通常は、１年経過する前にセキュリティパッチが提供されて、セキュリティパッチを適用する必要が発生します。
WordPressの場合、Security Category Archiveのページ
https://wordpress.org/news/category/security/ をチェックしていれば、脆弱性対処を含むパッチが提供されているか確認できる。ざっと見て、2か月に１回程度の頻度で脆弱性対処パッチが提供されていることがわかります。

これにより、WordPressの更新頻度が頻繁であれば、特別な方法で通知されなくても気づくことができます。逆にWordPressの更新頻度が低い場合、脆弱性対策パッチ未適用状態で長期間運用される可能性が高くなりそうです。このパターンは対応できるようにしたほうがよさそうです。

ということで、バージョンアップ情報や脆弱性対処を含むパッチの提供情報をメールで通知する仕掛けを用意しました。今回の公開には間に合わなかったが次回の公開時には、実際に通知されることを確認します。

脆弱性情報の収集

脆弱性関連情報を「定期的に自動チェックしてメール通知するとか、検討してみよう。」ということで、とりあえずクラウドサーバ上にpythonコードを移行し、定期実行の手順を検証します。
　phpから呼び出したところで、エラー。このクラウド環境は、Python2が動いていて、python3には対応していない。いまどきのクラウド環境ならPython3に対応しているのだろう。つぎの引っ越し先はPython3にも対応していることを条件に入れよう。その選定作業は別途行うことにします。※
Python2用にコードを書き換えて、チェック対象のコンテンツをダウンロードできることを確認できました。

つぎに、クラウド環境のコントロールパネルで定期実行タスクを設定します。
定期実行で、「with open(saveFilePath, ‘wb’) as saveFile:
IOError: [Errno 13] Permission denied: 」のエラーメールが送られてくる。
phpから呼び出した時とは実行ユーザが異なることが原因だろう。
ということで、パス指定を修正して、定期実行によりチェック対象のコンテンツをダウンロードできることを確認できました。
　
次は、脆弱性関連情報をチェックするPythonコードを用意します。

WordPress投稿のパスワードって何？　まとめ

まるめると「投稿ごとにパスワード設定可能なユーザIDが共通のフォーム認証」ということです。Webエンジニアならこの表現で大体の挙動は理解できると思います。

Web技術的な表現で書くと、次の通りです。
・WordPressで共通のポストデータでパスワードを指定する ユーザIDの指定がない フォーム認証。

サイトで固定のクッキーを使っているのか、それともページごとに指定するクッキーで指定するのかと推測しましたが、パスワードをWordPress固定のポストデータで指定して、WordPressのクッキーでセッション維持をしていました。

これにより次の動作をします。ある投稿のパスワード入力フォームに別の投稿用のパスワードを入力すると、パスワードを入力した投稿は参照できないが、パスワードが一致した投稿は参照できるようになる。また、ある投稿Aを参照できる状態で、別の投稿Bを参照するためのパスワードを入力すると投稿Bは参照可能となると同時に投稿Aは参照できない状態に変わります。

結局、この機能、どこかで投稿参照用のパスワードを利用者に渡して参照可能にするというものでしょう。　実際に使っているというか、有効に使えているところがあるのでしょうか。

WordPress 投稿の非公開ってどう使う？

この機能って、公開、非公開をあとで切り替える機能ってこと?　つまり、主な目的は公開済みのものを後で削除ではなく非公開に切り替えるということ？　見せないようにするのに削除するのではなくスイッチを切り替えて見せないようにする。証拠保存が目的でしょうか？　　

非公開にすればタイトルさえ表示されなくなる。

機能名が、なんか変。　つまり「公開する」なのに「非公開」ってなっている点です。日本語に翻訳したところで変なことになっているのか？

やっぱり読み通りでした。英語だと、

「公開する」→Published
「非公開」→Private
です。

「私的：Private（プライベート）」の反対語は 「公的：public（パブリック）」なので、英語だと違和感がありません。 Privateを日本語に翻訳するときに”非公開”としたことで、機能名的な違和感が発生したわけです。

初スパム

　
運用開始して10日目で、スパムコメントが入りました。
以前のサイトで運用していたフォーラムシステムでは、最初のスパム投稿が発生したのは 運用から１年以上経過した後でした。そのフォーラムにはスパムを自動判定できる仕掛けは、 なかったので、気が付いた時にはごみ投稿の山ができていたこともありました。
この感じだと、スパムコメントも大量にある感じがします。でもスパムをブロックする 仕掛けで、検出できていました。スパム検出が機能していることは、とりあえず一安心です。
つぎは、検出精度と処置の手間がどの程度低減できるのか注目です。

そういえば脆弱性

WordPressの初期設定をしたばっかりだが、そういえばWordPress関連の脆弱性は結構な数があったような気がする。
とうことで、その他のアプリケーションも含めて、チェックしてみました。

まず、WordPress：
開発元の情報だと5.1.1が最新で、5.1以前は脆弱性ありということ。
https://wordpress.org/news/2019/03/wordpress-5-1-1-security-and-maintenance-release/
https://wpvulndb.com/vulnerabilities/9230
　→ これに関しては対処済みで問題なし。

https://wordpress.org/news/category/releases/
　→ 2019/4/24時点のリリース状況だと、近く5.2が出そうだが、脆弱性的にはどうかは不明。ただし、バージョン番号のつけかたからすると、
つぎのSecurity Releaseは、5.1.2か、5.2.1だろう。

プラグイン：WordPress関連ではプラグインの脆弱性が多数報告されている。
https://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja&useSynonym=1&keyword=WordPress
https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=WordPress&search_type=all
→インストールしたプラグインも一通り確認して対処済みであることを確認した。

何度も見て回るのは面倒なので、定期的に自動チェックしてメール通知するとか、検討してみよう。

とりあえずチェックするサイトはつぎや開発元サイトにする。
https://nvd.nist.gov/vuln/search
https://jvndb.jvn.jp/index.html

phpからpython起動

ローカルマシン上で動かしているpythonのコードを、サーバー上に移行することを検討中です。　現在、Jupyter Notebook（iPython Notebook）を使っていて、この環境向けに書いたコードを定期的に起動して、データ収集と解析を行っています。現状は、実行するときは手動でJupyterを起動して、操作しています。　この手間を何とかしたいわけです。

まず、pythonコードをPHPから呼び出す方法を確認。　いくつかのサイトに記載があり、つぎの２つの動作確認はすぐにできました。

「phpからpythonを呼び出し、実行結果を取得、表示」
「サーバー側でPythonスクリプトを動かし、結果をクライアント側に表示する」

ただ、numpyをインポートする単純なコードだと、phpではpythonの出力文字列を拾えない状態になった。上の２つ目のコードに順に追加していくと問題なく動作し、前の問題を再現できていない。　

1つめのコードに１行ずつ追加して問題発生有無をチェックしていくと、２バイト文字を含む行を追加した時点で問題が発生することが判明した。　そして、２つ目のpythonコードと比べて、
２つ目のpythonコード の1行目「#-*– coding: utf-8 -＊-」が効いていた。　これを1つめのコードに反映して問題が解決した。　この行の記述のとおり２バイト文字はここで指定した文字コードで保存しないと文字化けする。
↑そもそもPHPでエラー出力を拾えるように細工しておけば、原因はすぐに分かったはずだが、　久しぶりに触ると.やはりだいぶ忘れてます。

つぎはJupyter Notebookのコードを移植していきます。