Windows8.1にアップグレードしたらGoogle Chromeの解像度がおかしくなった

22:20追記
ちゃんとした解決方法を紹介している方がいらっしゃいました。
徒然覚書:WINDOWS 8.1 にアップデートしたら、ディスプレイの解像度がおかしくなるトラブル発生。解決方法。
http://www.tsurezure.org/2013/10/windows-81.html

—-

手持ちのウルトラブックがWindows8機でした。
Windows8.1にアップグレードできると聞いたのでやってみました。

アップグレード自体は特に難もなく終了。
何かあちこち微妙な感じになってますが、慣れの問題かなと思いました。
で、メインで使ってるブラウザのGoogle Chrome(30.0.1599.101 m)を立ち上げてみると…
# あ、デスクトップモードでです

win8.1-chrome

ぼやけている(・ω・ )
解像度がおかしいようです。試しにIEやFirefoxなど他のアプリケーションを使ってみても別におかしな所はありません。
ちょろっとGoogleで検索かけるとおかしいという話はごくごくわずか出てましたが、解決方法までは見つかりませんでした。

他のブラウザを使う気はないので、いくつか試行錯誤しましたら、一応解像度は確保出来ました(・ε・ )

taskmng

タスクマネージャーを起動(なんか簡略化された表示になりましたね)。Google Chromeを右クリックしてプロパティをクリック。

prop

Google Chromeのタスクのプロパティが表示されるので、互換性タブの設定にある高DPI設定では画面のスケーリングを無効にするにチェックを入れてOKボタンをクリック。

Google Chromeを再起動します。

win8.1-chrome-kai

これでなんかフォントとかの感じはちょっと違いますが、解像度は戻りました。
今ところはこれで不具合は出てませんがなんかあるかもしれません。
やり方としては邪道な気がするのでGoogle先生の対応を待ちたいと思います(・ω・ )

カテゴリー: Google Chrome, Windows | コメントする

MySQLの練習

Apacheも入れたし、PHPも動いた。と言うことで、今度はデータベースのインストールと設定です。XAMPPと言えばデータベースはMySQLなのでこれを入れる事にしました。(MariaDBを使ってみたいとも思いましたが、Webアプリの一つもまともに作ってないのにやめとけよという気持ちになったのでやめました)

例によって参考にしているサイトのMySQLインストールのページを開くと、今回はOracleの用意したWindowsのインストーラーを使うようです(・_・)ZIPファイルの方も気になってみてみましたが、こちらはどうやらPerlで書かれたインストーラーが用意されているようでした。使い方がよく分からんし、まだPerlは入れてないし逆らう必要もないなということで素直に従うことにしました。あ、私の場合は64bit版で。

手順通りに進めていけばさらっとインストール終了です。
設定も特に問題なく進みました。親切なページですね。
my.iniファイルの設置場所だけデータファイルを置くディレクトリに入ってたので、これをMySQL本体の入っているディレクトリにコピーしておきました。
コンソールから接続して幾つかクエリを試して使えることがわかったので、これでインストールは終了です。インストーラで楽したからなのか、あっけない(・_・)

代表的なデータベースの管理ツールであるphpAdmin。入れるかどうか迷いましたが、今回は置いておいて先に進むことにしました。
あれ、便利なんだけど使いびたるとコンソールの使い方をいつまでたっても覚えられないような気がしてきて(・ω・ )必要になったら入れます。

さて、今回のXAMPP離れの練習の最後のステップです。
PHPからMySQLのデータベースにアクセスしてみます。そういうわけでまた飛びますが、PHP入門のページのデータベースへのアクセスの項を見てみました。
真っ先にMySQLへの接続のページがあるので中を見てみるのですが、ここで出てくるモジュールはPHP5.5では非推奨です。保守のために必要になったり余裕が出たら改めて勉強すりゃいいかと言うことで、データベース側の用意と言う項目だけやって飛ばしました。

代わりに使えるのがmysqliとPDO。ちょうど今回参考にしているサイトがPDOの使い方を説明してくれているのでPDOでやってみました。PDOの利用と言うページです。
で、いきなりここの説明と食い違うのですが、phd_pdo.dllはありません。マニュアルにはPHP5.3以降必要なくなったと書いてあります。バージョンによって入れたり使うなと言われたりややこしいですね(・ε・ )
他の手順についてはこのサイトの手順通りやっていけば良いんじゃないかなーと、さらっとしか読んでいません。私は途中で脱線して自分で書いてしまいました。
あ、PHP5.5はfinaryブロックが使えるので$dbh = null;って行はそこに収めるのがいいのかなという感じですかね。多分。

これで個人的にはXAMPPの代替は一段落です。あとでフレームワークとか入れてみたいですね。
…(・ω・ )あ、Perl入れてないわ。これも後でいいか。

