Category Archives: Security

INTER-Mediator Ver.6をCentOS 8にインストールする

まだ正式に出していないINTER-Mediator Ver.6ですが、色々なOSにインストールしながら、インストール時のポイントを探っているところです。以前に、Ubuntu Server 18.04、CentOS 7へのインストールを紹介しましたが、今回は、CentOS 8です。

インストールに使ったインストーラは「CentOS-Stream-x86_64-dvd1.iso」というファイル名のISOファイルで、Virtual Box上で展開しました。同時期にはStreamでないものとして「CentOS-8-x86_64-1905-dvd1.iso」が配布されています。Virtual Box側では、ネットワーク1に「NAT」、ネットワーク2に「ホストオンリーネットワーク」を設定しています。ホストオンリー側の設定は、192.168.56.0/24の一般的な設定を適用しています。インストーラの最初の方で、Software SelectionではServer with GUIでなく、Serverを選択してインストールしました。

インストール後、/etc/system-releaseを確認すると、「CentOS Linux release 8.0.1905 (Core) 」でした。ネットワーク設定を行い、ISOファイルを指定して、後は原則そのままインストールを進めました。なお、rootのパスワードは設定せず、管理者権限のユーザーadminを登録して進めました。以下、adminが出てくれば、sudo可能なユーザーとみなしてください。

インストール直後のネットワークの設定

インストール直後はsshでの接続もできないので、VirtualBoxの場合はVMのウインドウでまずはログインをして、ネットワークの設定を行ます。「ip a」や「nmcli connection」で、どんなデバイスがあるかを確認します。通常、NAT側はenp0s3、ホストオンリーネットワーク側はenp0s8になっていると思います。それぞれ、以下のようにコマンドを入れて設定を行ます。ホストオンリー側は、192.168.56.91という固定IPにします。もちろん、設定したセグメント内であれば違ってもOKです。DNSに8.8.8.8を設定するのは嫌われるかもしれませんが、ホストオンリーネットワーク側なので、DNS利用することはほとんどないかもしれません。そして、2つのネットワークデバイスに大して、connection.autoconnectの値をyesにします。こうすればNAT側はDHCPから設定を行い、VMからインターネットにアクセスが可能です。また、ホストオンリーネットワーク側も同様なプロパティをyesにすることで、起動時にデバイスが動作するようになります。最後にホスト名の設定が行われていますが、外部に公開するサーバーならこの方法あるいは別の方法でホスト名は必ず設定すると思われます。この後のApacheの設定でホスト名が決まっていない場合は警告を出して設定ファイルの読み込みがなされず、動作しない場合もあります。なので、実験用にVMを起動する場合も適当なホスト名を必ず設定してください。以下のサンプルをそのまま使ってもらってもいいですが、このcentos.msyk.netはIPの正引き設定はしていません。なお、CentOS 7では「systemctl restart network」と入れて設定を反映させていたのですが、CentOS 8ではnetworkサービスに対するsystemdの設定ファイルが用意されていないので、このコマンドを入れても意味はありません。設定後、検証もかねてすぐにリブート(sudo reboot)するのが良いでしょう。

nmcli connection
ip a
nmcli connection modify enp0s8 ipv4.addresses 192.168.56.92
nmcli connection modify enp0s8 ipv4.gateway 192.168.56.1
nmcli connection modify enp0s8 ipv4.method manual
nmcli connection modify enp0s8 ipv4.dns 8.8.8.8
nmcli connection up enp0s8
nmcli connection modify enp0s3 connection.autoconnect yes
nmcli connection modify enp0s8 connection.autoconnect yes
nmcli general hostname centos.msyk.net

再起動をして、コマンド入力と同様なネットワーク設定になっていることを「ip a」コマンド等で確認します。ちなみにip aは「ip address show」の省略形です。再起動後は正しく設定されていれば、sshで接続できます。CentOS 8は、sshdが最初から起動していますが、ネットワーク設定ができていないので、実質的にはssh接続できないという状態です。上記の作業がsshを可能にする設定とは違います。

再起動後、sshで接続するなどして、dnf updateコマンドを打ち込みます。ネットワークに接続されているので、アップデート等の作業を進めます。

コマンドの収集

ネットワークの設定ができれば、ターミナル等からsshで接続して、以下のコマンドを入れます。まず、最初に、よく利用するコマンドを入れておきます。以下、gitは必須ですが、他に、nmapなど自分の用途に合わせて入れましょう。なお、zip、unzip、lsof、nanoは最初から入っています。

sudo yum install -y git nmap

SELinuxに対応する

ここで1つ重要な設定があるので、最初に行ましょう。CentOS 8は、既定値でSELinuxがアクティブになっていて、高いセキュリティを確保していることになっています。しかしながら、Apacheがデータベースサーバにネットワーク経由で接続することが許可されていないなど、かなり制限は強くなります。また、INTER-Mediator Ver.6より内部で複数のサーバーが動くようなアーキテクチャになっており、SELinuxの初期状態のままでは動作が正しく行われません。

そのため、SELinuxをオフにするか、一部のポリシーを緩めるかのどちらかの設定をしなければなりません。ポリシーを緩める方法は、この手順の後の方で説明しています。

テストや試用の上では、SELinuxをオフにすることで対応するのが手軽な方法です。SELinux自体をオフにしたい場合は、次のように作業します。SELinuxの状態をみるには「getenforce」コマンドを入れますが、「Enforcing」と次の行に出てくれば、設定されていることになります。そして、以下のコマンドを入れることで、SELinuxは基本的にオフになります。

sudo setenforce 0

上記コマンドを入れて、「getenforce」を実行すると「Permissive」と表示されるので、これにより制限が設定されていても実施できるようになったことを示しています。ただし、再起動すると、またオンの状態になります。再起動後にもオフの状態にしたいなら、/etc/selinux/configファイルの「SELINUX=enforcing」を、「SELINUX=disabled」にして再起動してください。このファイルは間違えた状態にすると起動しなくなるので、記述の変更は慎重に行ってください。

Apache2のインストールとFirewallの設定

Apache2のインストールは非常にシンプルです。以下のようにコマンドを入れれば、インストールされてプロセスが稼働します。再起動後にも起動できるように、enableサブコマンドも入れておきます。

sudo dnf -y install httpd
sudo systemctl enable httpd
sudo systemctl start httpd
sudo systemctl status httpd

これで、ブラウザからチェックと思っても、まだページは出ません。CentOS 7は、ファイアウォールの設定が最初からなされているので、要するにポートに穴を開けないといけません。ネットワークアダプタは、publicというゾーンを利用するので、そこで、httpとhttpsについてのサービスを透過することを以下のように設定します。一部、確認のためのコマンドも入っています。設定するとすぐに機能するはずなので、VirtualBoxでこれまで通りの設定を行っていれば、ホストマシン側でWebブラウザからhttp://192.168.56.92に接続すれば、Apacheのページが見えます。なお、DHCPのクライアント処理とsshは最初から通す設定になっています。

sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-services --zone=public
sudo firewall-cmd --add-service=http --zone=public --permanent
sudo firewall-cmd --add-service=https --zone=public --permanent
sudo firewall-cmd --reload 
sudo firewall-cmd --list-services --zone=public
# このように表示される dhcpv6-client http https ssh

PHPのインストールと設定

続いてPHPのインストールです。標準のPHPは7.2です。執筆時点で7.2というのは通常は受け入れられるバージョンだと思われますが、今後、PHPのバージョンが進むとCentOS 7のように別のレポジトリに頼る必要が出るかもしれません。ですが、まずは、標準のPHPを利用することにします。以下のようにコマンドを入れます。すぐに利用したいのなら、Apache2を「sudo systemctl restart httpd」で再起動しておきます。また、この状態でphpコマンドにパスが通ります。なお、INTER-Mediator Ver.6は以下のパッケージの追加で動作可能な模様ですが、チェック漏れがあれば、ここで更新します。チェック漏れがありそうなら教えてください。よろしくお願いします。

sudo dnf install -y php php-cli php-common php-bcmath php-gd php-intl php-json php-ldap php-mbstring php-pdo php-xml php-mysqlnd php-pgsql php-process

composerのインストール

PHPのライブラリ管理ツールにINTER-Mediatorは対応しています。しかしながら、composerを動かさないと、必要なライブラリを取ってきません。なお、npmも利用しますが、npmはcomposerがインストールするのでセットアップは原則的には不要です。セットアップは以下のコマンドを入れます。最初のcd以外は、composerのページに記載された通りですが、composerのページの内容は随時アップデートがあるので、以下のコードのコピペはしないで、composerのページのコードをコピーしてください。

cd
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'a5c698ffe4b8e849a443b120cd5ba38043260d5c4023dbf93e1558871f1f07f58274fc6f4c93bcfd858c6bd0775cd8d1') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

なお、composerもコマンドとしてそのまま打ち込んで利用できるようにしたいので、以下のように作業を行ます。前述の作業では、composer.pharというファイルがホームディレクトリのルートにできて、そのまま動かせるのですが、以下のようにコマンドを入れれば、composerコマンドとして普通にコマンド入力できるようになります。

sudo mv composer.phar /usr/local/bin
cd /usr/local/bin
sudo ln -s composer.phar composer

MySQLのインストール

データベースとしてインストールするのはここではMySQLのみ紹介しましょう。他のデータベースについては、別のサイトをなどをご覧ください。MySQLもPHPと同様に標準のレポジトリにあるパッケージを利用してインストールします。例えば、以下のようにして、インストールを行い、稼働します。

