ひみつのPDFフォーム（その５）

※このブログの内容は、アドビ社から公開されている情報に基づき、個人の趣味で記述しています。

PDFフォームにセキュリティロックをかけることで、PDFフォームのレイアウトやJavaScriptを変更されたり、読み取られるリスクを回避できます。

※OS： Windows 7 Ultimete SP1
※Webブラウザ： IE 8.0, Safari 5.1.5
※PDF表示： Adobe Reader X 10.1.3
※PDF作成： Adobe Acrobat X Pro 10.1.3
※PDFフォーム作成： Adobe LiveCycle Designer ES2 9.0.0

PDFフォームのコンテンツプロバイダにとっては、レイアウトを変更されたり、JavaScriptを変更されることを警戒すべきです。
特にJavaScriptは、悪意のある者がコードを書き換えて再配布した場合には、セキュリティの脅威になります。
（ユーザは、Adobe Reader XのJava Scriptを無効にすることにより、全てのJavaScriptによるPDFフォームへのアクセスを抑止できます。　→ 過去記事参照）

Adobe LiveCycle Designer ES2には、パスワードを設定することにより、印刷の禁止や、編集（PDFフォームのデザインやJavaScriptへのアクセス）の禁止することができます。

メニューから「ファイル」 - 「フォームのプロパティ」を選択し、「フォームのプロパティ」ダイアログボックスを表示します。
『PDFセキュリティ』タブで、上記のセキュリティ設定ができます。


当ブログからリンクしているサンプルPDFフォームは、全て、上記のPDFセキュリティ設定をしていますので、PDFフォームのデザインやJavaScriptにアクセスするためには、パスワードの入力が必要になります。


PDFセキュリティを設定していないPDFフォームは、Adobe Acrobat Pro X付属のLiveCycle Designer ES2を用いて、PDFフォームの内容を開けるだけでなく、デザインやJavaScriptを修正して再び保存（改変）できてしまいます。

XFA XML表示タブを使えば、細かい改変が容易です。


PDFやPDFフォームコンテンツのセキュリティは、コンテンツプロバイダにとっては頭が痛い問題ではないでしょうか。
特にインターネット上で公開している場合は、伝送路はSSL/TLSで暗号化できても、Webブラウザより先では保護が効きません。
電子書籍など、コンテンツ自体に商品価値があるものに関しては、DRM（Digital Rights Management、デジタル著作権管理）の導入が考えられますが、専用ブラウザやプラグインが必要になり、また、解除するためのハッキングツールなどが登場することで、いたちごっこになっています。

Wikipedia : デジタル著作権管理
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E8%91%97%E4%BD%9C%E6%A8%A9%E7%AE%A1%E7%90%86

しかし、JavaScriptを用いた、いわば『トリック』のような『なんちゃって保護』は、JavaScriptを無効にされた場合、同時に無効化してしまいます。
これをフェイルセーフにするには、JavaScriptが無効になっていることを前提にしたPDFの保護ができることが条件になります。
そのような機能を保有する製品が販売されてはいますが、いずれも、専用ブラウザ、もしくは、プラグインのインストールが必要になり、サーバサイドにも特殊なサーバを設置する必要があり、ある程度の不便と引き換えになります。

現在、インターネット上に、MS Office製品（WordやExcelなど）の生データを公開しているケースは急激に現象しており、PDF、PDFフォームへの切り替えが進んでいますが、これらについても、不正コピーや改変を防止するための対策を講じておく必要があるといえます。

[シリーズブログ]
ひみつのPDFフォーム
[1] [2] [3] [4] [5]

タグ：PDF

ひみつのPDFフォーム（その４）

※このブログの内容は、アドビ社から公開されている情報に基づき、個人の趣味で記述しています。

Webサーバ上の非公開ディレクトリ上にあるPDFフォームをWebブラウザで表示するには、Java Servletを使えば簡単にできます。