カテゴリー: Windows | タグ: , | コメントする

Apacheの練習(その2のおまけ) – PHP5.5を入れてみる

大した話ではないのですが、書き忘れたので。
httpd.conf

LoadModule php5_module d:/pg/php/php5apache2_4.dll

と書いて、嬉々としてApacheを再起動したらノートン先生がphp5apche2_4.dllをすごい勢いで隔離しました(・ω・ )
正規のところからダウンロードしたし、誤検知だろうとそっとセーフリストへ。最近のセキュリティソフトは開発者に厳しい(?)ような話を聞いた気がしますが、公式のモジュールを蹴っ飛ばすほどとは思いませんでした。そのうち対応してくれるんですかね。

カテゴリー: Windows | タグ: , | コメントする

Apacheの練習(その2) – PHP5.5を入れてみる

例によってAdminWebのApache入門を参考に進めました。今回はPHP利用のための設定のページを参考にします。
しかし、これPHP5.5.4を設置したのですが、大した苦労もなくphpinfo()を呼ぶところまで出来てしまい拍子抜けでした。もっと苦労するのかと思っておりましたので(・ω・ )
引っかかった点はモジュールがphp5apache2_4.dllしかなかったところと、phpinfo()の出力結果でエラーが出たところです。

モジュールはWindowsの場合DLLファイルで提供されていて、上記の通りphp5apache2_4.dllしか見当たらなかったのですが、このファイル名の”2_4″の部分ってApacheのバージョンを指してると思うんですよね。今回は最初からApache2.4を使用してたから良いのですが、これが2.2だったらどうなっていたのかなと。これは良く分からないんですけど、2.2系で使いたかったらソースを拾ってきて自分でビルドしましょうということなんでしょうか。
# 頑張れば出来ないことはないようです。でも、これに手を出すならUNIX系OSを用意して使いたくなる気がします(・ω・ )

phpinfo()のエラーは、

Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.

と言う感じでした。タイムゾーンが設定されてないぞっと(・_・)
php.iniを追っても良かったのですが、エラーメッセージで検索をかけたら即ヒットしたのでそれを参考にしました。
date.timezoneの設定をする。
参考にした記事はMac bookでしたが、やることは同じです。

date.timezone = Asia/Tokyo

として、終了。

最後にちょっと飛んで、PHPインストールと初期設定のページにある、マジッククオートの設定。こちらはPHP5.4以降は削除されているので、設定自体が出来ません。これを確認して、ベースとなるPHPのインストールはひとまず終わりました。

他の拡張機能やフレームワークやまだやってないデータベースを導入すると、また一悶着あるのかなぁと言う気がしますが、今回はここまでで(・ω・ )

カテゴリー: Windows | タグ: , | コメントする

Apacheの練習(その1の補足)

先日、エイリアスの設定方法で、Allowディレクティブが上手く効かなかった事を書きました。

アクセスすることは出来たんで、スルーして先に進もうかなとも思ったのですが、結局気になって調べることにしました。
検索をかけて、最初に見つかったのは
Apacheのアクセス制御をちゃんと理解する。
で、AllowディレクティブやOrderディレクティブ等の使い方についてとても細かく書かれていました。
ついでに将来来るであろうApache3.0についてもおまけで書いてあり、その時はDSLとやらが使えるようになるみたいだよということも書かれていました。
# DSLについてはよく調べてないのでわかりませんが、スクリプト言語みたいなのが使えるみたいですね

Allowディレクティブたちについては大体わかったんだけど、結局うまくアクセスできなかった理由がよくわかりません。

次に、Upgrading to 2.4 from 2.2というページを見つけました。その中に、Run-Time Configuration Changesと言う項目があって、まぁ、英語なんですけど何とか読んでみると、

「後方互換性のためにmod_access_compatって言うモジュールで残すけど、今後はmod_authz_hostモジュールを使ってよ」

というようなことが書いてあって、Allowディレクティブなどの代わりに拡張されたRequireディレクティブを使って記述する例が書かれていました。httpd.confを見るとmod_access_compatモジュールはちゃんとロードされていたので、非推奨であることは確かですが、アクセスできなかった理由にはならなさそうです。

…?(・ω・ )

あ(・_・)
混在させてるのがまずいんじゃね?
ということで、ルートディレクトリをOrderディレクティブとAllowディレクティブで書き直し、エイリアス側もAllowディレクティブで書いてみました。おお、アクセス成功(・_・)ノ

若干腑に落ちないところもありますが、旧式の書き方でもアクセスできました。このへんまだまだ奥が深そうです。まぁ、非推奨になってることには変わりないので、Requireディレクティブで進めてみようと思います。

カテゴリー: Windows | タグ: | コメントする

Apacheの練習(その1)