sudo dnf install -y mysql-server
sudo systemctl start mysqld
sudo systemctl enable mysqld

この方法でセットアップすると、MySQLのrootユーザーのパスワードが設定されなお応対になります。そこで、以下のコマンドを入れて、rootのパスワードを設定します。最初に、上記の仮に設定されたパスワードを入れ、その後に新しいパスワードを入れます。パスワードの検証をするかどうか、パスワードのポリシーの強度はどうするかを対話式に答えます。テストするだけの場合は検証しないか、するとしてもLOWを選択しておきます。その後に新しいrootのパスワードを入力します。もちろん、rootのパスワードはメモしておきましょう。

mysql_secure_installation

INTER-Mediatorのインストールとセットアップ

ここで、やっとINTER-Mediatorの登場です。まず、準備として、以下の作業を行ます。ここでは、Apache2はapacheユーザーで稼働しているものとします。

まず、apacheユーザーのホームディレクトリに、apacheユーザーが書き込みできるようにしておきます。インストール当初はrootユーザーにしか書き込み権限がありません。これは、node.jsのプロセス起動のためのユーティリティであるforeverの稼働のための条件です。

cat /etc/passwd|grep apache
# 出力例 apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
cd /usr/share
sudo chown -R apache httpd

次に、Apache2のドキュメント領域について、apacheユーザーとadminユーザーに書き込み権限を与えておきます。apacheユーザーについては読み出し権限で十分とも言えるのですが、オーナーをApache2のオーナーにして、グループ側にはログインするユーザーに応じたグループ、つまりコンテンツをいじる側のアカウントを指定するようにしました。通常はグループを新たに作るのが良いと思われますが、以下のコマンドは管理者のグループwheelを指定しています。ドキュメントルートは、/var/www/htmlですが、このwww以下を作業しやすいように、アクセス権を設定しています。なお、以下のコマンドは初期状態でファイルがないことを仮定しています。ファイルがある場合は、3つ目のコマンドについては、775ではなくg+rwでおそらく問題なく行くでしょうけど、既にファイルをコピーしてしまった場合は一概には言えない面もあるので、アクセス権について状況に応じて改めて見直してください。

cd /var
sudo chown -R apache:wheel www
sudo chmod -R 775 www

そして、以下のようにコマンドを入れて、INTER-Mediatorをインストールしてください。その後、composerコマンドを稼働して、しばらく待ちます。これでインストールは終了です。

cd www/html
git clone https://github.com/INTER-Mediator/INTER-Mediator
cd INTER-Mediator/
composer update

SELinuxのポリシーファイルは、dist-docs/selinuxディレクトリに用意しています。INTER-Mediatorをインストール後、次のようにコマンドを入れて、ポリシーをインストールします。INTER-Mediatorディレクトリがカレントであると仮定しています。これにより、即座にポリシーが適用され、再起動後も設定が継続します。なお、ここでのsemoduleコマンドを利用できるようにするために、policycoreutils-pythonパッケージのインストールも必要になります。

sudo yum install -y policycoreutils-python
cd dist-docs/selinux
sudo semodule -i inter-mediator.pp

INTER-Mediatorのファイルのアップロード機能を使うなど、Webアプリケーションからの書き込みがあるような場合もあります。その場合、前述のポリシーファイルだけでは許可は足りませんので、例えば、/var/www/filesにアップロードされたファイルを展開するような場合には、以下のようにコマンドを入力します。最初のコマンドが許可ポリシーを付与するもので、2つ目は設定確認、3つ目はファイルやフォルダを設定をsemanageコマンド通りにするとういうものです。

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/files(/.)?"
sudo semanage fcontext -l | grep files
sudo restorecon -R /var/www/files

サンプルデータ用のスキーマは以下のようにして読み込みます。なお、MySQLのルートのパスワードを変更する時にお気づきだと思いますが、ポリシーをHIGHTなどにすると複雑なパスワードを設定しないといけなくなります。サンプルについては、ユーザーを作るコマンドも入っています。ROWを選択していれば、サンプルスキーマはそのまま使えます。

cd /var/www/html/INTER-Mediator/dist-docs/
mysql -uroot -p < sample_schema_mysql.txt

これを読み込んだ後に、http://192.168.56.92/INTER-Mediator/samples を参照すると、サンプルの一覧が出てきますので、郵便番号検索などのサンプルをご覧ください。Ver.6の新機能の1つであるサーバーサイドでのNode.jsによるサービスサーバーについても、自動的に稼働するはずです。

一通りの手順は以上です。色々、状況によって違う面もあるかもしれませんが、訂正やバリエーションがあれば、このページに追記します。レポート歓迎します。

INTER-Mediator Ver.6をCentOS 7にインストールする

まだ正式に出していないINTER-Mediator Ver.6ですが、色々なOSにインストールしながら、インストール時のポイントを探っているところです。以前に、Ubuntu Server 18.04へのインストールを紹介しましたが、今回は、CentOS 7です。

インストールに使ったインストーラは「CentOS-7-x86_64-Minimal-1908.iso」というファイル名のISOファイルで、Virtual Box上で展開しました。Virtual Box側では、ネットワーク1に「NAT」、ネットワーク2に「ホストオンリーネットワーク」を設定しています。ホストオンリー側の設定は、192.168.56.0/24の一般的な設定を適用しています。インストール後、/etc/system-releaseを確認すると、「CentOS Linux release 7.7.1908 (Core)」でした。ネットワーク設定を行、ISOファイルを指定して、後は原則そのままインストールを進めました。なお、rootのパスワードは設定せず、管理者権限のユーザーadminを登録して進めました。以下、adminが出てくれば、sudo可能なユーザーとみなしてください。

インストール直後のネットワークの設定

インストール直後はsshでの接続もできないので、VirtualBoxの場合はVMのウインドウでまずはログインをして、ネットワークの設定を行ます。「ip a」や「nmcli connection」で、どんなデバイスがあるかを確認します。通常、NAT側はenp0s3、ホストオンリーネットワーク側はenp0s8になっていると思います。それぞれ、以下のようにコマンドを入れて設定を行ます。ホストオンリー側は、192.168.56.91という固定IPにします。もちろん、設定したセグメント内であれば違ってもOKです。DNSに8.8.8.8を設定するのは嫌われるかもしれませんが、ホストオンリーネットワーク側なので、DNS利用することはほとんどないかもしれません。そして、2つのネットワークデバイスに大して、connection.autoconnectの値をyesにします。こうすればNAT側はDHCPから設定を行い、VMからインターネットにアクセスが可能です。また、ホストオンリーネットワーク側も同様なプロパティをyesにすることで、起動時にデバイスが動作するようになります。最後にホスト名の設定が行われていますが、外部に公開するサーバーならこの方法あるいは別の方法でホスト名は必ず設定すると思われます。この後のApacheの設定でホスト名が決まっていない場合は警告を出して設定ファイルの読み込みがなされず、動作しない場合もあります。なので、実験用にVMを起動する場合も適当なホスト名を必ず設定してください。以下のサンプルをそのまま使ってもらってもいいですが、このcentos.msyk.netはIPの正引き設定はしていません。

nmcli connection
ip a
nmcli connection modify enp0s8 ipv4.addresses 192.168.56.91
nmcli connection modify enp0s8 ipv4.gateway 192.168.56.1
nmcli connection modify enp0s8 ipv4.method manual
nmcli connection modify enp0s8 ipv4.dns 8.8.8.8
nmcli connection up enp0s8
nmcli connection modify enp0s3 connection.autoconnect yes
nmcli connection modify enp0s8 connection.autoconnect yes
nmcli general hostname centos.msyk.net
systemctl restart network

ここで再起動をして、コマンド入力と同様なネットワーク設定になっていることを「ip a」コマンド等で確認すると良いでしょう。ちなみにip aは「ip address show」の省略形です。再起動後は正しく設定されていれば、sshで接続できます。CentOS 7は、sshdが最初から起動していますが、ネットワーク設定ができていないので、実質的にはssh接続できないという状態です。上記の作業がsshを可能にする設定とは違います。

再起動後、sshで接続するなどして、yum updateコマンドを打ち込みます。ネットワークに接続されているので、アップデート等の作業を進めます。

コマンドの収集

ネットワークの設定ができれば、ターミナル等からsshで接続して、以下のコマンドを入れます。まず、最初に、よく利用するコマンドを入れておきます。以下、git、zip、unzipは必須ですが、他に、nanoなど自分の用途に合わせて入れましょう。例えば、プロセスやポートの情報を得るためのlsofや、開いているポートを確認するnmapあたりは、このままパッケージ名として記述すればOKです。

sudo yum install -y git zip unzip
sudo yum install -y nano lsof nmap   #  こちらは参考まで

SELinuxに対応する

ここで1つ重要な設定があるので、最初に行ましょう。CentOS 7は、既定値でSELinuxがアクティブになっていて、高いセキュリティを確保していることになっています。しかしながら、Apacheがデータベースサーバにネットワーク経由で接続することが許可されていないなど、かなり制限は強くなります。また、INTER-Mediator Ver.6より内部で複数のサーバーが動くようなアーキテクチャになっており、SELinuxの初期状態のままでは動作が正しく行われません。

そのため、SELinuxをオフにするか、一部のポリシーを緩めるかのどちらかの設定をしなければなりません。ポリシーを緩める方法は、この手順の後の方で説明しています。

テストや試用の上では、SELinuxをオフにすることで対応するのが手軽な方法です。SELinux自体をオフにしたい場合は、次のように作業します。SELinuxの状態をみるには「getenforce」コマンドを入れますが、「Enforcing」と次の行に出てくれば、設定されていることになります。そして、以下のコマンドを入れることで、SELinuxは基本的にオフになります。