※OS： Windows 7 Ultimete SP1
※Java SE： Java SE SDK 6 Update 19
※Java IDE： Eclipse 3.7.2 Indigo SR2
※　＋ Pleiades All in One e3.7 Java
※Webサーバ/APサーバ： Apache Tomcat 6.0.35
※Webブラウザ： IE 8.0, Safari 5.1.5
※PDF表示： Adobe Reader X 10.1.3
※PDF作成： Adobe Acrobat X Pro 10.1.3
※PDFフォーム作成： Adobe LiveCycle Designer ES2 9.0.0

あらかじめ、Java SEのJREを、JDKのJREランタイムに変更しておきます。
※このための設定方法は割愛します。ネットで検索するなどして調べてください。

あらかじめ、Eclipseに、Apache Tomcat v6.0をインストールしておき、サーバ構成を作っておきます。
Tomcatのサーバ構成の作り方は、ここでは割愛しますが、コマンドラインから、"startup"で起動し、Webブラウザから、"http://localhost:8080/"へのアクセスにより、Tomcatのトップページが表示される状態になっているとします。
※このための設定方法は割愛します。ネットで検索するなどして調べてください。

Eclipseを起動し、メニューから「ファイル」 - 「新規...」 - 「動的 Webプロジェクト」を選び、適当なプロジェクト名を付けます。
<

プロジェクトエクスプローラ上の、作成した動的 Webプロジェクトで右クリックし、「新規」 - 「サーブレット」を選び、適当なJavaパッケージ名を付けます。
ここでは、クラス名は"LoadPdfTemplate"にして、完了をクリックします。


できあがったサーブレットの雛形"LoadPdfTemplate.java"に、Javaでコードを書いていきます。


今回は、HTTP GETリクエストでPDFフォームを返すようにするため、doGetメソッドにコードに、コードを書きます。
おおまかな処理の流れは、以下のようになります。
(1) HTTPリクエストパラメタから、PDFテンプレート名称を取得
(2) HTTPレスポンスヘッダを設定
(3) サーバ側で公開されていないディレクトリ上にあるPDFテンプレートを読み込み、
　読み込んだPDFテンプレートを、HTTP RESPONSEへ出力ストリームで返す

これらの処理を、Javaで記述します。
doGetメソッドのコードは、エラー処理や、リソース処理などを極力省いて簡略化し、エッセンシャルのみを記述しています。

/**
 * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
 */
protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
    // TODO Auto-generated method stub
    // (1) HTTPリクエストパラメタから、PDFテンプレート名称を取得
    String template = request.getParameter("template");
    if (template != null) {
        // PDFテンプレートファイルのフルパス
        final String TEMPLATE_BASE = "c:\\pdf_template";
        String templateFilePath = TEMPLATE_BASE + "\\" + template;
        System.out.println("INFO: PDF=" + templateFilePath);
        File templateFile = new File(templateFilePath);

        // (2) HTTPレスポンスヘッダを設定
        response.setContentType("application/pdf");
        response.addHeader("Accept-Ranges", "none");
        response.setContentLength((int)templateFile.length());
        response.addHeader("Expires", "0");

        // (3) サーバ側で公開されていないディレクトリ上にあるPDFテンプレートを読み込み、
        //   読み込んだPDFテンプレートを、HTTP RESPONSEへ出力ストリームで返す
        OutputStream outStream = response.getOutputStream();
        InputStream inStream = null;
        try {
            inStream = new BufferedInputStream(new FileInputStream(templateFile));
            byte[] byteBuf = new byte[4096];
            for (;;) {
                int iRead = inStream.read(byteBuf, 0, byteBuf.length);
                if (iRead < 0) {
                    break;
                }
                outStream.write(byteBuf, 0, iRead);
            }
        } catch (Exception e) {
            // TODO 自動生成された catch ブロック
            System.out.println("ERROR: PDFストリームが生成できませんでした.");
            e.printStackTrace();
        } finally {
            inStream.close();
        }
    }
    else
        System.out.println("ERROR: templateパラメタがありません.");
}

