Category: FileMaker

FileMaker Server 13の管理コンソールが別のコンピュータから接続できない理由

*** 内容が少し違っていたので、修正しました。2013/20/50 ***

FileMaker Server 13になって、管理コンソールが純粋なWebアプリになり、クライアント側ではJavaのバージョンなどは気にしなくてもいいようになりました。これは非常に便利です。サーバ側はTomcatなので相変わらずJavaですが、そちらは管理された環境なので、利用者はJavaのバージョン等は気にしなくていいようになりました。

一方、FMS13では、16000ポートがHTTPSで、16001ポートがHTTPでの接続ができるようになっています。管理コンソールへの接続条件は、インストールしたサーバでは「https://localhost:16000」「http://localhost:16001」で接続ができます。FMS12のときと、HTTPSとHTTPが入れ替わっています。また、他のコンピュータから「https://ホスト名:16000」での接続は可能ですが、「http://ホスト名:16001」の接続はできません。

なぜか？　パケットをキャプチャしてみました。コンソールへのログインをするときに、クライアントからサーバへのリクエストをダンプしてみました。以下の最初の数行の固まりはヘッダです（クッキーは省略しています）。そして、行をあけて1行だけあるのがボディです。

POST /admin-console/APP/connector/3/304/login HTTP/1.1
Host: homeserver.msyk.net:16001
Connection: keep-alive
Content-Length: 29
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://homeserver.msyk.net:16001
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://homeserver.msyk.net:16001/admin-console/APP/connector/3/304/login
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Cookie: JSESSIONID=6706...888

username=admin&password=abcdef

わお！ユーザ名とパスワードがそのまま流れています（もちろんabcedfは置き換えてあり、abcdefの代わりに本物のパスワードが見えました）。ハッシュですらありません！　つまり、localhostからの接続でないと、通信経路上での盗聴で簡単にログインのアカウントとパスワードを取り出せてしまうのです。サーバのコンピュータからしかログインできなくなっているのはそのためでしょう。同一コンピュータ内なら、パスワードをそのまま流しても、問題になることはないと言えます。しかし、他のコンピュータから接続するという状況では明らかに問題です。すなわち絶対に通信そのものを暗号化しないと危険なので、HTTPSでの接続しかできなくなっています。

それでも、どうしても、他のコンピュータから16001ポートを使って管理コンソールに接続したいという方は、以下のファイルを修正してください。OS Xでは必要に応じてsudoで作業をしましょう。Windowsは、多分、「FileMaker Server」がProgram Filesにあると思うので、それ以下は同じと思います。

/Library/FileMaker Server/Admin/admin-master-tomcat/conf/server.xml

このファイルの最初に以下の部分があります。開いて「16001」を検索します。このポート番号はここだけです。最後の方の下線、赤字の部分を削除してファイルを保存してください。

<Connector port="16001" protocol="HTTP/1.1" maxHttpHeaderSize="8192" maxThreads="150"
 minSpareThreads="5" maxSpareThreads="75" enableLookups="false"
 redirectPort="8443" acceptCount="100" connectionTimeout="20000"
 disableUploadTimeout="true" address="127.0.0.1" URIEncoding="UTF-8"/>

この後、サーバの再起動をしますが、管理コンソール自体を再起動させます。うまく行かない場合にはコンピュータの再起動を行いましょう。そうすれば「http://ホスト名:16001」で管理コンソールに接続できます。ホスト名はIPアドレスでももちろんかまいません。

くれぐれも、この状態で、インターネット経由での接続は細心の注意を払ってください。パスワードがバレない限りは他人にアクセスはできませんが、現状では容易にバレてしまうような通信方法です。安心な方法は、FMS13を稼働させているコンピュータにVPNで接続することですが、一手間増えるならVNCでサーバにログインしてページを開くのとあまり変わらないですよね。したがって、こうした変更はしないで、現状通り使うのが安全です。あるいは、自己署名証明書である点が微妙ですが、16000ポートで接続しましょう。いくら暗号化されているとは言え改善を期待したいですが、次のバージョン以降なのでしょうか。

FileMaker Server 13の「デーモングループ」とは何か？

FileMaker Server 13のインストーラで次の図のような画面が出てきます。FileMaker Server 12までは、fmserverという決められたユーザでしか稼働できなかったのですが、任意のユーザでの実行が可能になったのです。

shot0050