sudo setenforce 0

上記コマンドを入れて、getenforceコマンドを実行すると「Permissive」と表示されるので、これにより制限が設定されていても実施できるようになったことを示しています。ただし、再起動すると、またオンの状態になります。再起動後にもオフの状態にしたいなら、/etc/selinux/configファイルの「SELINUX=enforcing」を、「SELINUX=disabled」にして再起動してください。このファイルは間違えた状態にすると起動しなくなるので、記述の変更は慎重に行ってください。

Apache2のインストールとFirewallの設定

Apache2のインストールは非常にシンプルです。以下のようにコマンドを入れれば、インストールされてプロセスが稼働します。再起動後にも起動できるように、enableサブコマンドも入れておきます。

sudo yum -y install httpd
sudo systemctl enable httpd
sudo systemctl start httpd
sudo systemctl status httpd

これで、ブラウザからチェックと思っても、まだページは出ません。CentOS 7は、ファイアウォールの設定が最初からなされているので、要するにポートに穴を開けないといけません。ネットワークアダプタは、publicというゾーンを利用するので、そこで、httpとhttpsについてのサービスを透過することを以下のように設定します。一部、確認のためのコマンドも入っています。設定するとすぐに機能するはずなので、VirtualBoxでこれまで通りの設定を行っていれば、ホストマシン側でWebブラウザからhttp://192.168.56.91に接続すれば、Apacheのページが見えます。なお、DHCPのクライアント処理とsshは最初から通す設定になっています。

sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-services --zone=public
sudo firewall-cmd --add-service=http --zone=public --permanent
sudo firewall-cmd --add-service=https --zone=public --permanent
sudo firewall-cmd --reload 
sudo firewall-cmd --list-services --zone=public
# このように表示される dhcpv6-client http https ssh

PHPのインストールと設定

続いてPHPのインストールです。当然ながら、PHP 7.1以上を得るためには標準のレポジトリではだめなので、remiのレポジトリを利用します。例えば、以下のようにコマンドを入れます。この例では、Ver.7.3系列のファイルがインストールされますが、remiのレポジトリは執筆時点では7.0〜7.4まで揃っていました。別のレポジトリを使う場合のレポジトリ指定方法は、–enablerepo=remi,remi-php73をパラメータに指定するなど、色々流儀があるとは思いますので、この方法に限らないとは思いますが、ともかく、PHPのバージョンを混在することは避けましょう。最後にApacheを再起動しておきます。そうしないと、PHPの動作が組み込まれていない状態のままになります。なお、INTER-Mediator Ver.6は以下のパッケージの追加で動作可能な模様ですが、チェック漏れがあれば、ここで更新します。チェック漏れがありそうなら教えてください。よろしくお願いします。

sudo yum -y install http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
sudo yum --enablerepo=remi-php73 install -y php php-cli php-common php-bcmath php-gd php-intl php-json php-ldap php-mbstring php-pdo php-xml php-mysqlnd php-pgsql php-process
sudo systemctl restart httpd

phpコマンドを-vオプションをつけて実行して、念のために欲しいバージョンのPHPが稼働しているかどうかを確認しましょう。最後のphp -iで動作確認やモジュールが登録されているかを確認できますが、コマンドラインに大量に行が流れるのでちょっと見づらいかもしれません。

php -v
php -i

composerのインストール

PHPのライブラリ管理ツールにINTER-Mediatorは対応しています。しかしながら、composerを動かさないと、必要なライブラリを取ってきません。なお、npmも利用しますが、npmはcomposerがインストールするのでセットアップは原則的には不要です。セットアップは以下のコマンドを入れます。最初のcd以外は、composerのページに記載された通りですが、composerのページの内容は随時アップデートがあるので、以下のコードのコピペはしないで、composerのページのコードをコピーしてください。

cd
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'a5c698ffe4b8e849a443b120cd5ba38043260d5c4023dbf93e1558871f1f07f58274fc6f4c93bcfd858c6bd0775cd8d1') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

なお、composerもコマンドとしてそのまま打ち込んで利用できるようにしたいので、以下のように作業を行ます。前述の作業では、composer.pharというファイルがホームディレクトリのルートにできて、そのまま動かせるのですが、以下のようにコマンドを入れれば、composerコマンドとして普通にコマンド入力できるようになります。

sudo mv composer.phar /usr/local/bin
cd /usr/local/bin
sudo ln -s composer.phar composer

MySQLのインストール

データベースとしてインストールするのはここではMySQLのみ紹介しましょう。他のデータベースについては、別のサイトをなどをご覧ください。なお、PostgreSQLは標準のパッケージにあるpostgresql-serverを利用できます。また、SQLiteはsqliteというパッケージ名です。

MySQLもPHPと同様に標準のレポジトリにはパッケージがないので、開発元が提供しているレポジトリを利用してインストールします。例えば、以下のようにして、インストールを行い、稼働します。

sudo yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-7.noarch.rpm
sudo yum search mysql
sudo yum install mysql-community-server -y
sudo systemctl start mysqld
sudo systemctl enable mysqld

この方法でセットアップすると、MySQLのrootユーザーのパスワードが自動的に設定されます。まず、そのパスワードを以下のようにして取り出します。つまり、ログにrootのパスワードが残っているということです。以下の例だと、「!#si2Zx;!.CG」がパスワードです。

sudo cat /var/log/mysqld.log | grep root
# 例えば次のように表示 2019-11-12T05:38:49.015480Z 1 [Note] A temporary password is generated for root@localhost: !#si2Zx;!.CG

続いて、以下のコマンドを入れて、rootのパスワードを再設定します。最初に、上記の仮に設定されたパスワードを入れ、その後に新しいパスワードを入れます。パスワードのポリシー5.7の途中から厳しくなっていて、大文字、小文字、記号、数字を入れてある程度長い文字列でないといけません。もちろん、rootのパスワードはメモしておきましょう。

mysql_secure_installation

なお、MySQL 5.7で、INTER-Mediatorのサンプルデータベースをエラーなく読み込ませる手軽な方法は、/etc/my.cnfの最後の行に「validate-password=OFF」を追加して、MySQLを再起動させてください。サンプルのデータベースは、パスワードを単純な「password」という文字で運用させており、これだとパスワードのポリシーを満たさないためユーザー作成時にエラーになってしまいます。設定ファイルの記述でポリシーを満たさなくてもユーザー登録できるようになります。

INTER-Mediatorのインストールとセットアップ

ここで、やっとINTER-Mediatorの登場です。まず、準備として、以下の作業を行ます。ここでは、Apache2はapacheユーザーで稼働しているものとします。

まず、apacheユーザーのホームディレクトリに、apacheユーザーが書き込みできるようにしておきます。インストール当初はrootユーザーにしか書き込み権限がありません。これは、node.jsのプロセス起動のためのユーティリティであるforeverの稼働のための条件です。

cat /etc/passwd|grep apache
# 出力例 apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
cd /usr/share
sudo chown -R apache httpd

次に、Apache2のドキュメント領域について、apacheユーザーとadminユーザーに書き込み権限を与えておきます。apacheユーザーについては読み出し権限で十分とも言えるのですが、オーナーをApache2のオーナーにして、グループ側にはログインするユーザーに応じたグループ、つまりコンテンツをいじる側のアカウントを指定するようにしました。通常はグループを新たに作るのが良いと思われますが、以下のコマンドは管理者のグループwheelを指定しています。ドキュメントルートは、/var/www/htmlですが、このwww以下を作業しやすいように、アクセス権を設定しています。なお、以下のコマンドは初期状態でファイルがないことを仮定しています。ファイルがある場合は、3つ目のコマンドについては、775ではなくg+rwでおそらく問題なく行くでしょうけど、既にファイルをコピーしてしまった場合は一概には言えない面もあるので、アクセス権について状況に応じて改めて見直してください。

cd /var
sudo chown -R apache:wheel www
sudo chmod -R 775 www

そして、以下のようにコマンドを入れて、INTER-Mediatorをインストールしてください。その後、composerコマンドを稼働して、しばらく待ちます。これでインストールは終了です。

cd www/html
git clone https://github.com/INTER-Mediator/INTER-Mediator
cd INTER-Mediator/
composer update

SELinuxのポリシーファイルは、dist-docs/selinuxディレクトリに用意しています。INTER-Mediatorをインストール後、次のようにコマンドを入れて、ポリシーをインストールします。INTER-Mediatorディレクトリがカレントであると仮定しています。これにより、即座にポリシーが適用され、再起動後も設定が継続します。なお、ここでのsemoduleコマンドを利用できるようにするために、policycoreutils-pythonパッケージのインストールも必要になります。

sudo yum install -y policycoreutils-python
cd dist-docs/selinux
sudo semodule -i inter-mediator.pp

INTER-Mediatorのファイルのアップロード機能を使うなど、Webアプリケーションからの書き込みがあるような場合もあります。その場合、前述のポリシーファイルだけでは許可は足りませんので、例えば、/var/www/filesにアップロードされたファイルを展開するような場合には、以下のようにコマンドを入力します。最初のコマンドが許可ポリシーを付与するもので、2つ目は設定確認、3つ目はファイルやフォルダを設定をsemanageコマンド通りにするとういうものです。

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/files(/.)?"
sudo semanage fcontext -l | grep files
sudo restorecon -R /var/www/files