ローカルではWindows環境のXAMPPで楽をしていたのですが、PHPをバージョンアップしてやろうとして失敗。phpAdminのインストールとかも無理やり詰め込んで無理やり動かした感があり、これは自分でコントロールできるようにならないとダメだという結論に。自分でやるのも不安なんですけど…。まぁ、公開する本番環境をこしらえるわけではないので、大丈夫でしょう(・ω・ )

Apache入門
http://www.adminweb.jp/apache/
こちらのサイトを参考にまずはApacheを自力でインストールを試みます。WindowsならIISだろと言う意見が多いようなんですけど、借りてるレンタルサーバーがFreeBSDでApache動かしてるのでそれにならうことにしました。このサイトでは2.2系列を例にとっているのですが、2.4系列が最新のようなのでそっちで試してみることに。

PHPは5.5を試したいので、VC11のランタイムコンポーネント版(Visual C++ Redistributable for Visual Studio 2012 Update 3)をダウンロード。ランタイムコンポーネントはいつの間にか先にインストールされていたのでそれでよしとしました。なければこちらから入手できるようです。

展開して適当なディレクトリにコピー。入門サイトにならってD:/pg/Apache/Apache24/にしました。設定ファイルのhttpd.confは参考例の2.2系列と全然違うということはなかったので、多少の違いは置いておいて指示に従って変更してインストール。起動してみると正常に動いているようです。

基本設定の項を読み流して、コンテンツの設置の項へ。ここでハマりました。エイリアスの設定がうまくいきません。

<Directory "D:/Apache Group/data">
Allow from all
</Directory>

と書いてやったのですが、

Forbidden

You don’t have permission to access /data/hello.html on this server.

となんだかよく見るエラーを表示してしまいました。多分、例題は合ってるだろうと勝手に予想して、ファイルのアクセス権限などを調べることに。…そもそもDirecotryRootの方も権限は同じだった…。Apacheのサービスはどういう権限でファイルに触ってるんだ?と疑問を持って泥沼に。結局これは関係ないという結論でhttpd.confのディレクションの書き方が間違ってるということに。試しに<Directory />

Require all denide

をコメントアウトしてみると、上手く表示されてしまいました。そういう訳でエイリアスのディレクションに

Require all granted

を追加してやってルートの方のコメントアウトを戻してあげると表示されました。
ここまでやって夜が明けたのでこの辺にしておきます。まぁ、今使ってるレンタルサーバーのプランではhttpd.confは自分でいじくれません。VPSやクラウドを使うようになるまでにわかるようにしておけば良いかということで(・_・)

# .htaccessは早々に使うことになるからその辺は勉強しないといけないんでしょうけど…
# 簡単にセキュリティホールになるからどうしてもガチガチにしたいんですよね(ーー;

カテゴリー: Windows | タグ: | コメントする

さくらのレンタルサーバでWordPressとWAFの共存

さくらのレンタルサーバではWAF(ウェブアプリケーションファイアウォール)が利用できるので、これを有効にしてみた。

そしたら更新できなくなった(・_・)

WAFは一部のCMS(コンテンツ管理システム)と仲が悪いことが知られている、ようだ。
Wordpressのダッシュボードもご多分に漏れなかったらしい。

無効に戻して更新を試してみたら、当然出来るようにはなったのだが、せっかくあるセキュリティの機能をないがしろにするのはもったいない。現にWordpressに対する攻撃を一部防いでいたログが残っていた。せっかくなので共存させたいなと思っていたら、以下の様な記事を発見。

さくらのレンタルサーバーでWordPressを運用する時のWAFの設定と注意点
http://gatespace.jp/2013/07/25/sakura-wordpress-waf/

まさにピッタリの内容。早速利用させて頂いた。
# ロリポップでの方法を参考にしたとのことなのだが…その記事は徳丸氏の書かれた記事だった
# またこの人か。なんなのこの人、天才なの?(・_・)

別段難しい設定はなく、記事の手順通りに実行して終了。
幾分ましになったのではないだろうか。

この方法…閲覧用ドメインと管理用ドメインとの2つにわけないといけないのだが、これはしょうがないのだろうか。一番いいのはWAFがCMSの処理を正常と判別してくれることなのだろうけど、これは気の長い話になりそうである(・ω・ )

カテゴリー: WordPress | タグ: , | コメントする

Google Chromeの拡張機能に関する安全性の担保

他のウェブサイトから拡張機能を追加する(ウェブストアからのダウンロードを推奨する文書)
https://support.google.com/chrome_webstore/answer/2664769?hl=ja&p=crx_warning

実態は主にJavascriptで記述されている。
https://developer.chrome.com/extensions/index.html

Google Chrome、悪質な拡張機能を「マルウェア」として警告(IT media 2013/4/18)
http://www.itmedia.co.jp/news/articles/1304/18/news080.html

詐欺データを追加する悪質なブラウザアドオン(シマンテック 2012/11/30)
http://www.symantec.com/connect/ja/blogs-25