つまり、今ログインしているユーザで稼働させることができるのです。そうなると、FileMaker Server内のフォルダやファイルが、ログインしているユーザが所有者となるため、削除や名前の変更をアクセス権のことを気にしないでできるようになります。自分のMacにFileMaker Serverを入れて開発をしている人に取っては一手間、二手間が減るということになります。以下の図は、私のmsykのアカウントでインストールした結果です。Web用のファイルのフォルダやデータベースのフォルダの所有者がmsykとなり、ログインしている私msykに読み書き権限があります。

shot0052

このように、fmserverアカウント以外での運用をするには、インストーラでインストールするときに指定をします。しかしながら、ログインをしているユーザを単に指定すると次の図のようなシートの警告が出て来て、インストールができません。

shot0051

デーモングループ？　なんでしょうか？　これ、日本語にすると意味が分からないのですが、OS Xにはdaemonという名前のグループアカウントがあり、そのグループに所属しているユーザでないと、指定ができないですよということです。なので「daemonグループ」と翻訳しないで書かないと意味は通りません。既定値ではdaemonグループには、rootユーザしか登録されていませんが、ここでは私のアカウントmsykを登録しておく必要があります。しかしながら、マニュアルに具体的には書かれていません。システム環境設定ではできません。

では、どうすればいいでしょうか？　以下のように、ターミナルでコマンドをたたいてください。どうしてもGUIで作業したいという方は、「ワークグループマネージャ」をダウンロードしてやれなくはないですが、手順は簡単ではありませんので、ここでは省略します。コマンドの方がはるかに簡単です、と言い切ります。msykの箇所は実際に利用するユーザ名に変えますが、あとはこのままです。2行目は追加されている事を確認するためのコマンドです。

sudo dseditgroup -o edit -a msyk -t user daemon
sudo dseditgroup -o read daemon

2つ目のコマンドでは、daemonグループに関するさまざまな情報が表示されるので、その中で、グループに含まれるユーザを示すdsAttrTypeStandard:GroupMembership以降にユーザ名が追加されているかを確認します。インストールの途中でターミナルを立ち上げて作業してもOKでした。

こんなコマンドは見た事がない？　そんな方は、こちらの書籍をお勧めします（さりげない宣伝）。アカウントについても詳しく書籍で紹介があります。

こうしてインストールすると、fmserverdなどのデーモンやWeb共有のhttpdといったプロセスは、全部msykアカウントで稼働します。セキュリティ上大丈夫なのかと気にする人もいらっしゃるかもしれませんが、FileMaker Serverに変なバグがなければ大丈夫です。Webで公開するものは気をつけた方がいいかもしれませんが、たぶん、自分で開発しているアプリを入れるのが普通なので、通常のWebとは違ってグローバルIPにさらされることはほぼないこともあり、問題になることはほとんどないと思います。もっとも、こういう仕事をしている人は「問題になる状況かどうか」を自分で判断できるものじゃないかとも言えますし、自分で回避できるだろうとも言えます。

「FileMaker® Server 13入門ガイド」のp43に次のような事が書かれています。他のページにはアカウントの事はあまりきちんと書かれていません。インストールのところでも、ここを見ろというリファレンスがあるだけです。

OS X: アカウントは OS X のローカルユーザアカウントであり、ローカルファイルへのアクセス（デーモングループのメンバーシップを含む）に関して fmserver アカウントと同一の権限を持っている必要があります。ディレクトリサービス（Active Directory または Open Directory など）に由来するアカウントは使用できません。リモートボリュームにデータベースまたはオブジェクトデータフォルダを追加して設定する場合、アカウントはこれらのリモートフォルダに対する完全なアクセス権を持っている必要があります。

例によって解釈しづらい文章です。ここで、fmserverアカウントのアクセス権をidコマンドで確認してみます。ここで、1(daemon)、および61(localaccounts)がポイントなのではないかと思います。Open Directoryのアカウントは、localaccountsグループには所属していません。ローカルに作ったアカウントだと、足りないのがdaemonグループへの所属だけなので、前記の方法でFileMaker Serverの実行アカウントとして利用できるようになります。

$ id fmserver
uid=502(fmserver) gid=499(fmsadmin) groups=499(fmsadmin),1(daemon),12(everyone),61(localaccounts),100(_lpoperator),402(com.apple.sharepoint.group.1),240(com.apple.access_loginwindow)