サンプルデータ用のスキーマは以下のようにして読み込みます。なお、MySQLのルートのパスワードを変更する時にお気づきだと思いますが、複雑なパスワードを設定しないといけなくなります。サンプルについては、ユーザーを作るコマンドも入っています。dist-docs/sample_schema_mysql.txtの20行目にある’password’を、例えば’password#P3’など登録可能なパスワードに変更してください。また、INTER-Mediatorのルートにあるprams.phpの25行目の’password’も、同様に書き換えておいてください。

cd /var/www/html/INTER-Mediator/dist-docs/
mysql -uroot -p < sample_schema_mysql.txt

これを読み込んだ後に、http://192.168.56.91/INTER-Mediator/samples を参照すると、サンプルの一覧が出てきますので、郵便番号検索などのサンプルをご覧ください。Ver.6の新機能の1つであるサーバーサイドでのNode.jsによるサービスサーバーについても、自動的に稼働するはずです。

一通りの手順は以上です。色々、状況によって違う面もあるかもしれませんが、訂正やバリエーションがあれば、このページに追記します。レポート歓迎します。

自動運転の実用化に違う方向性はないのだろうか?

次世代の自動運転技術に注目が集まっている。機械学習さらには人工知能の研究を強く牽引する期待が大きく、現実になればより安全な社会が実現するかもしれない。自動車業界は競争状態に入った自動運転技術を捨てるわけには行かないのかもしれないが、色々な業界がこぞって自動運転に目を向けている。一方で、新技術を危険視する向きもあり、自動運転で事故、あるいは死亡事故が発生すると、否定論が強まるなど、世論の関心も強く集めている。

技術そのものについて、「できない」と言ってしまうと、全く前に進めない。ところが「できる」とも言い切れないというのは、そこで「競争に負けた」と思われてしまうということもある。そして技術競争は熾烈になり、「あと何年で実用化」みたいな話はまことしやかに語られる。人工知能の世界でも、シンギュラリティという概念が既知のものであるのと同様、自動運転は近々実用化することになっているのが現在である。一方で、安全をどう確保するのかも大きな問題となっている。

自動運転の死亡事故をきっかけに一瞬、そうした議論が盛り上がったが、今回のアクシデントは偶発的なものと思いたい人たちと、ともかく「怖い」という漠然とした感覚から逃れられない人たちが大勢あることは改めて確認できたと思われる。事故が教訓になっていない漢字はちょっと怖いことでもある。どうすればいいという議論が進まないという点でもある意味怖い。この事故をきっかけに、何か安全性を高める方法はないだろうかと考えた。

自動運転の議論であまり出てこないと思うのが「社会インフラと連動した安全性の確保」だと以前より感じていた。現在、自動車をはじめとして色々な乗り物や人間が公道を安全に移動することができるには「信号」と言ったインフラがあるからだと考えられる。正確には、交通法規が根底にあるのだが、ともかく信号があるから安全でかつ、交通がスムーズに流れることは疑いの余地がない。自動運転にも、こうした社会インフラと連動したことができないだろうかと考えた結果、1つのアイデアが浮かんだ。それは、「舗装道路をスマート化」するということだ。

道路の舗装には、小石を含んだ砂利を利用していると思われるが、小石程度の大きさのIoTデバイスを開発し、一定の密度で舗装道路に含める。もちろん、様々なセンサーを持ち、結果は通行中のデバイスに送られる。熱に強いとか、すごく小さいとか、この『スマート砂利』には技術的な難しさは色々あるだろうが、自動運転よりはるかに容易だと想像できる。こうしたスマート砂利による舗装道路では、進路上に人間が歩いているなどのセンシングを、自動車の前の画像やセンサー等で見つける以上に正確にできることが期待できる。角を曲がった先の道路の状況が分かるかもしれない。

スマート砂利の道路は自動運転でより安全に走れるとしたら、自治体は極力スマート砂利を使った道路工事に切り替えるだろう。なんだか建築・土木系の利権を復活させるような雰囲気はちょっとげんなりするけども、自動運転について、自動車以外のことに目を向けてもいいのではないかとも思う。

FileMaker Server 16のREST APIをmacOS上で試用する場合

FileMaker Server 16をまずは手元のMacにインストールして使ってみようという方も多いだろう。ここで、FileMaker Data API(REST API)を使用する場合にPHPのcurlライブラリを使うと、「SSL: CA certificate set, but certificate verification is disabled」というエラーメッセージが返ってくる。httpsでの通信が推奨され、証明書が検証できないと通信をしないということが当然となって来ているが、とはいえ、試用なので自己署名証明書で運用できないかとPHPの様々なパラメータを触ってみたところで、上記のエラーないしは別のエラーが出る。ということで、色々調べてみると、macOSに入っているopensslのバグで、サーバー検証をしないという設定ができないということらしい。homebrewから入れ直す方法など、色々紹介されているが、何をとっても大事になってしまう。

というところで、早速、FileMakerホスティングで有名なエミックの松尾さんが、ルータとなるスクリプトを公開された(一部、修正したい箇所があったので、筆者がフォークしたものもある)。FileMaker ServerのREST APIは、httpで接続してもhttpsにリダイレクトされるが、その背後のNode.jsが開いている3000ポートを目指して接続することで、httpでも処理が進められる。ただ、ヘッダをうまく使って同じホストからの接続しかできないような仕掛けがあるため、「直接3000番ポートに接続する」よりも、ルータスクリプトを使う方が楽である。

ルータは、WebアプリケーションとFileMaker Serverの中間に位置しており、WebアプリケーションがFileMaker ServerへのRESTコールを行う代わりに、ルーターに対して呼び出しを行う。ルーターはhttpsを使わずにFileMaker Serverを呼び出し結果を得て、それをWebアプリケーションに返す。動作としては「プロキシ」であるが、名前がrouterなので、ルーターと呼ぶことにする。

ルーターを利用できるようにするには、ダウンロードしたファイルrouter.phpを、以下のようなコマンドで起動する。ファイルがある場所をカレントディレクトリにして、コマンドを入力する。

php -S 127.0.0.1:8090 router.php

ここで、127.0.0.1は自分自身に接続するIPアドレスであり、コロンに続いてサーバーが利用するポート番号を指定する。他のプロセスが使っていない番号を使う必要がある。なお、使用を止めたい場合は、Terminalの画面でcontrol+Cキーを押す。

筆者が作ったAPIを利用するためのクラスFMDataAPIでルーターを利用したい場合、利用方法のサンプルを示したFMDataAPI_Sample.phpであれば、最初の方にあるインスタンス化している部分を記載のように修正する。パラメータを2つ追加して、8090ポートを使うことと、httpプロトコルを使うように設定すれば良い。他は変更が必要ない。もちろん、8090はルーターを起動する時に指定したポート番号を使う。IPアドレスも、基本的に起動時に設定したものを指定する。

修正前:
$fmdb = new FMDataAPI("TestDB", "web", "password", "127.0.0.1");

修正後:
$fmdb = new FMDataAPI("TestDB", "web", "password", "127.0.0.1", 8090, "http");

一方、FMDataAPITrialにあるスクリプトは、まず、lib.phpファイルにある以下の関数の返り値に、ルータ側のポート番号を指定する。

function targetHost()
{
    return "127.0.0.1:8090";
}

そして、Test2.php以降、プログラムの中のhttpsの記述をhttpに切り替える。callAPI関数の最初の引数が全てhttpsになっているので、httpに書き換える。

$host = targetHost();
$result = callAPI(
    "http://{$host}/fmi/rest/api/auth/TestDB",
    null,
    json_encode(array(
        "user" => "web",
        "password" => "password",
        "layout" => "person_layout",
    )),
    "POST");
resultOutput($result);

なお、phpコマンドで、router.phpを起動する時、127.0.0.1ではなく、localhostで指定した場合、上記の修正箇所のIPアドレスは、全てlocalhostで記述する。127.0.0.1では稼働しないので注意する必要がある。phpコマンドで起動する時に127.0.0.1を指定すると、Webアプリケーション側の設定は、127.0.0.1でもlocalhostでもどちらでも良いようだ。FileMaker Serverはかなり以前からIPv6ベースで動いているのだが、localhostとした場合、どこかで127.0.0.1ではないIPv6のアドレスとして識別しているのではないかと想像できるのだが、詳細は分からない。

ちなみに、FMDataAPIを使ったシステムを運用する時、原則としては正しい証明書でhttpsで運用することが原則だ。もちろん、盗聴されないためというのが大きな理由であるが、ホストを偽ってデータを収集されたり嘘の情報を流されることも防ぐ必要がある。httpsでの運用は、Let’s Encryptで無償で利用できるなど、年々手軽になってきているので、面倒がらずに対応すべきだというのが1つの結論である。

では、PHPを稼働させるWebサーバーとFileMaker Serverが同一のホストであれば、盗聴の心配はないのではないかと言うことになる。Firewallでポートを塞げば、それでいいのではないかと言う話もなくはない。ただ、FileMaker Data APIだけにWebサーバーを使うと言うことはあまりないと思われるので、Firewallの設定はちょっと面倒ではないだろうか。絶対に外部からFileMaker Data APIは利用しないで、サーバー内部に限るのであれば、httpでの運用でも問題はないかもしれないが、必ずサーバーの内部からの利用しかしないと言うことを管理者が人手で保証しないといけなくなる。通常、httpsで運用する手順を踏む方が楽なのではないだろうか。

自己署名証明書の問題も同様だ。サーバー内部に限るのなら、詐称のしようもないと考えることができる。これも、「絶対にサーバーの内部からの利用しかしないと言うことを管理者が人手で保証する」と言うモデルであり、むしろ、そういった人的な縛りよりもhttpsでの運用をする方が問題が発生しにく状況であると言えなくないだろうか?