※上記コードはコピペして、煮るなり焼くなり、好きに使ってください
ソースコードを記述して、エラーや警告が無ければ、サーブレットを実行してみます。
メニューから、「実行 - 「実行」で進めると、Tomcatが起動し、サーブレットが deploy されます。

アプリケーションを実行するには、Webサーバには公開されない場所に、PDFテンプレートを配置するパスにディレクトリを作成しておく必要がありますが、ここでは、"c:\pdf_template"ディレクトリを作成し、この中に、"OrderForm102.pdf"を配置しておきます。


Webブラウザ（Safari 5.5）を起動し、以下のURLを開きます。
　　↓ 　IE8でも、結果は同じです
http://localhost:8080/WS4PDF/LoadPdfTemplate?template=OrderForm102.pdf
※localhostでの実行になります。インターネットには公開していません

このように、Webサーバ上の非公開ディレクトリ上にあるPDFフォームをWebブラウザで表示することができます。


Eclipseのコンソールには、サーブレットから出力されたコンソールメッセージが出力されています。


以上は、サーバサイドから、HTTPレスポンスのコンテンツとしてPDFファイルを返し、WebブラウザへPDFファイルを表示する基本処理になります。

[シリーズブログ]
ひみつのPDFフォーム
[1] [2] [3] [4] [5]

ひみつのPDFフォーム（その３）

※このブログの内容は、アドビ社から公開されている情報に基づき、個人の趣味で記述しています。

PDFフォームが、ローカルファイルから開かれたのか、Webサーバからダウンロードして開かれたのかを調べるには、JavaScriptを使えば簡単にできます。

※OS： Windows 7 Ultimete SP1
※Webブラウザ： IE 8.0, Safari 5.1.5
※PDF表示： Adobe Reader X 10.1.3
※PDF作成： Adobe Acrobat X Pro 10.1.3
※PDFフォーム作成： Adobe LiveCycle Designer ES2 9.0.0

Adobe LiveCycle Designer ES2のScriptエディタでスクリプトを書きます。
　topmostSubform::ready:form - (JavaScript, client)
var schema = util.crackURL(event.target.URL).cScheme;
xfa.host.messageBox("このPDFのURLスキーマは、" + schema + "です。");

LiveCycle Scriptでは、Docオブジェクトは"event.target"で取得します。
Docオブジェクトの"URL"プロパティは、開いているPDFドキュメントのURLです。
"util.crackURL(cURL).cScheme"は、URLのスキーマ部（"file", "http", "https"）を取得します。

PDFフォームをローカルファイルとして、Adobe Reader X 10.1.3で開くと、セキュリティ警告のメッセージボックスが表示されます。


セキュリティ警告のメッセージボックスに対して、「許可」を選択すると、”file”と表示されます。


Adobe Acrobat X Proでも、結果は同じです。

Safari 5.1で、Webサイトへアクセスし、PDFフォームへアクセスすると、”http”と表示されます。


IE8でも、結果は同じです。

このようなスクリプトを用いて、PDFフォームがローカルファイルから開いたのか、Webサーバから取得して開いたのかを識別することができます。

この記事で使ったPDFフォームは、ここにあります。
　↓
http://www003.upp.so-net.ne.jp/motosoft/misc/OrderForm104.pdf




PDFフォームが、ローカルファイルから開かれた場合、強制的に閉じるには、JavaScriptを使えば簡単にできます。

Adobe LiveCycle Designer ES2のScriptエディタでスクリプトを書きます。
強制的に開いた文書を閉じるためにｊは、"closeDoc(true)"メソッドを使います。
topmostSubform::docReady - (JavaScript, client)
var myDoc = event.target;
var schema = util.crackURL(myDoc.URL).cScheme;
if (schema == "file") {
      myDoc.closeDoc(true);
}
ここで注意すべき点は、closeDoc(true)メソッドで閉じるドキュメントのレンダリングが終わっているイベント処理で実行する点です。
最初の例では、"ready:form" イベントを使いましたが、ここでは、"docReady"イベントを使います。
ただし、"docReady"ということは、もたついていると文書がチラっと見えてしまうため、見せたくなければ、余計なメッセージボックスなどは表示せず、速やかに文書を閉じてください。