FileMaker Server 13はWebDirectなどいろいろ新しい機能が増えていますが、こういう地道なところでも変化がありますね。

FileMaker ServerのAdmin Console起動のファイルの入手すらできない場合

OS XでFileMaker ServerのAdmin Console接続の続報です。なんとかうまくセットアップができたとしても、そのうちあれこれやっていると、16000番ポートにつなぐとこれになることがあります。もちろん、Javaのインストールはすでにやってあってもこれが出てしまうとします。そうなると、admin_console_webstart.jnlpというファイルのダウンロードができません。

スクリーンショット 2013-09-28 0.44.01

そのようなときには、ブラウザのアドレス欄に以下のようなURLを入れます。これで、admin_console_webstart.jnlpが入手できます。

http://ホスト名:16000/admin_console_webstart.jnlp

OS XでFileMaker ServerのAdmin Console接続

JavaVMをAppleがリリースしなくなり、OS XのJavaは混沌としてしまっていますが、FileMaker Serverを使うにはどうしても避けて通れません。FMS自体を動かすためのJavaのバージョンについてはFileMakerのサイトにいろいろな情報が掲載されていますが、サーバ管理ツールのAdmin Consoleについてもバージョンの混在で訳が分からなくなりつつあります。

OS Xのメンテナンスをどうやってきたかによって多分動作は違うと思いますが、私のメインマシンは以下のようにどうしようもない状態になりました。

  • ログイン時に作ったアプリケーションでは起動しなくなった。
  • 16000番ポートに接続して表示されるページのアイコンをクリックしても、Admin Consoleは表示されなくなった。admin_console_webstart.jnlpがダウンロードされるだけ。
  • サーバからadmin_console_webstart.jnlpというファイルがダウンロードできれば、それを右クリックして、「Java Web Start」を選択すると、なんとか起動できるようになった。

3つ目の方法でなんとか凌ぐということもできるのですが、なんか不便です。また、admin_console_webstart.jnlpに接続先情報が組み込まれているためと思われますが、サーバごとにkのファイルを残しておかないといけません。そんなわけで、コマンドラインで管理したりとか、だんだんダークな世界に入りつつあり、なんとかできないのかと思ったのですが、Automaterでアプリケーションを作ればいいじゃんということに気付きました。こんなのを作ります。

fig2

このワークフローは、Automaterで新しくウインドウを作ったときに「アプリケーション」を選択します。最初の「指定されたFinder項目を取得」は、admin_console_webstart.jnlpファイルをウインドウ内にドラッグ&ドロップすれば作成できます。ダウンロードしたadmin_console_webstart.jnlpファイルは、私の場合いくつもあるので適当に名前を変えています。

そして、続くワークフローでは「Finder項目を開く」で、「このアプリケーションで開く」で「Java Web Start」を指定します。ただ、ポップアップニューには「Java Web Start」は出てきません。ポップアップメニューで、「その他」を選択してファイル選択のダイアログボックスを表示します。そして、command+shift+Gを押して、移動先のパスを入力するシートを表示して、「/System/Library/CoreServices」に移動します。そこには、「Java Web Start」のアプリケーションがあるので選択ができます。

こうしてアプリケーション自体をサーバごとに作っておけば、ダブルクリックでAdmin Consoleを起動することができます。

[FMRP] 繰り返しフィールド、ポータル、ポータルフィルタ

しばらくさぼってしまっていましたが、FileMaker Relationship Patternsの続きです。

カテゴリ：1対多

名前：繰り返しフィールド

問題：

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策：

繰り返しフィールドを必要な数、つまり複数のエンティティに対応するフィールドの数だけ定義して、レイアウト上に配置する

フォース：

TO間の結合を定義するのではなく、フィールドのオプション設定として、繰り返す数の上限を1より大きな値に設定する事で、繰り返しフィールドを用意する

繰り返しフィールドで複数のレコードに対する保存は確保できるが、厳密な意味でのテーブル間結合ではなく、第一正規形も満たしていない点を考慮する必要がある

複数エンティティを起点としたリレーションシップは確保できず、集計処理などができない。たとえば、伝票で明細を繰り返しフィールドで作れば「伝票」という帳票は作成できるが、明細行のレコードに関して商品ごとの売り上げ集計はできなくなる。

繰り返し数の上限は、データベースの定義で決める必要がある。繰り返し数が後から足りなくなった場合に増やす事もできるが、データベースの設計変更を伴う