そう言うことで、httpや自己署名証明書での運用は自己責任が大きいので、FileMaker Data APIでアプリケーションを開発したら、本番はhttpsでの運用を目指すようにすべきである。

なお、筆者の作ったFMDataAPIクラスは、デフォルトは証明書の検証をしない状態で稼働するので、そちらは開発中での利用を想定している。実際に正しい証明書が用意できれば、以下のメソッドを呼び出す。そうすれば、証明書の検証を行うようになる。自己署名でないこと、期限、アクセスしているサーバ名と同一なのかが検証される。

$fm->setCertValidating(true);

すなわち、FMDataAPIクラスは、証明書の検証もメソッドでコントロールできるようになっている。

FileMakerデータベースをOAuth認証で利用する

一部に間違いがあり、修正しました。修正箇所は青字で記載してあります。(2017-06-17)

FileMaker 16の大きな機能アップの1つは、OAuth対応だ。GoogleのアカウントでFieMakerデータベースへのログイン認証ができるようになったのである。OAuthの大きな特徴は、1度パスワードを入れれば、その後に認証されたことが異なるサービスに対しても継続されることである。これは「パスワードを覚えていて、その都度送り出す」のではなく、認証した事実を別のサーバーにうまく伝達を行うことで、サービスをまたいだ認証の継続を実現している。パスワードのやりとりは最初のログイン時だけになるので、概してより安全な認証方法と言うべきだろう。FileMakerがOAuthにどのように対応したのかを、データベースログインをGoogleアカウントでログインできるようにするための設定を通じて説明する。

FileMakerデータベースへのログイン

FileMakerデータベースをFileMaker Serverで公開したとする。以下はINTER-MediatorのサンプルデータベースをプライベートネットワークにあるFileMaker Server 16で公開した結果を示す。上記のサンプルで改変した点は本文途中で示す。

公開したデータベースをFileMaker Pro/Advancedで開こうとすると、次のようなダイアログボックスが表示され、そして、アカウント名とパスワードを入力して、「サインイン」ボタンをクリックする。

ここで、FileMaker Server 16で、Googleを認証サーバーとして利用するような設定を行い、加えてデータベース側にそのGoogleのアカウントを追加設定すると、サインインのダイアログボックスがでは以下のように、「Google」のボタンが下部に追加される。このダイアログボックスが表示された時には、「Google」ボタンをクリックするだけでOKである。アカウント名やパスワードのテキストフィールドに、Googleのユーザー名やパスワードを入力することは不要である。

そうすると、デフォルトのブラウザが開き、Googleアカウントのログインの「アカウントの選択」の画面になる。ちなみに筆者が複数のGoogleアカウントでログインをしているのでアカウントの選択になるのだが、アカウントが単独の場合には何も出ないかもしれない。あるいはまだログインをしていないのなら、さらにパスワードの入力や場合によってはアカウントの入力も必要だろう。何れにしても、サインインのダイアログボックスで「Google」ボタンをクリックすると、Webブラウザを利用してGoogleでの認証結果を確認する。その時に、Googleのアカウントでログインしていなければログインをするが、ログインして入ればそのまま処理が継続される。

ログインが成功するか、ログインされて入れば、次の図のようなダイアログボックスが表示される。これは認証が成功したことを示しており、データベースを利用するには「FileMaker Pro Advancedを開く」(もちろん、Proの場合もある)ボタンをクリックする。なお、「開かない」にしたら、何もしないので、ここでは必ず「〜を開く」ボタンをクリックする必要がある。

そうすれば、データベースが開かれる。この時、Get(アカウント名)等の取得関数の結果もデータビューアで示したが、ログインしているGoogleアカウントのアカウント名がそのまま見えている。

以上のように全てがうまく設定された状態だと、ログインパネルで、Googleボタンをクリックすることで、パスワードをその場では入力することなく、自動的にデータベースを開き、データベースではGoogleアカウントで誰が使っているのかを識別できる状態になる。あらかじめGoogleアカウントでログインしていれば、何も追加作業は必要ないか、あるいはアカウントの選択の作業が必要になる。 ログインしていなければ、Webブラウザでログイン作業を行う。

OAuthで利用するためのデータベース

FileMakerのデータベースは、ProないしはAdvancedで管理者でログインをして、「ファイル」メニューの「管理」にある「セキュリティ」を選択する。認証を行なったのちに、アカウントの追加をまずは行う。「アカウントの認証方法」の部分には、「Amazon」「Google」「Microsoft Asure AD」の3つの選択肢が増えている。利用するOAuthサービスを選択した上で、ユーザー名は、そのサービスのユーザー名をそのまま指定する。このように、Googleであれば、Googleのユーザー名を指定したアカウントを作っておかなければならない。もし、作っていない場合は、たとえGoogle側のログインが成功していてもデータベースの利用はできなくなっている。一見すると、他のこの種のサービスのように自由にログインできないのは不便と思われるかもしれないが、登録しないと利用できないようにするのがセキュリティ確保の基本である。誰でもログインできる状態というのは、多くのFileMakerデータベースには望まれていない。

アカウントが実際に利用できるようになるには、「アクセス権セット」を選択する必要がある。ここでは既定の「データ入力のみ」を選択しているが、もちろん、このアクセス権セットに、fmappつまり「FileMakerネットワークによるデータベースアクセス」の拡張アクセス権が設定されている必要がある。これは従来からと同様で、FileMaker Serverで公開するデータベースでは必須の設定である。なお、INTER-Mediatorのサンプルデータベースでは、「データ入力のみ」のアクセス権セットには、fmappはチェックが入っていないので、サンプルをそのまま使う場合には注意していただきたい。

アカウントの一覧には、Googleがタイプの項目が増えており、アカウントの列ではGoogleのユーザー名がそのまま見えている。

FileMaker Serverでの設定

FileMakerのAdmin Consoleで作業をする。ログイン後、左側で「データベースサーバー」を選択し、右側で「セキュリティ」のタブを選択する。そこにあるポップアップメニューで「FileMakerと外部サーバーアカウント」を選択する。すると、Amazon、Google、Microsoftの3つの項目が表示されるので、右側のギアのアイコンをクリックして、作業を進める。ここでは、Googleを例にとって説明する。

Googleのギアアイコンをクリックすると、次のようなパネルが表示される。結果的には、ここでGoogle側で得られた2つのコードを入力することになるが、それは、この後に説明する。簡単なようで難しい問題もあるので、それも併せてこの後に説明する。ともかく、2つのコードが得られたら、「保存」ボタンをクリックする。

ちなみに、Microsoftを選択すると、少し違うダイアログボックスが表示される。これらはサービスごとに得られるデータが少しずつ違うと言うことだ。なお、これら3つ以外のサービスはプラグインとして追加は可能となっているが、基本的にはメジャーなサービスの場合はFileMaker社による機能追加を待つことになるだろう。自社でOAuthサーバーを立てているなら、プラグインの開発をしたくなるところだろうが、こちらはFileMaker社による情報待ちの状態だ。

設定終了後、次のようなメッセージがでかでかと表示される。つまり、FileMaker Serverのサービスを再起動すると言うことだ。もちろん、コンピューター自体を再起動してもいいが、macOS、Windowsでの作業方法が、こちらのページに記載されている。

Googleのコードの取得

Admin Consoleで設定をするには、Google側から与えられるコードを取得しなければならない。そのコードは、Google APIのところで取得を行う。以下の手順で「利用規約の更新」が出てくる場合には、もちろん、そこで対応をして進める。

Googleの場合、Admin Consoleの「データベース」のセキュリティ設定のところで出てきた「Google API Console」をクリックすると、以下のような英語のOAuth 2.0のページが出てくる。実際作業は、このページの本文の2パラグラフ目にある「Google API Console」をクリックして進める。

Google API Consoleをクリックすると、以下のページに移動する。こちらを直接開くには、Google Developer Consoleのページにジャンプすれば良い。なお、このページ内容は、それまでにこの機能を使ったかどうかによって大きく違っている。全く初めて使う場合の作業手順も併せて説明しよう。ポイントは、上部に「Google APIs」というバーが出ている点である。

Google APIsと書かれた右側の部分では、初めて使う場合には「プロジェクトを選択」と表示されるので、それをクリックする。すでに何かで利用してプロジェクトが存在する場合には、とにかくプロジェクト名が見えているのでそれをクリックする。すると、以下のように、プロジェクトの一覧パネルが表示される。パネル右上の「+」をクリックすると、プロジェクトが新たに作成される。ここで、FileMaker Server向けにプロジェクトを1つ作っておく。

プロジェクトの作成時に必要なことは、プロジェクトの名前を設定することである。名前は適当に設定する。なお、プロジェクトIDはこの後は特には使用しない。

プロジェクトを作成すると、そのプロジェクト名がGoogle APIsの右に見えていることを確認して、左側で「認証情報」を選択する。すると、「認証情報を作成」というボタンが見える。ここで、ボタンをクリックして「OAuthクライアントID」という項目を選択する。

なお、ここで以下のようにメッセージが見えているGoogleアカウントでは、必要なコードを生成する権限が与えられていない。例えば、組織で作成されたアカウントではコード生成が許可されていない場合があるので、その場合は個人でアカウントをするなどして、コード発行を行う必要がある。組織のアカウントの場合は、その組織の管理者が、クライアントIDの発行を制限していることが一般的な原因だろう。

 「OAuthクライアントID」を選択した後、同意画面の作成を促す表示が出てくれば、それに従って以下のページで必要な情報を入力する。本来はこの「同意画面」がユーザーに示されて、そしてサービスを利用できるようにするという流れをOAuthでは採用している。しかしながら、FileMakerではこの同意画面を利用していないようで、「ユーザーに表示するサービス名」だけを設定して「保存」ボタンで保存すれば良い。