ここまでのスクリプトを書けば、JavaScriptが有効であるとするならば、Webサーバへ接続したときには、内容が表示されるが、ローカルファイルへ保存して、Adobe Reader Xなどから開こうとすると、すぐに閉じてしまい、無いような見えないようにすることができます。
このような、トリッキーなスクリプトを、『なんちゃってPDF保存保護』と呼んでいます。
なんとなく、PDFフォームの保存保護ができているかのように見せかける妖術です。



なお、ここで紹介しているJavaScriptによる処理は、設定により無効化できます。

Adobe Reader Xのメニューで、「編集」- 「環境設定...」を選び、『環境設定』ダイアログボックスを表示します。
左側の「分類」ペインで「JavaScript」を選び、『Acrobat Scriptを使用』のチェックを外すと、PDFフォーム内に埋め込まれたJavaScriptの実行ができなくなり、JavaScriptによる処理を無効化できます。

JavaScriptを実行させたくない場合には、チェックを外して無効にしておくとよいでしょう。

JavaScriptを無効にしたら、全ての細工が無効化されるので、『なんちゃってPDF保存保護』と呼んでいるのです。

ところで、JavaScriptが無効にされてはPDFフォームの内容が見えず、有効であって初めて閲覧可能にすることができます。
そのお話は、またいつか・・・


[シリーズブログ]
ひみつのPDFフォーム
[1] [2] [3] [4]

タグ：PDF

SOA(Service Oriented Architecture)に関連する特許が登録になりました

2007年に出願したSOA(Service Oriented Architecture)に関連する特許が登録になり、特許庁から特許証が届きました。


権利は勤務先に譲渡してるのですが、報奨金で沖縄へ行けます。
いろんな特許を出願した中では、SOAの分野で登録になったことは、特に嬉しいです。
お世話になった方々に感謝です。

SOA (service-oriented architecture)
http://www.atmarkit.co.jp/aig/04biz/soa.html


特許を出願（出願書類は、特許事務所の弁理士さんに依頼）してから、登録になるまでには、約5年間かかります。
出願から登録までの流れは、このサイトの図が詳しいです。
　　↓
http://www.tokkyonavi.com/learn/%E7%89%B9%E8%A8%B1%E6%A8%A9%E7%99%BB%E9%8C%B2%E3%81%BE%E3%81%A7%E3%81%AE%E6%B5%81%E3%82%8C.html

発明の質しだいなんですが、自分の場合は、20件ぐらい出願して、そのうちの 1件登録される、ぐらいの率です。

タグ：SOA

ひみつのPDFフォーム（その２）

※このブログの内容は、アドビ社から公開されている情報に基づき、個人の趣味で記述しています。

PDFフォームを表示するエンジン（ビューワー）の種類を調べるには、JavaScriptを使えば簡単にできます。

※OS： Windows 7 Ultimete SP1
※Webブラウザ： IE 8.0
※PDF表示： Adobe Reader X 10.1.3
※PDF作成： Adobe Acrobat X Pro 10.1.3
　　　→ 2012.4.16 : オンラインアップデートで 10.1.3が提供開始されました
※PDFフォーム作成： Adobe LiveCycle Designer ES2 9.0.0


Acrobat Scriptで書くと、こうです。
topmostSubform.Page1::ready:form - (JavaScript, client)
app.alert("使われているPDF表示エンジンは、" + app.viewerType + "です。");

LiveCycle Scriptで書くと、こうです。
topmostSubform.Page1::ready:form - (JavaScript, client)
xfa.host.messageBox("使われているPDF表示エンジンは、" + xfa.host.appType + "です。");