繰り返しフィールドはスクロールができないため、レコード数が多数になると、レイアウトの広い範囲を繰り返しフィールドが占めてしまい、使い勝手が悪いレイアウトができてしまう

関連パターン：

ポータル

カテゴリ：1対多

名前：ポータル

問題：

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策：

レイアウト上にポータルを配置して、レイアウトのTOとリレーションシップでつながっている別のTOを割り当てる。これにより、レイアウトのTOのレコードと対応関係にあるポータルのTOのレコードが、ポータルに一覧される

フォース：

典型的な1対多の展開である。リレーションで直接つながっているTOだけでなく、複数のTOを経由した先のTOでもポータルには配置できる。

ポータルの中にポータルは配置できない。ポータルの中では1対1のリレーションシップの先の単一のフィールドしか配置できない。

関連パターン：

ポータルフィルタ、繰り返しフィールド

カテゴリ：1対多

名前：ポータルフィルタ

問題：

ポータルに表示するレコードを条件に応じて制限したいが、制約をリレーションシップで定義したくない

解決策：

ポータルフィルタの設定を行う

フォース：

FileMakerのリレーションシップの制約の1つは、複数のTOが存在するTOGにおいて、すでに2つ先になっているTOと直接結合することができないことである。つまり、条件の設定をSQLのように柔軟にできないため、リレーションシップだけで必要なレコードに絞り込むことが困難な場合も出てくる。ポータルフィルタは単にレコードに式をあてはめて、表示するかどうかを判定するだけである。ただし、式に使えるフィールドはリレーションシップに影響する可能性が発生するが、1つの解決方法はグローバルフィールドを用いて条件を与え、式で判定させるということができる点がある。従って、レイアウトに表示するという状況では、リレーション以外に制約を与える方法が存在するため、すべてをリレーションで解決する必要はない。

フィルタにより一部のレコードだけが表示されるが、フィルタの式の結果がすべてtrueつまり、フィルタ前のすべてのレコードを一度は読み込むため、レイアウトを表示した最初のときに非常に時間がかかるケースも発生する。FIleMaker 12の段階では、サーバサイドでフィルタを適用しているのではなく、クライアントサイドで適用していることが原因と考えられる。

関連パターン：

ポータル