その後にアプリケーションの種類を選択するページが表示される。ここでは、「ウェブアプリケーション」を選択する。すると、名前などを入力する項目が表示される。ここで、名前は適当に設定するとして、もう1つは「承認済みのリダイレクトURI」を入力しなければならない。このURLは、例えば、FileMaker Serverに接続するためのホスト名が「fmstest.msyk.net」ならば、「https://fmstest.msyk.net/oauth/redirect」を指定する。ホスト名の部分だけがサーバーによって違い、他の部分はどのサーバーでも同様だ。なお、:443はあってもなくても良い。ちなみに、ここにmacOSの共有名(Macintosh.local)や、IPアドレスではうまく動作しない。ドメインを含む利用可能なホスト名をきちんと設定し、そのホスト名でサーバーに接続できる環境になっていなければならない。

「作成」ボタンをクリックすると、生成されたコードがパネルに表示される。こちらからコピーして、Admin Consoleの該当するフィールドにペーストすれば良い。なお、コードは後からでも参照は可能である。

うまくいかない場合の対処

手順は以上の通りだが、FileMakerのドキュメントにも書いてある通り、FileMaker Serverを、きちんとしたドメイン名のURLのホストで公開する必要がある。macOSの共有名の場合、ブラウザからのアクセスが正しくできない場合もある。IPアドレスだけではhttpsでアクセスしているはずはないので、Googleの側で登録が進まない。自分でドメインを持っている方は、何らかのテスト項目を作るなどしてともかくドメイン名を含むホスト名を用意する。

例えば、サインインのダイアログボックスで、Googleボタンをクリックした場合に次のようなページが出たとする。ここで詳細を表示すると、redirect_uriに見えるように、https://MacBookPro.localというホストにアクセスしようとしている。もちろん、この名前は共有名である。ブラウザでは共有名でもOKのはずなのにと思うかもしれないが、単にそのURLにブラウザからアクセスするのではなく、裏ではもっと色々複雑なことを行なっている。筆者の場合には、msyk.netというドメインを所有しているので、fmstest.msyk.netが利用できるようして、検証を行なった。IPアドレスは、実は10.0.1.102というプライベートアドレスだが、自宅環境ではそれで運用可能なので問題はない。

ここで、上記のrequest_uriのURIがどのように自動生成されるのか分からず、対処がなかなかできなかった。実際には、FileMaker Pro/Advancedがrequest_uriを「サーバーへ接続した時に使うホスト名」から生成しているようだ。macOSの場合、自動的にBonjour名が左側に出てきてアクセスをしがちであるが、それだと、上記のrequest_uriには共有名が含まれてしまう。サーバーのドメイン名(つまりFQDN)で接続するサーバーを選択できるように、例えば、お気に入りのホストにドメイン名を登録して、そこからデータベースを選択して開くようにすれば良い。以下の図のように、fmstest.msyk.netでデータベース選択ができるように、お気に入りのホストの登録を行なった。もちろん、自動的に識別される名前がホスト名であれば、それを選択すればOKである。

OAuth対応をどう考えるか

以上のように、Google側の使いこなしが必要になるものの、OAuth対応は確かに便利だろう。アカウントそのものの管理を外部に任せることができるのである。ただし、社員全員がGoogle Appsなどでアカウントを持っていれば便利は便利なのだが、データベース個別にそれぞれのアカウントを登録しなければならない。これは、テキストファイルで読み込みはできないため、自動化のスクリプトなどを使用することになると思われる。ともかく、Googleにアカウントを作ればデータベース側を変更しなくても新しいアカウントから使えるようになる…と言う状況は作れない。機能としては素晴らしいが、運用を考えた時に、手間になる部分も見えてくる。ログインしたアカウントのドメイン名がある名前であれば、自動的に登録されて定義されたアクセス権セットを利用するような仕組みがあることで、管理負荷を軽減できると考えられる。

FileMaker Data APIもOAuth対応している。その意味ではWeb対応しているのだが、WebDirect経由ではOAuth対応はなされていないこれは先のバージョンを待つしかないだろう。WebDirectについては当初は対応していないと記載していたが、GOからのアクセスも含めて対応はしている。エミックの松尾さんに指摘をいただいたが、恐らく正しい証明書であればHTTPSであればOAuth認証ができ、自己署名の証明書であればできないということではないかと思われる。なお、http://…だと、Googleで登録ができなかった。この件、簡単に検証ができないのではあるが、手元で検証した時の違いとなると署名書の違いしか考えられない。

[IM] OAuth2あるいはOpenID対応

Google AppsのOAuth2対応について、Using OAuth 2.0 to Access Google APIsに説明されています。この認証方式をサポートしました。したがって、OAuth2対応およびOpenID対応と言えるかと思います。Google以外のプロバイダについては今後、確認します。まずは、認証できるようになっているので、その使用方法を説明します。

OAuth認証するクライアント

まず最初に、ページをOAuth対応にした場合にどんな感じにページ表示されるのかを示します。認証を必須にすると、INTER-Mediator内蔵のログインパネルが表示されそこに「OAuth認証」というボタンが登場します。ここで、ボタンをクリックします。

shot2712

初めて利用するときには、次のように、認証アカウントから何を取り出すのかを表示するメッセージが出てきます。ここで「許可」をクリックします。なお、複数のアカウントでログインしている場合には、さらにどのアカウントでログインするのかを問い合わせるページもこの前に表示されます。

shot2713

そして、認証されます。おなじみのサンプルのページです。ログインユーザーは、ここでは意図的にプロバイダーによって提供される一意な名前とプロバイダー名を@でつないであります。

shot2714

認証のデータベースを見てみると、そちらに新たにユーザーが追加されています。つまり、外部にあるユーザーの認証ではありますが、いったん、利用しているデータベースのauthuserテーブルに、ユーザーを作り、もっぱらauthuserテーブルのユーザー情報を利用して、認証を行います。一定時間で無効化しますが(今日現在未実装)、それまでは、OAuth認証直後にランダムに生成したパスワードをクライアントに通知して記憶させ、INTER-Mediator自身の認証処理を行うことで、都度都度OAuthサーバーとのやりとりはないようにします。

shot2715

Googleでのアカウント発行

GoogleのOAuth2を利用するためには、アカウント発行が必要です。このアカウントは、アプリケーション、つまり、INTER-Mediatorで作るページに対するアカウントです。ページの利用者はこれらの情報は不要ですし、見えるようにする必要はありません。

まず、Googleデベロッパーのコンソールページに移動します。ここで、「プロジェクトを作成」をクリックします。このページは、もしかすると、2つ先のような画面になっているかもしれません。その場合はページの中にある新規プロジェクトを作成するようなボックスがあるので、それをクリックします。

shot2701

プロジェクトの作成で指定するのはプロジェクト名のみです。もちろん、開発者が把握できる名前を指定して、「作成」ボタンをクリックします。

shot2702

このようなページになります。追加したプロジェクトが1つのボックスになっています。また、左側に見えるように、このページが「ホーム」です。初めての利用であれば、このページに行きますが、以前い何か利用していた場合ではこの限りではありませんので、臨機応変に対処しましょう。ここまでで、ともかく1つのプロジェクトを作成してください。

shot2703

プロジェクトのボックスの右下にある「V」マーク部分をクリックすれば、内容が開きます。ここで、「プロジェクトの詳細」をクリックします。

shot2704

左側のナビゲーションで、APIと認証にある、「認証情報」をクリックします。認証情報というパネルが出るので、「認証情報を追加」をクリックします。

shot2705

ドロップダウンから、「OAuth 2.0クライアントID」を選択します。

shot2706

このような画面になります。「同意画面を設定」をクリックします。ここの同意画面は、最初に認証するときに見える画面です。

shot2707

メールアドレスはGoogleアカウントのメールアドレスが設定されています。サービス名を適当に記述しますが、この名前がタイトルになります。その他は「省略可」であるので、認証の動作には影響しません。入力をして「保存」ボタンをクリックします。

shot2708

アプリケーションの種類は「ウェブアプリケーション」を選択します。そして、「名前」は一覧の中で識別する名前を適当に指定します。そして、承認済みのJavaScript生成元には入力せず、承認済みのリダイレクトURLに、ここではINTER-Mediatorに含まれている/Auth_Support/OAuthCatcher.phpのURLが示されています。実際に利用するときには、このファイルのコピーを作るなどしてもかまいませんが、このまま利用してもかまいません。ログインパネルの「OAuth認証」ボタンをクリックすると、Googleが指定する「トークンリクエスト」のURLに移動し、ユーザーの特定や取得可能な情報のアクセス許可をページ上で求めます。その後に、「承認済みのリダイレクトURL」にリダイレクトするときに、アクセストークンが引数として渡され、INTER-Mediatorはそれを元に、OAuthユーザーをデータベースに作成します。

shot2709

「作成」ボタンを押すと、クライアントIDとクライアントシークレットが表示されます。これらはparams.phpファイルにコピペをします。コピペの方法は後で説明します。(ご安心ください。このIDとシークレットはすでに無効化してあります)

shot2710

OKをクリックすると、発行したアイアウントが一覧されるページになります。ここから、削除や追加、あるいは変更などのアカウントの管理もでき明日し、同意画面の変更などもできます。