どちらも処理結果は同じですが、これから始める人は、LiveCycle Scriptで書くほうがよいでしょう（Acrobat Scriptは、deplicatedなものがあります）。
Adobe LiveCycle Designer ES2のScriptエディタでスクリプトを書きます。

スクリプトを書いたら、名前をつけてPDFフォームを保存します。

PDFフォームをローカルファイルとして、Adobe Reader X 10.1.3で開くと、”Reader”と識別されます。


PDFフォームをローカルファイルとして、Adobe Acrobat X Pro 10.1.3で開くと、”Exchange-Pro”と識別されます。


Adobe LiveCycle Designer ES2上のPDFプレビューは、”Reader”と識別されます。

インターネット上に配備したPDFフォームを IE8上で、HTTPで取得して開くと、”Reader”と識別されます。
ただし、Adobe Acrobat X Proアドオンが無効になっているものとします。


IE8 のAdobe Acrobat X Proアドオンを無効から、有効に切り替えてみます。


※IE7では、「ツール」-「アドオンの管理」-「アドオンの有効化または無効化」を選び、『アドオンの管理』ダイアログボックスを表示します。しかし、IE7のデフォルトでは アドオンのバージョン番号が表示されないので、”名前”などのタイトルバーの上で右クリックし、バージョン欄を追加表示するようにする必要があります。

インターネット上に配備したPDFフォームを IE8上で、HTTPで取得して開くと、Acrobat X Proアドオンが有効であっても、”Reader”と識別されます。


また、Windowsの場合、ファイルの拡張子「.pdf」を、Adobe Reader Xで開くか、Adobe Acrobat X Proで開くかを設定できますが、この設定に関係なく、IE8で開くときは、”Reader”と識別されます。

以上、当たり前の結果なのですが、IE6などのAdobe Acrobat X ProがサポートしていないWebブラウザでは、HTTPでPDFフォームを取得した場合に、Adobe Acrobat X Proのアドオンが有効になっていると、正しい結果が返ってくる保証がありません（というか、バグがあって、誤った結果が返ってくる）ので、IE7以上にバージョンアップしましょう。

アドビ社が保証している組み合わせで使っていれば、Adobe Reader XとAdobe Acrobat X Proなどが混在していても、特別な設定をしなくても、結果は正しいのです。

このブログ記事で実証しているPDFフォームは、以下のサイトに置いてあります。
　　↓
http://www003.upp.so-net.ne.jp/motosoft/misc/OrderForm103.pdf


[2012.4.17 05:32 追試]
※OS： Windows XP SP3
※Webブラウザ： IE 7.0.5
※PDF表示： Adobe Reader X 10.1.3
※PDF作成： Adobe Acrobat X Pro 10.1.3

IE7も、IE8同様、インターネット上に配備したPDFフォームを IE8上で、HTTPで取得して開くと、Acrobat X Proアドオンが有効・無効に関わらず、”Reader”と識別されます。

また、ファイルの拡張子「.pdf」を、Adobe Reader Xで開くか、Adobe Acrobat X Proで開くかの設定に関わらず、IE7で開くときは、”Reader”と識別されます。

つまり、IE7は、IE8と挙動が同じであり、特に設定なしで、Adobe Reader Xと、Adobe Acrobat X Proの共存が可能。


[2012.4.17 05:45 追試]
※OS： Windows 7 Ultimete SP1
※Webブラウザ： Safari 5.1.5
※PDF表示： Adobe Reader X 10.1.3
※PDF作成： Adobe Acrobat X Pro 10.1.3

インターネット上に配備したPDFフォームをSafariで開く場合においても、IE8、IE7と同じく、”Reader”と識別されます。


つまり、Safariは、IE8と挙動が同じであり、特に設定なしで、Adobe Reader Xと、Adobe Acrobat X Proの共存が可能。

次回は、ローカルファイルとして保存されたPDFフォームを開いた場合と、インターネット経由で取得して開いたPDFフォームの識別方式について、検証します。（複数の方式があります）

[シリーズブログ]
ひみつのPDFフォーム
[1] [2] [3]

タグ：PDF