[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のようにできると言えばできますが、おそらく、そういうディレクトリは存在せず、漏洩にはならないでしょう。

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

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

（まだ続く）

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

INTER-Mediatorはデータベースの内容を取り出し、Webページに展開し、場合によっては書き直したデータをデータベースに書き戻します。この一連のDBを中心としたデータの流れがあるのですが、Webアプリケーションではこれだけではすべてはまかなえません。HTMLでページを作るときは写真などの画像を別のファイルで供給します。このHTML外に実データが存在するようなものを「メディア」と呼ぶことにします。

メディアにはいろいろな種類があります。主要なものはIMGタグ要素で表示する画像、OBJECTタグなどで表示するFlashのコンテンツやビデオなど、そしてリンク先で得られるものとなるでしょうか。また、それぞれ、サーバ上にスタティックにあるものや、データベースのオブジェクト型フィールドに存在する場合もあります。WebページからこれらにアクセスするためのものがMediaAccessクラスです。概ね、次のような用途に使用方法は分類できます。

  • サーバ上にある画像ファイルを参照する
  • FileMakerのオブジェクトフィールドを参照する
  • データ生成を指定したクラスにさせる、生成結果を返す

ここで、単なる画像は普通にHTMLを書けばいいじゃないかと思うかもしれませんが、MediaAccessクラスを使う理由は、認証やアクセス権の設定との連携が可能になっているところです。

サーバ上にある画像ファイルを参照する

スタティックな画像で、認証が絡まない場合は、普通にIMGタグを記述します。また、画像ファイル名やパスがデータベースにある場合でも、必ずしもMediaAccessクラスは必要ないかもしれません。たとえば、あるテーブルのfilepathフィールドにファイル名が記録されているのなら、このようなIMGタグで表示できるでしょう。#srcにより、この要素のSRC属性にフィールドのデータが追加されます。

<img src=”figs/” class=”IM[context@filepath@#src]” />

ページの内容を認証しなければ参照できないようにしたとき、やはりページに埋め込んだ画像なども認証を経由したいと考えます。Webサーバレベルでの認証の場合は、ある意味、認証がない場合と概ね同じことで可能ですが、INTER-Mediatorの認証機能を使った場合、SRC要素がスタティックな画像を参照していれば、もしかしたら、認証しなくても画像だけは見えてしまうかもしれません。そんなことをしても大した情報流出にならないとも言えるのですが、ガードしたいものはガードするのが基本ですし、認証しているのに一部は誰でも見えるのは正しい運用ではありません。

そこで、IM_Entry関数の2つ目の引数（つまりオプション引数）に、’media-root-dir’というキーで、サーバ上にあるメディアファイルのフォルダへのルートからの絶対パスを指定しておきます。たとえば、

‘media-root-dir’ => ‘/var/www/images’,

となっていたとします。あるページファイルで使われている定義ファイルのパスがcontext.phpだったとします。すると、次の部分URLが、メディアを返します。ここで背後では、MediaAccessクラスが使われており、このクラスがメディアに対するプロキシになっているとも言えます。

context.php?media=ch1/shot345.png

たとえば、IMGタグのSRC属性に上記のURLを記述すれば、media-root-dirと合成して、「/var/www/images/ch1/shot345.png」というファイルをアクセスし、その内容を取り出して、適切なMIMEタイプのヘッダとともに出力をします。

前記のURLにある画像ファイル名「shot345.png」がフィールドpicfileにあるような場合には、ページファイルの要素には以下のような記述ができます。media=は決められたキーワードです。

<img src=”context.php?media=ch1/” class=”IM[table@picfile@#src]” />

このとき、定義ファイルで認証が必要な設定になっていると、SRC属性のURLからの取得時にMediaAccessクラス内部で、認証の確認を行います。ここで、一般の認証時に使っているクレデンシャルをそのまま使うことが実はできません。一般の認証では、1つのアクセスごとに異なるチャレンジデータを使うことで、認証の乗っ取りをしにくくしています。しかし、そのためにメディア処理ではその仕組みが使えません。なぜなら、メディアへのアクセスは並列的にブラウザから行うからです。

そこで、メディアアクセス時の認証のためだけのクレデンシャルを生成させるようにしています。たとえば、直前のimgタグ要素の場合、tableという名前のコンテキストからの取得となりますが、そのコンテキスト定義（IM_Entry関数の第1引数）の’authentication’キー内部の’media-handling’キーの値をtrueにします。すると、このコンテキストのデータを取得するときに、サーバ側からメディア用のクレデンシャルを出力します。

IMGタグ要素などから実際にメディア取得を定義ファイルに対して行うとき、media=があれば、MediaAccessクラスに処理をまかせます。そのとき、クレデンシャルがクッキーに記録されてサーバ側に到達し、それを発行したクレデンシャルと比較することで認証が通っているかどうかを判定します。つまり、コンテキストが得られるということは認証が通っているわけで、その信頼関係をもとに秘密の合い言葉をやりとりします。このクレデンシャルは繰り返し使われる可能性があります。クッキーに記録し、時間が来れば消去するようにはなっているものの、クレデンシャルを盗まれるのはそれだけでメディアアクセスを可能にしてしまうことになります。従って、HTTPS（SSL）でのサーバ運用は必須とも言えるでしょう。

普通のHTMLでMediaAccessを経由させる

Webページを作って画像を埋め込むと、<img src=”img/cover.jpg” /> などと記述します。これをMediaAccessクラスを使ってデータの取り出しを行いたいとしたら、ソースを全部変更しないといけないのかというとそうではありません。リダイレクトを使うことで、HTMLソースはそのままに、MediaAccessクラスを使うことができます。たとえば、.htaccessファイルを作り、たとえば次のような記述を作ります。

RedirectMatch img/(.+) http://host.name/myapp/context.php?media=$1

すると、<img src=”img/cover.jpg” /> は、<img src=”http://host.name/myapp/context.php?media=cover.jpg” /> と同じことになるわけです。

部分パスと絶対パス、それらを消したり追加したりといろいろ複雑にはなりますが、このスタティックなメディアを認証した上で表示できるようにしたのがMediaAccessの最初のインプリメントでした。

（この内容、続く）

[IM]PHP Ver.5.3 on OS Xで、APCを稼働させる方法

ファイルのアップロードをするときのプログレスバーを出す方法が「A Simple PHP Upload Progress Bar」というページに紹介されています。シンプルなのでやりやすそうと思われるのか、このサイトのスクリプトを単にコピーしただけのサイトなんかもあります（せめて出展くらい出すべきでしょう）。

当初、動かし方を紹介したサイトはないかと思って探したのが「Mac OS XのPHP 5.3にAPC(Alternative PHP Cache)をインストールする方法」というサイトでした。OS X Lion時代のものなのかこの通りでは動かなかったので、追加で必要な作業をまとめてみました。

プログレスバーを出す仕組みはちょっとややこしいのですが、ポイントの1つはPHPのAPC（Alternative PHP Cache）という機能を利用することです。残念ながら、PHP 5.3では生の状態ではこの機能は使えません。この機能を、OS X Moutain Lion + OS X Server Ver.2.2 + FileMaker Server 12という状況で使えるようにする方法を解説します。PHPは、Ver.5.3.13です。FileMaker Serverでない場合php.iniファイルの扱いが違ってくると思われます。

  1. Webサーバ稼働マシンに、Xcodeをインストールしてください。Xcode 4.6.2で以下の動作は確認しています。
  2. MacPortsをインストールします（インストール済みならもちろん何もしなくてもOKです）。まず、以下のコマンドでダウンロードします。以下のURLはアップデートにより変更されるかもしれません。
    curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.1.3-10.8-MountainLion.pkg
  3. 以下のコマンドでインストーラを使ってMacPortsをインストールします。
    sudo installer -target / -pkg MacPorts-2.1.3-10.8-MountainLion.pkg
  4. 以下のコマンドで、autoconfiをインストールします。
    sudo port install autoconf
  5. 以下のコマンドで、pcreをインストールします。
    sudo port install pcre
  6. 以下のコマンドで、ヘッダファイルの1つをコンパイラが認識するディレクトリにコピーします（参考）。
    sudo cp /opt/local/include/pcre.h /usr/include
  7. APCのソースをダウンロードします。URLはアップデートによって変更があるかもしれません。
    curl -O http://pecl.php.net/get/APC-3.1.13.tgz
  8. アーカイブを展開します。
    tar zfvx APC-3.1.13.tgz
  9. カレントディレクトリに移動します。
    cd APC-3.1.13
  10. 以下のコマンドを入れます。
    phpize
  11. 次のように表示されます。warningがありますが、問題ない模様です。
    Configuring for:
    PHP Api Version: 20090626
    Zend Module Api No: 20090626
    Zend Extension Api No: 220090626
    configure.in:3: warning: prefer named diversions
    configure.in:3: warning: prefer named diversions
  12. おなじみの以下のコマンドでコンパイルします。
    make
    sudo make install
  13. 最後のコマンドで以下のようなメッセージが表示されます。1行目のパスをphp.iniファイルに記述するので、コピーしておくといいでしょう。
    Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20090626/
    Installing header files: /usr/include/php/
  14. php.iniファイルを変更します。以下のパスは、Mountain Lion + FMS12の場合です。使用する状況に合わせて正しいphp.iniファイルを編集します。もし、ない場合は、/etc/php.iniあたりに作成します。使用しているphp.iniファイルのパスを調べるには、phpinfo関数の出力を利用しましょう。
    sudo nano ‘/Library/FileMaker Server/Web Publishing/publishing-engine/php/mountain lion/lib/php.ini’
  15. php.iniファイルに以下の3行を追加します。これらの設定をいままで全く行っていないのなら、そのまま追加でかまいません。すでに設定がないかどうかは検索して確認しましょう。
    extension_dir=/usr/lib/php/extensions/no-debug-non-zts-20090626/
    extension=apc.so
    apc.rfc1867=on
  16. 以下のコマンドを入力して、Apacheに設定変更を適用させます。
    sudo apachectl graceful
  17. phpinfo関数の出力を見て、APCのカテゴリがあることと、apc.rfc1867の値が「On」になっていることを確認します。

ポイントとしては、APCのコンパイルのために、autoconf、pcreが必要である点です。また、APCの設定は既定値ではrfc1867はOffですので、設定ファイルで記述してオンにしておく必要があります。

なぜ、この記事のカテゴリにINTER-Mediatorがあるかというと、この仕組みをINTER-Mediatorに組み込んだからです。

スクリーンショット 2013-06-16 16.44.40

[FMRP]TOの名前付け

パターンとして微妙、あるいはパターンと言えるほどの考察がないのじゃないのかと思われる1つのパターンを紹介しましょう。しかしながら、問題点は明確であると思います。

カテゴリ：要素

略称：ネーミング

名前：TOの名前付け（Ver.1.0）

問題：

  • TOは任意の名前が設定できる。そして自動的に名前が設定されてしまうが、そのままにすると後から混乱が生じる。
  • TOの名前は、元になるテーブル定義の名前とはまったく関係ない名前をつけてしまうこともできてしまう。
  • 1つのテーブル定義に対してたくさんのTOを定義することも多く、TO選択のポップアップメニューは混乱しがちである。TO選択時に目的のTOを確実に素早く探し出せる名前付けルールが必要である

解決策：

  • TOには、TOグループを端的に示す「グループ名」と、どのテーブルをもとしているかを示す「テーブル名」を含めた名前を付ける

フォース：

  • 1つのソリューションで一貫した名前付けのルールを持たせないと混乱する
  • グループ名とテーブル名だけでは、時として同じ名前の異なるTOが登場し、完全な名前付けができない。そこで、バリエーションにあるように、「用途名」といった補助的な名前を追加する必要が発生する

バリエーション：

  • 「グループ名_テーブル名」を基本とする。TOグループ内で同じテーブル定義を元にしたTOが複数登場する場合には、用途に応じて、「グループ名_テーブル名_用途名」、あるいは、「グループ名_用途名_テーブル名」をTO名とする。この名前付けルールだと、TO選択のポップアップメニュー等で、同一TOグループの項目がまとまる。その中で後半のテーブル名や用途名を見つけ出すという作業になる。TOグループを基準に考える場合には適した方法であると言える。
  • 「テーブル名_グループ名」を基本として、前記のバリエーションと同様に、さらに用途名を付け加える。この名前付けルールだと、TO選択のポップアップメニュー等で、同一のテーブル定義をもとにしたTOがまとまる。その中で後半のTOグループ名や用途名を見つけ出すという作業になる。テーブル定義名を基準に考える場合には適した方法であると言える。
  • TOの結合の流れに従って名前を付ける。名前からリレーションシップの中での関係が一目瞭然になるが、TO名が長くなり過ぎる傾向がある

関連パターン：（TBD）

FileMakerリレーションパターンの前提知識

本当はこれを最初にまとめないといけないのかもしれません。そもそも、パターンの記述を読み込むための前提知識は前提知識として定義できるはずです。パターン集ではあまりそういう記述を見ませんが、パターンなのか、たんなる機能なのかを判断する上でも、必要な情報と考えます。つまり、前提知識はパターンではないというところが出発点です。前提知識は、問題解決というよりも、単一の機能であるとも言えるかもしれません。以下、見出しが前提知識として提示します。

テーブル、フィールドといったデータベースの基本

データベースあるいは表形式のデータそのものは、フォーマットです。もしかすると、広い意味でのシステム構築パターンには「データベースを使う」というのがあるかもしれませんが、ここではリレーショナルデータベースを使用した場合の設計に関する問題解決にフォーカスしているので、フィールドやレコードといった存在、あるいはその概念は前提知識とします。

テーブル演算によるデータ処理

テーブル演算そのものは、パターンでないと考えますが、パターンの中で特定のテーブル演算を使うことはあり得ます。言い換えれば、テーブル同士の演算があるという前提から出発している話なので、これらも前提知識とします。

リレーションシップによるテーブル結合

前項と同じ意味ですが、テーブル同士は結合できるという事実も、前提知識です。いや、むしろ、この仕組みが出発点なのです。これはパターンではなく、いちばんコアな意味での前提知識と言えるでしょう。

FileMakerに関する機能

ここの切り分けが難しいところですし、どこまでの機能が前提知識で、どこからがパターンなのかは問題解決への貢献度や、自明さから考えることになるでしょう。「レイアウト」というのは機能であり、動作は明確であり、目的を持って使えるものです。しかしながら、レイアウトの機能でも「データに応じて文字列の色を変更したい」という問題点から出発すれば、「条件付き書式」はパターンかもしれません。一方、条件付き書式に対するトレードオフはFileMakerで実装しているかどうかの問題しかなく、問題解決で発生する葛藤は薄いでしょう。そうなると、「条件付き書式」はやっぱり単なる機能でしかないかなと考えるわけです。機能そのものがパターンになり得る場合も一部はあると考えますしかしながら、一般には機能そのものはパターンにはなり得ないと考えます。

他に項目を思い付いたらまた追記します。