過去、騒がれたこともあるようだが最近は落ち着いている模様。
セキュリティソフトウェアベンダーも認識している上、ブラウザ自体のあんぜんせいもこうじょうしt

カテゴリー: ブラウザ | タグ: , | コメントする

PHPにおけるパスワードの暗号化について その2

色々考えたけど、結局良く分からなかった。

ストレッチングの重要性はともかくとして、コストと安全性のトレードオフについては目的に応じて自分の勘で判断するしか無いという微妙な結論に…(・_・;)
crypt()のコスト=ストレッチングであるか否かはわからんちんヽ(・_・)ノ
# ソースを読むべき。いつか、そのうち、きっと

QA@ITと言うところで質問してみたところ、親切にも二人も回答して下さった方がいた。

PHPでのパスワードの暗号化について
http://qa.atmarkit.co.jp/q/2975?_nid=1255

# 一人目の回答者さんには今頃気がついて大変失礼なことをしてしまいました

回答として書いてくださった一人目の回答者さんからは、ストレッチングは単なる時間稼ぎじゃないんだよということをソース付きでお教え頂きました。
Key stretching
http://en.wikipedia.org/wiki/Key_stretching

しかし、この辺の事情を加味したとして、将来的にアルゴリズム換えますといった保守を考えると、スライドのように自作するのはやっぱりなんとなく嫌。
# 回答者さんのおっしゃっている通り、文字通りのサンプルであるなら言わずもがな

二人目の回答者さんはコメントでご回答下さいました。曰く、password_hash()password_verify()を使うのがよろしいのではと。これらの関数はPHP 5.5からの実装になりますが、互換ライブラリが提供されており、導入出来れば同じように使うことが出来そうです。

ライブラリの導入はどうやるんだ?(・_・)
と思っていたら何のことはない普通にPHPのソースだったので、私の使っているさくらサーバーでも、自分のコードと一緒にサーバに置いてあげれば使えそう。

カテゴリー: プログラミング | タグ: , | コメントする

PHPにおけるパスワードの扱いについて

Webアプリケーションでログインの機能をつける時、大抵ユーザーIDとパスワードを使う。アプリケーション内でのユーザーのなりすましを防ぐために、パスワードは丁重に扱わなくてはならない。

と、言うところまでは言葉では分かったが、実際どうすればいいのかがいまいち分からなかった。とりあえず、平文のままパスワードをデータベースの中に放り込むのは論外として、じゃあ暗号化だなということで調べ始めた。

すると、手軽な方法でPHPのネイティブな関数にcrypt()というものがあることが分かった。

PHP: crypt – Manual
http://www.php.net/manual/ja/function.crypt.php

第1引数で指定した文字列(パスワード)を第2引数で指定されたsalt(これで使用するハッシュ関数一緒に指定する)でハッシュした文字列を得るということでこれを「暗号化されたパスワード」としてデータベースに保存すればOKと言う事になる。

PHP: パスワードのハッシュ – Manual
http://www.php.net/manual/ja/faq.passwords.php

関連のこのページを読んで見るとハッシュアルゴリズムにはBlowfishが良いだろうというようなことが書いてあったので、それを使えばいいのかなとなんとなく理解した。つまるところ他のMD5やSHA1よりましであるようだ程度の認識だ。この関数で使用出来る用意されたアルゴリズムはBlowfish以上のものだとSHA256とSHA512で選択肢はそんなにない。利用できるかは設定によるようだが…とりあえず、あとは危険でないsaltの指定方法を探したのだがここでハマった。

結論としてはsaltについては十分に長くてそれなりに複雑であればなんでもいい。アカウントごとにsaltを用意してあげる必要がある。そしてsaltをハッシュとともに保存しておく。ということは分かった(時間がかかったが)。

問題はそれを調べる過程で本当にcrypt()を使っていいのかという疑問を持ってしまったことだ。

Webアプリでパスワード保護はどこまでやればいいか
http://www.slideshare.net/ockeghem/how-to-guard-your-password

セキュリティ関連で著名な方らしい、徳丸さんという方のスライドである。この中で「ストレッチング」と言うハッシュの計算を相当数繰り返す方法をとるべきであると主張されている。例のコードではhash()と言う関数でSHA256が使われ、それが1,000回繰り返されていた。

crypt()のSHA256の説明には「’rounds=<N>$’ で始まる場合は、数値 N がハッシュループの実行回数を表します。」と書いてあったのでこれがストレッチングに相当するのか?

http://www.akkadia.org/drepper/SHA-crypt.txt

このへん見るとそうっぽいんだけどそもそもこれ、UNIXの実装の話だし。…そうだとするとわざわざ自作する必要性がよくわからなくなる。

カテゴリー: プログラミング | タグ: , | コメントする