shot2711

INTER-Mediatorで作成するファイル

OAuth認証を使いたいページでは、まず、定義ファイルに基本的な設定を行います。例えば、以下のファイルは、Samples/Sample_Auth/MySQL_definitions.phpの記述です。IM_Entryの第2引数に、authenticationキーで連想配列を指定します。とりあえず、クレデンシャルの記録方法(ここではセッションストレージ)とレルム(ここでは「Sample_Auth/MySQL_definitions」)を指定します。レルムは単に同一認証を受け付ける領域名とと考えてください。

IM_Entry(
    array( /* コンテキスト定義 */
    array(
        'authentication' => array(
            'storing' => 'session-storage',
            'realm' => 'Sample_Auth/MySQL_definitions',
        ),
    ),
    array('db-class' => 'PDO'),
    2
);

Googleに関連づける情報は、params.phpファイル側に記述できます。これらは、定義ファイルでは記述できないのが現在の仕様です。それぞれ、以下のように、決められた変数名に値を指定します。最初はプロバイダーで現在は「Google」のみサポートしています。続いて、クライアントIDトクライアントシークレットを、Googleのデベロッパーコンソールのページからコピー&ペーストします。最後のリダイレクトのURLは、「承認済みのリダイレクトURL」と同じURLを指定します。

$oAuthProvider = "Google";
$oAuthClientID = '1084721348801-jv3hvi4shcmr4j7unuhioq8k2mm47n6s.apps.googleusercontent.com';
$oAuthClientSecret = 'hV5TZD8x108K1Zac4RfZopur';
$oAuthRedirect = 'http://localhost:7001/Auth_Support/OAuthCatcher.php';

まだ完成というまでには至っていませんが、ともかく、認証できるところまでを作りました。タイムアウトのタイミングや、カスタマイズポイントなどを作りこみたいと思いますが、ご意見があれば、Facebookのグループでよろしくお願いします。

[IM]LDAP認証の実装がだいたいできてきました

INTER-Mediatorには、自分自身でユーザーテーブルを持つ認証(ビルトイン認証)が可能です。そして、データベースエンジンのユーザーによる認証(ネイティブ認証)もすでにサポートしています。次に取り組むのはやはりLDAPです。ただ、MySQLにはLDAP接続のプラグインがあり、そういう手法を使えば、ネイティブ認証の一環としてLDAP認証を実現することができます。しかし、通常とは異なるデータベース運用が必要になりますし、MySQLとPostgreSQLで動作に違いがあるとまた大変です。SQLiteはそういう統合はできません。LDAPについては、単に認証の確認だけだと、要するに認証バインドをするだけのことであり、PHPではさほど難しくはないので、データベースエンジンと独立してLDAP認証の仕組みを搭載しました。

LDAPサーバに対する設定

まず、LDAPサーバ情報は、params.phpファイルに、変数で記載する方法にしました。LDAPでの認証時は、ユーザーはユーザー名だけを与えるのではなく、ユーザーレコードのDN(Distinguished Name)を指定する必要があります。たとえば、OS X Serverで、ホスト名がhomeserver.msyk.netの場合、

uid=msyk,cn=users,dc=homeserver,dc=msyk,dc=net

というのがユーザーを特定するDNとなります。ここで、dc…以降は「検索ベース」、cn=usersは「コンテナ」とします。さらに、OS X Serverはuidという属性名でユーザー名を指定しますが、これもActive Directoryでは違うこともあって、結果的に上記のユーザー名「msyk」以外の部分をすべて、変数で与えて、DNを構成するようにしています。サーバーのURL、ポート番号も合わせて、結局、params.phpファイルに以下のように記載をすることにします。

$ldapServer = "ldap://homeserver.msyk.net";
$ldapPort = 389;
$ldapBase = "dc=homeserver,dc=msyk,dc=net";
$ldapContainer = "cn=users";
$ldapAccountKey = "uid";

なお、$ldapServer変数に設定されている文字列の長さが0以上なら、LDAP認証を試みるように動作します。これらの変数部分を全部コメントにすると、LDAP認証に関しては何も行わず、以前の通りの動作になるようにしました。

PHPのLDAPライブラリの機能を使って認証するとしたら、その認証のためのバインドはサーバーからLDAPサーバーに送られます。ということは、クライアントからサーバーに対して、ユーザー名とパスワードを送り届けないといけません。これは、ネイティブ認証の仕組みを利用しますが、そのために、鍵ペアを生成して、params.phpファイルに記述します。以下の部分です。もちろん、最初から入っている鍵ではなく、コメントに書いている方法で自分が使用する鍵に置き換えてください。もちろん、クライアントに送られるのは、公開鍵です。

$generatedPrivateKey = <<<EOL
-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBAKihibtt92M6A/z49CqNcWugBd3sPrW3HF8TtKANZd1EWQ/agZ65
 :
jU6zr1wG9awuXj8j5x37eFXnfD/p92GpteyHuIDpog==
-----END RSA PRIVATE KEY-----
EOL;

ネイティブ認証との混合動作

そして、LDAPアカウントでのログインは簡単にできました。ただし、1回の認証バインドに0.2〜0.3秒ほどかかります。同一のサブネットです。たとえば、フォームのサンプルだと、1ページの合成にデータベースアクセスを15回ほど行うので、5秒くらいのアクセス時間の増加になります。これは、ちょっと長いです。また、単に認証ができたとしても、グループ設定との連動等といった問題があります。

そこで、LDAPアカウントで認証が成功したら、ビルトイン認証で使うテーブル(authuserテーブル)に、そのLDAPのアカウントの情報をレコードとして追加することにしました。1回成功したら、ビルトイン認証テーブルにユーザーを追加し、パスワードもわかっているのでハッシュ化したパスワードを保存します。そのために、ビルトイン認証を行って失敗するとLDAP認証を行うという流れにしました。ビルトイン認証とLDAP認証は切り替えるのではなく、この順序で両方行います。
しかし、その追加したユーザーがいつまでも使えるのは問題で、タイムアウトさせないといけません。そこで、結果的にはビルトイン認証のテーブルにDateTime型のフィールド「limitdt」を追加する必要が発生しました。現在の実装では、そのフィールドの有無で落ちることはないようにしてありますが、LDAPを使う場合には追加したフィールドの定義がされていないといけません。

こうしてユーザーのレコードを作っておくと、グループへの登録ができます。ユーザー名で識別され、1度登録すると消されないので、主キー値は保持されるはずです。タイムアウトすると、LDAP認証を試みます。ただ、この部分、現在実装中で、うまくいったりいかなかったり、一進一退ですが、ある程度のところまで動くようになっています。ちなみに、MoodleもLDAP認証をサポートしますが、ログインを1度することで、ユーーザーレコードが作られる仕組みになっており、やはり同じような仕組みをINTER-Mediatorでも実装しています。

認証処理の流れ

初めて、LDAPアカウントでログインしようとするとき、ビルドイン認証のテーブルにはそのユーザーはありません。したがって、ビルトイン認証では失敗しますが、その後のLDAP認証で成功します。このとき、新たにビルトイン認証のテーブルに、そのユーザーのレコードを作りパスワードのハッシュと期限を記録します。クライアント側には認証のための情報が残されているので、この次の通信時からは、自動的にビルトイン認証が成功します。したがって、1画面作るのに20回の通信処理が必要でも、最初の1回だけがLDAP認証されます。

次の通信処理が、LDAP認証のタイムアウト以内の期間なら、ビルトイン認証が成功して終了します。そのとき、limitdtフィールドも現在の時刻に更新します。しばらくクライアントを利用しないなどでタイムアウトになると、ビルトイン認証は失敗しますが、引き続くLDAP認証が成功するように、クライアントでは、LDAP認証とネイティブ認証に必要な情報が残されています。そして、1度LDAP認証に成功すると、次回以降はまたネイティブ認証がタイムアウトまで成功します。

認証に必要な情報はクッキーに保存することもできるので、翌日にまた認証を継続させることもできます。

今現在、動作が怪しいのは、LDAP認証のパスワードを変えたときです。まず、この方法だと、LDAP認証のタイムアウトの時間が来るまでLDAPでの認証は行われないので、その期間は変更前のパスワードが通ります。これは、とりあえず、仕方ないことの1つとしておきます。そして、タイムアウトしてLDAP認証すると、当然ながら以前のパスワードでは認証が通らないので認証エラーとなり、ログインパネルが表示されます。ここで、新しくなったパスワードを入力すると、また同じように動作するというのが期待する動作です。このあたりの挙動が現状、今ひとつな感じです。

FileMakerはサポートせず

なお、LDAP認証は、PDOのみで、FileMaker Serverはサポートしません。どうしようかと思ったのですが、Admin Consoleでの設定で「外部サーバーアカウント」をクライアント認証で使えるようにしておけば、ネイティブ認証で事実上、Active Directory、Open Directoryは利用できます。LinuxのLDAPは使えないけど、FileMakerのクライアントで使えないで、Web側だけで使える仕組みまでのサポートは必要かどうか疑問ですので、FileMakerはINTER-Mediator組み込みのLDAP認証はサポートしないということにしたいと思います。

第三者を介在せずに「抽選」を行う方法

Facebookに記事を書いたように、機材の販売先を決める抽選が必要になりそうです。第三者に立ち会ってもらって公正にするということは可能でしょうけど、それでも不正の確率は0になりません。頼まれた方もいい迷惑(笑)。なんかいい方法がないか考えました。こんなのはどうでしょう。

基本的な手法

  1. 当せん決定者は、何か1文字を思い浮かべるが、公表しない
  2. 複数の抽選参加者は、何か1文字を思い浮かべて公表する
  3. Unicode のエンコードで、決定者の文字に一番近い参加者が当せんとする

しかし、いろいろ問題があります。決定者が、参加者の公表よりも後になって、思い浮かべた文字を変えてしまうということをしても検出する方法がありません。つまり、決定者は、誰かが当せんするように、意図的に文字を思い浮かべ、それを事前に思い浮かべたものとしてしてしまうと不正が成立します。

では、決定者が文字を思い浮かべた時点で、第三者に伝達する方法があります。しかし、これは決定者と第三者、あるいは参加者と第三者が、裏で結託していると、やはり不正が成立します。

不正を防止する手段

しかしながら、以下のような、ダイジェスト(あるいはハッシュ)を利用する方法をすれば、第三者の介在なしに、不正ができないと考えますがどうでしょう。

  1. 当せん決定者は何か1文字を思い浮かべる:その文字をcとする
  2. 当せん決定者は、別の適当な文言を思い浮かべる。何文字かは公表しない:文章をsとする
  3. s+cのダイジェストd1を求めて公表する
  4. sのダイジェストd2を求めて公表する

こうして2つのダイジェストを求めますが、当然ながら、決定者はファイル等で、sとcを残しておきます。これらのファイルや文字列が、最終決定までに漏えいしないことが前提です。

2つのダイジェストを公表したのちに、参加者は、期限までに「自分が思い浮かべた1文字」を公表します。他人の表明を見ての変更もありとしてもいいかと思います。

最初cのダイジェストを求めればいいかと思ったのですが、Unicodeで1文字程度なら、全部チェックで比較的短時間でわかってしまうという懸念があります。もちろん、公表から10分以内という手もありますが、セキュリティホールの確率が下がるだけです。そこで、不定長の文字列と組み合わせることを考えつきました。

データの作成例

以下は、具体例です。sha1は、「openssl sha1 (ファイル名)」で得られます。公開/非公開は、参加者の表明が終わるまでの間の扱いです。

s="サンプルテキストです:"(非公開)
c="A"(非公開)
sのsha1→34591a094e22f43fb1ba99426265383993599c96(公開)
s+cのsha1→1c19e4ce3a0d49b6dff756e2bf62bdd605355051(公開)

ここで、公表するのはsha1のダイジェスト値のみです。従って、この2つのバイナリデータから、「A」を推測するのは難しいです。cのダイジェストならば数万回程度の試行で元の文字列が分かるかもしれないけど、上記のd1とd2は「不定数の文字列のダイジェスト」なので、ブルートフォース攻撃の必要アタック数は桁違いに高くなります。決定者がAないしはsを変えてしまって、同一のダイジェスト値を得るのは、ほぼ無理と考えれば、不正が入る余地はありません。もちろん、sha1ではなく、sha512などを本番では使うべきでしょうね。

sもcも決定前には未公開なので、参加者は偶然に当ててしまった場合でも、当たったかどうかは分からないはずです。

なお、抽選者が3人以上の場合、「文字コード上で一定以上の距離を空ける」というルールは必要でしょうね。例えば、ある人が「F」と言ったとします。別の2人が「E」と「G」と宣言して、最初の人の当せん確率を限りなく0にすることが可能です。つまり、別の2人が結託している状況です。まあ、これは監視されている上なので、普通はやらないとは思いますが、厳密にはそのルールが必要かと思います。

抽選者にとって、確率は同一になるかどうか? ここはアイデアが固まっていません。抽選者にとってはcは未知なので、Unicodeのコード空間上、どこにあるかは分からないという点では均一なのかもしれません。しかし、cが空間の端の場合とど真ん中の場合で抽選者に影響はあるのかどうかという点も気になります。cを複数設定して、参加者の1文字は一番近いcを採用するといったようなランダム化は必要なのかもしれません。しかし、この問題は、ちょっと難しそうなので、cは1つということにします。

いかがでしょうか?

[IM]MediaAccessクラスと新たな拡張点(2)

こちらの文書の続きです。

FileMakerのオブジェクトフィールドを参照する

オブジェクトフィールドはデータベースごとに扱いが異なり、統一的にはやりにくい処理ではあります。MediaAccessクラスでは、FileMaker Serverをターゲットにオブジェクトフィールドに対応する機能を作成しました。

FIleMakerはFXを経由し、XML共有の仕組みを使います。テキスト型や数値型は、基本的にテキストでフィールドにあるデータが得られます。一方、オブジェクトフィールドはオブジェクトそのもののデータではなく、フィールドのデータに応じた以下のような「テキスト」が得られます。

/fmi/xml/cnt/photo.jpg
http://server:16000/…

PDFは完全なURLで、FileMaker Serverに16000ポートで接続して取り出すことが可能です。JPEGなどの画像の場合は、URLのパスに相当するものが得られますが、たとえばIMGタグのSRC属性にそのまま指定が可能な文字列になります。

いずれにしても、両方ともURLであると解釈すればいいわけです。この仕組みはFileMaker Serverに限らず、一般的なアクセスにも使えます。つまり、media=URLと指定をした場合は、そのURLにアクセスしたデータをMediaAccessクラスが取得し、さらにクラスを呼び出した元にそのデータを返します。/fmi/xml/cntで始まる物だけは特別にURLであるという処理が組み込まれています。また、URLかどうかはそれ以外には、httpあるいはhttpsで開始するものかどうかで判定しています。

MediaAccessでのアクセス権

認証が成立したらすべて参照可能となり、成立しなければ参照不可という単純なものなら非常に話が早く、前に説明したmedia-tokenの仕組みで事は足りるのです。なお、データはCRUDの4つの側面がありますが、メディアに関しては「編集」というのはWeb世界ではかなり難易度が高い世界であり、MediaAccessクラスはほぼ参照のみのサポートになっています。

ここで、メディアそのものがログインしたユーザごとのアクセス権を持たせたい場合が出てきます。レコードについては、特定のフィールドにユーザ名やグループ名を入力することで、そのユーザやグループに所属したユーザでないと参照や更新ができない仕組みを持っています。フィールドのデータはそれでいいのですが、メディアは実体はレコードと別に有ります。ここで、個々のメディアをコンテキストのレコードと結合させ、レコードごとのアクセス権をメディアにまで及ぼす仕組みを組み込みました。

まず、IM_Entry関数の2つ目の引数(オプション引数)に、キーが’media-context’で値がコンテキスト名(コンテキストのnameキーに対する値)を与えます。すると、メディアはこのコンテキストにある特定のレコードの、1つのフィールドのようなふるまいになります。

‘media-context’ => ‘context-name’,

実際にメディアにアクセスするパスは次のような形式にします。つまり、コンテキスト名、レコードの検索条件をパスに入れます。最初のfilesは特に意味はなく、相対パスの最初のキーワードです。context-nameは、media-contextの値と同じでなければなりません。そのコンテキストのkeyキーに対する値、つまり主キーがpidであるなら、たとえば、field=valueは、pid=312 のような値になります。

context.php?media=files/context-name/field=value/filename.png

ここでもし、media-root-dirが /var/www/media であるなら、実際に

/var/www/media/files/context-name/pid=312/finename.png

という絶対パスの画像ファイルが存在する必要があります。コンテキストの定義には、レコード単位のアクセス権設定があれば、メディアに対するアクセス権の認証の確認を行い、ユーザを特定します。pid=312のレコードがそのユーザにアクセス権があるのかどうかを確認することによって、アクセスの可否を決めます。従って、適当にpid=316などとパスを変えても、その条件で検索されたレコードが他のユーザに対する権利があるものであれば、400番台のレスポンスを返してデータは返しません。認証の確認を行い、そのユーザに対するアクセス権がないものは出力しないという仕様によりアクセス権は定義した通りに適用されます。

pid=312を、age=45のようにできると言えばできますが、おそらく、そういうディレクトリは存在せず、漏洩にはならないでしょう。

ファイルのアップロードのコンポーネントは、コンテキスト名やレコード検索条件のパスを自動的に作成するようにも作られています。

とまあ、ここまで書いたところで、ソースに間違いを発見! また、グループ名をフィールドに入れる場合はまだ実装していなかったことも思い出しました。今のところ、メディア関連処理は、開発している側で「必要の合った」状況しかうまく動かない可能性があります。ぜひとも、いろいろ試してフィードバックをください。

(まだ続く)

Booking.comを騙るメール

来ました。予約した覚えはないのですが、1泊で1800ドルとはゴージャスなものです。ただ、よくあるタイプの別のサイトへの誘導は明示的ではなく、HTML内にあるのリンクはちゃんとbooking.comに行きますね。しかし、金額は書いてあるけど、どこのホテルか書いていない。そんな予約はありえないでしょう。このメールアドレスで昔booking.comを使った可能性もあるのですが、なんとアカウントは作られていませんでした。まあ、これでほとんど安心なのですが、念のためアカウントを作ってみたのだけどやはり予約は入っていません。また、添付するzipを展開するとexeが入っていたので間違いなく、嘘メールでしょう。あと、巧妙なのは、本物のBooking.comの広告メールと同じような時間に配布しているところですね。

だけど、ClamXavだとマルウェアと判定はしませんでした。Booking.comには似たような警告はありますが、このメールではなく、1年ほど前の別のもののようです。ということで、警告の意味も含めてブログに記載します。1ヶ月ぶりの書き込みがこんな話題ですんません。

スクリーンショット 2013-08-06 14.52.52 スクリーンショット 2013-08-06 14.53.09