JP5575071B2 - 情報処理装置、情報処理方法、およびプログラム - Google Patents
情報処理装置、情報処理方法、およびプログラム Download PDFInfo
- Publication number
- JP5575071B2 JP5575071B2 JP2011184767A JP2011184767A JP5575071B2 JP 5575071 B2 JP5575071 B2 JP 5575071B2 JP 2011184767 A JP2011184767 A JP 2011184767A JP 2011184767 A JP2011184767 A JP 2011184767A JP 5575071 B2 JP5575071 B2 JP 5575071B2
- Authority
- JP
- Japan
- Prior art keywords
- unit
- application
- web application
- file
- function
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Description
本発明の実施の形態は、情報処理装置、情報処理方法、およびプログラムに関する。
近年、HTMLやJava(登録商標)Scriptなどのウェブ記述言語を用いてリッチなクライアントアプリケーション(ウェブアプリケーション)を記述することが一般的になりつつある。ウェブアプリケーションとは、ネットワークを介してプログラムやデータのやりとりを行うアプリケーションソフトウェアのことである。クライアント単体で実行できるアプリケーションであっても、そのアプリケーションのプログラムやデータの一部または全体をネットワークを介してやりとりすることが可能であれば、そのアプリケーションのことをウェブアプリケーションと呼ぶ。これに伴い、デジタルテレビやスレート端末、スマートフォンといった情報処理装置で実行されるアプリケーションを、ウェブアプリケーションとして記述することも行われている。例えば、デジタルテレビにおけるIPTVなどでは、ウェブアプリケーションの技術を用いてメニュー画面や動画再生画面を表示する規格が登場している。
ウェブアプリケーションは、HTMLやJava(登録商標)Scriptなどを解釈できるブラウザベースの実行環境で実行される。このウェブアプリケーションは、一般に複数のページファイルとメディアファイルから構成される。ここで、メディアファイルとは、JPEG、GIF、MPEGなどの動画像データが納められたファイルや、MP3などの音声データが納められたファイルのことをいう。一方、ページファイルとは、文章の構造や画面表示方法や画面遷移に関する指定が記述されたファイルのことである。具体的には、表示文字データなどのページ表示情報、文字の色や大きさなどの装飾情報、画像などの配置を表す配置情報などを含む。さらに、ページファイルには、Java(登録商標)Scriptなどで記述された制御プログラムが格納される場合がある。また、Java(登録商標)Scriptなどで記述された制御プログラムだけを独立したファイルとして用意することもできる。
ページファイルに含まれる配置情報には、別のページファイルを表示、実行するためのボタン(リンク)が存在する。リンクは、そのページファイルのURL情報を含む。ウェブアプリケーションの実行中にユーザ要求などによりそのボタンが選択されると、ブラウザは、そのボタンに対応する新たなページファイルのダウンロード要求を出し、そのページファイルで利用するメディアファイルも含め、必要なファイルがそろった時点で新たなページファイルの表示、実行を開始する。この新たに表示、実行されるページファイルは、先に表示、実行していたページファイルと同一のウェブアプリケーションの場合もあれば、別のウェブアプリケーションの場合もある。
新たなページファイルの表示、実行が行われた場合、人間の目から見れば、ウェブアプリケーションが別のウェブアプリケーションに遷移したか否かを容易に識別できることが多い。しかし、ブラウザの処理としては、同一のウェブアプリケーションのページファイルを実行する方法と、別のウェブアプリケーションのページファイルを実行する方法とに違いはなく、ウェブアプリケーション間の遷移を機械的に検出することは困難である。
一方、HTMLやJava(登録商標)Scriptなどの仕様だけでは実現できない機能をソフトウェアとして実装し、HTMLやJava(登録商標)Scriptから利用できるようにしたソフトウェア部品のことを拡張機能もしくはプラグインと呼ぶ。ウェブアプリケーションでは、拡張機能を利用することが一般的になっている。例えば、ブラウザは基本機能として、単純な画像表示機能や文字表示機能、文字列操作機能、数値演算機能などを持っている。一方で、DLNA(Digital Living Network Alliance)規格に準じた動画再生機能やローカルファイルへのアクセス機能、デジタルテレビのチャンネル変更機能や音量変更機能などは、ブラウザの基本機能として備えられていない。このようにブラウザの基本機能だけでは、実現できるアプリケーションの幅が限定されるため、デジタルテレビなどにおいては、拡張機能としてこれらブラウザの基本機能では実現できない機能を実装し、HTMLやJava(登録商標)Scriptからその機能を呼出すこととなる。このほか、著名な拡張機能の例としては、Adobe社のFLASH Playerなどが存在する。
拡張機能はいわゆるネイティブコードで記述されることも多く、実現できる機能に自由度が高い。このため、セキュリティ上の観点では、使われるウェブアプリケーションを限定したい場合も多い。具体的には、ローカルファイルアクセス機能を拡張機能として提供すると、ユーザ情報流出やローカルファイルの削除、改ざんなどの危険を伴う。このため、ローカルファイルアクセス機能は、実行環境が限定された特定のウェブアプリケーションのみで利用を許可するようにしたいといったニーズがある。
しかし、上述したように、これまでウェブアプリケーション間の遷移を機械的に検出することが困難であったため、ウェブアプリケーション単位で利用を許可する拡張機能を限定するといったセキュリティポリシの使い分けが困難である。
OMTP(Open Mobile Terminal Platform)、BONDI規格、[online]、[平成23年8月25日検索]、インターネット<URL:http://bondi.omtp.org/>
W3C HTML5規格、Same−origin policy、[online]、[平成23年8月25日検索]、インターネット<URL:http://dev.w3.org/html5/spec/Overview.html>
本発明が解決しようとする課題は、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができる情報処理装置、情報処理方法、およびプログラムを提供することである。
実施形態の情報処理装置は、ブラウザ部と、アプリ範囲管理部と、終了判定部と、利用可否判定部と、拡張機能呼出し部と、を備える。ブラウザ部は、ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行する。アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する。終了判定部は、前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する。利用可否判定部は、前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する。拡張機能呼出し部は、実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す。
以下、実施形態の情報処理装置、情報処理方法、およびプログラムについて、図面を参照して説明する。
(第1の実施形態)
図1は、第1の実施形態の情報処理装置10を含む情報処理システムのハードウェア構成図である。図1に示す情報処理システムは、情報処理装置10と、サーバ装置20と、を備える。サーバ装置20は、クライアントとなる情報処理装置10に対してウェブアプリケーションを提供する。情報処理装置10は、サーバ装置20からウェブアプリケーションを実行するために必要な各種ファイルを受信して、ウェブアプリケーションを実行する。情報処理装置10とサーバ装置20は、例えばインターネットなどのネットワーク30により接続される。ウェブアプリケーションとは、ネットワークを介してプログラムやデータのやりとりを行うアプリケーションソフトウェアのことである。クライアント単体で実行できるアプリケーションであっても、そのアプリケーションのプログラムやデータの一部または全体をネットワークを介してやりとりすることが可能であれば、そのアプリケーションのことをウェブアプリケーションと呼ぶ。
図1は、第1の実施形態の情報処理装置10を含む情報処理システムのハードウェア構成図である。図1に示す情報処理システムは、情報処理装置10と、サーバ装置20と、を備える。サーバ装置20は、クライアントとなる情報処理装置10に対してウェブアプリケーションを提供する。情報処理装置10は、サーバ装置20からウェブアプリケーションを実行するために必要な各種ファイルを受信して、ウェブアプリケーションを実行する。情報処理装置10とサーバ装置20は、例えばインターネットなどのネットワーク30により接続される。ウェブアプリケーションとは、ネットワークを介してプログラムやデータのやりとりを行うアプリケーションソフトウェアのことである。クライアント単体で実行できるアプリケーションであっても、そのアプリケーションのプログラムやデータの一部または全体をネットワークを介してやりとりすることが可能であれば、そのアプリケーションのことをウェブアプリケーションと呼ぶ。
情報処理装置10は、主要なハードウェア構成として、CPU11、主記憶メモリ12、ストレージ13、ネットワークインタフェース14、ディスプレイ15、および入力機器16を備える。ストレージ13には、ブラウザプログラムと、拡張機能アクセス制御プログラムと、各種の拡張機能用のプログラム(以下、単に拡張機能という。)と、が格納されている。入力機器16は、例えば、マウス、キーボード、タッチパネルなどである。
サーバ装置20は、主要なハードウェア構成として、ストレージ21およびネットワークインタフェース22を備える。ストレージ21には、ウェブアプリケーションの構成部品であるページファイルやメディアファイルが格納されている。ページファイルとは、ページを構成するための情報が記述されたファイルであり、ページを構成するための情報としては、例えば、文章の構造や画面表示方法や画面遷移に関する指定がある。ページファイルやメディアファイルは、URLと呼ばれる位置識別子を用いて、その位置(サーバ装置20の位置とサーバ装置20内での位置)が特定される。情報処理装置10とサーバ装置20は、ネットワークインタフェース14,22を用い、ネットワーク30を介して情報のやりとりを行う。
情報処理装置10がサーバ装置20から提供されるウェブアプリケーションを実行する際には、まず下準備として、ウェブアプリケーションの実行環境であるブラウザプログラムの実行を行う。具体的には、CPU11が実行しているOS(Operating System)などのシェルプログラムが、ユーザの要求等に従い、ブラウザプログラムをストレージ13から読み出して主記憶メモリ12に保存する。そして、CPU11が、主記憶メモリ12に保存されたブラウザプログラムを実行する。その際、CPU11は、ブラウザプログラムとは別プログラムとなっている各種の拡張機能(プラグイン)をストレージ13から読み出し、主記憶メモリ12に保存する。
ウェブアプリケーションは、ユーザもしくはプログラム中からウェブアプリケーションに含まれるページファイルのURLが指定されることにより、その実行が開始される。その際、CPU11は、ネットワークインタフェース14に対して、指定されたURLのページファイルの取得命令を出す。ネットワークインタフェース14は、指定されたURLにより特定されるサーバ装置20に接続し、指定されたURLに該当するページファイルのダウンロード命令を出す。サーバ装置20のネットワークインタフェース22は、このダウンロード命令に応じてストレージ21から該当するページファイルを読み取り、クライアントである情報処理装置10に返す。情報処理装置10のネットワークインタフェース14は、サーバ装置20から取得したページファイルを主記憶メモリ12に保存する。ページファイルには、そのページファイルで利用するメディアファイルのURLが列挙されている。CPU11は、ページファイルの取得時と同様に、ネットワークインタフェース14に対してこれらメディアファイルの取得命令を出す。そして、ネットワークインタフェース14がサーバ装置20に対してこれらメディアファイルのダウンロード命令を出し、このダウンロード命令に応じてサーバ装置20のストレージ21から読み取られ、情報処理装置10に送られたメディアファイルを取得して、主記憶メモリ12やストレージ13に保存する。
ウェブアプリケーションの実行に必要なファイルが用意された時点で、ブラウザプログラムは、主記憶メモリ12に保存されたページファイルをCPU11が解釈できる命令に変換する。そして、CPU11が、変換された命令を実行する。実行結果は、ページファイルに含まれる配置情報に従ってディスプレイ15に出力される。
配置情報には、別のページファイルへ遷移するためのリンクが含まれている。このリンクは、遷移先のページファイルのURLと関連付けられている。ユーザ操作などによりそのリンクが選択されると、CPU11は、ネットワークインタフェース14に対して、そのリンクに関連付けられたURLのページファイルの取得命令を出す。そして、上記と同様に、サーバ装置20からそのURLにあるページファイルおよび当該ページファイルで利用するメディアファイルを取得し、必要なファイルがそろった時点で新たなページファイルの表示、実行を開始する。
図2−1は、CPU11がページファイルを実行した場合にディスプレイ15に表示される画面の一例を示す図である。この図2−1の画面例では、「動画メニュー画面」という文字データ1や「起動したい画面を選んで下さい」という文字データ3、画像データ2に加えて、「動画検索画面」へのリンク4、「本日の動画再生画面」へのリンク5、および「お気に入りリスト画面」へのリンク6が存在する。ユーザ操作などによりこれらのリンク4,5,6のいずれかが選択されると、リンク先のページファイルが実行されて、ディスプレイ15の表示が例えば図2−2のように変化する。図2−2は、図2−1の画面で「本日の動画再生画面」へのリンク5が選択された場合にディスプレイ15に表示される画面の一例を示している。
本実施形態の情報処理装置10は、ストレージ13に、ブラウザプログラムに加えて、拡張機能アクセス制御プログラムを格納している。図3は、情報処理装置10のCPU11が、ブラウザプログラムおよび拡張機能アクセス制御プログラムを実行することにより実現される情報処理装置10内部の機能的な構成を示す機能ブロック図である。図3に示すように、情報処理装置10では、ブラウザプログラムの実行によりブラウザ部200が実現され、拡張機能アクセス制御プログラムの実行により拡張機能アクセス制御部100が実現される。
ブラウザ部200は、アプリケーション実行部210と、拡張機能呼出し依頼部220と、を備える。
アプリケーション実行部210は、ページファイル間の遷移要求に応じて、ページファイルおよびそのページファイルで利用されるメディアファイルを、サーバ装置20からネットワーク30を介して受信し、配置情報をもとに文字や画像をディスプレイ15に表示する機能を持つ。また、アプリケーション実行部210は、ページファイルに含まれるJava(登録商標)Scriptなどで記述された制御プログラムを実行する機能を持つ。
拡張機能呼出し依頼部220は、ブラウザ部200の起動時に、ストレージ13に格納されている拡張機能の初期化を依頼する機能を持つ。また、拡張機能呼出し依頼部220は、ページファイルに含まれるプログラムの実行中に拡張機能の呼出しを検知し、拡張機能アクセス制御部100に対して呼出し先の拡張機能の識別子と呼び出す関数名を通知し、拡張機能の呼出しを依頼する機能を持つ。
拡張機能アクセス制御部100は、拡張機能の読み込みや呼出しを行う拡張機能管理部110と、拡張機能の呼出し時に呼出し可否の判定を行うアクセス制御実行部120と、実行中のウェブアプリケーションのアプリ構成情報の管理を行うライフサイクル管理部130と、を備える。
本実施形態の情報処理装置10では、ブラウザ部200が起動する際に、拡張機能呼出し依頼部220が呼び出される。拡張機能呼出し依頼部220は、拡張機能アクセス制御部100に対して拡張機能の初期化を依頼する。拡張機能アクセス制御部100の拡張機能管理部110は、拡張機能の初期化の依頼を検出し、ストレージ13から拡張機能を主記憶メモリ12に読み込み、拡張機能が持つ命令(関数)の呼出し先アドレスを格納する。このとき、ストレージ13から主記憶メモリ12に読み込む拡張機能は複数であってもよい。例えば、DLNA動画プレーヤ拡張機能と、ローカルファイルアクセス拡張機能とが別個の拡張機能として提供されてストレージ13に格納されている場合、これらDLNA動画プレーヤ拡張機能とローカルファイルアクセス拡張機能とをストレージ13から主記憶メモリ12に読み込む。DLNA動画プレーヤ拡張機能には、再生命令、再生停止命令、動画リスト取得命令などが含まれる。ローカルファイルアクセス拡張機能には、ファイル削除命令、ファイルリスト取得命令などが含まれる。
さらに、拡張機能管理部110は、各拡張機能を識別するための識別子のリストを主記憶メモリ12に格納する。この識別子は、後述の拡張機能呼出し部112が拡張機能を呼出す際に、呼出す拡張機能を決定するために利用される。この識別子としては、具体的にはMIMEタイプ、ファイルの拡張子などを用いればよい。例えばMIMEタイプで拡張機能を識別する場合、DLNA動画プレーヤ拡張機能にはvideo/dlna−player、ローカルファイルアクセス拡張機能にはapplication/file−managerなどの名前を付ける。この識別子は、独自の拡張機能であれば、拡張機能の開発者が自由に決めることができる。
拡張機能は複数の命令(関数)を持つことができ、個々の関数は、拡張機能の識別子と関数名の指定により、ウェブアプリケーションから呼出される。拡張機能管理部110は拡張機能の管理テーブルを持ち、個々の拡張機能で同じ関数名の関数があっても拡張機能の識別子で呼出す関数を区別できる。図4は、拡張機能管理部110が生成、管理する拡張機能管理テーブルの一例を示す図である。この図4に示す拡張機能管理テーブルの例では、拡張機能の識別子として、video/dlna−playerとapplication/file−managerとが存在し、関数名getfilelistは両方の拡張機能に存在する。拡張機能の呼出し時には、識別子と関数名との組が渡される。例えば、識別子application/file−managerと、関数名getfilelistとの組の呼出し依頼が拡張機能呼出し依頼部220から拡張機能管理部110にあった場合には、拡張機能管理部110は、図4に示すような拡張機能管理テーブルを参照し、指定された識別子と関数名に合致するアドレス56789に格納された関数を呼出す。
アプリケーション実行部210は、ページファイル間の遷移時に、拡張機能アクセス制御部110に対して遷移先ページファイルの位置識別子であるURLを通知し、アプリ構成情報の更新を依頼する。
アプリ構成情報は、対応するウェブアプリケーションに含まれる1つ以上のページファイルを表すアプリ範囲情報と、当該ウェブアプリケーションで利用が許可された拡張機能を表す情報である利用証明書と、を含む。アプリ範囲情報は、ウェブアプリケーションに含まれる各ページファイルの位置情報である。例えば、ウェブアプリケーションに含まれる各ページファイルの位置情報をリスト、具体的には位置識別子のリスト(以下、URLリストという。)にした情報などである。このURLリストは、ウェブアプリケーションがファイルを利用する場合に使用される。このとき、ブラウザ部10はファイルをサーバ装置20から能動的に取得しても、受動的に受け取ってもよい。以下の実施形態では、リストの形式で説明するが、アプリ範囲情報は特にリストに限定されるものではなく、ウェブアプリケーションに含まれる各ページファイルの位置情報が特定できるものであればよい。また、利用証明書も対応するウェブアプリケーションにおいて利用することが許可されたすべての拡張機能に対する利用証明書がリスト形式(以下、利用証明書リストという。)で記述されている。これらURLリストと利用証明書リストとを含むアプリ構成情報は、例えば、対応するウェブアプリケーションで最初に実行されるページファイルに組み込まれて提供される。
図5−1は、ページファイルに組み込まれたアプリ構成情報のデータ構造の一例を示す図であり、図5−2は、図5−1のデータ構造に従って記述されたアプリ構成情報の一例を示す図である。この図5の例では、「アプリ構成情報開始識別子」である<appinfo>のタグと「アプリ構成情報終了識別子」である</appinfo>のタグとに挟まれた部分の情報が、アプリ構成情報である。また、アプリ構成情報内の「位置識別子情報開始識別子」である<url_list>のタグと「位置識別子情報終了識別子」である</url_list>のタグとに挟まれた部分の情報が、URLリストである。また、アプリ構成情報内の「拡張機能利用証明書開始識別子」である<cert_list>のタグと「拡張機能利用証明書終了識別子」である</cert_list>のタグとに挟まれた部分の情報が、利用証明書リストである。なお、本実施形態では、ウェブアプリケーションを構成するページファイルの一覧としてURLリストを用いるが、ウェブアプリケーションの範囲を特定可能な情報であれば、URLリスト以外の情報、例えばウェブアプリケーションを構成するページファイルのファイル名一覧などを用いてもよい。
アクセス制御実行部120は、拡張機能呼出し依頼部220から呼出しが依頼された拡張機能の呼出し可否を判定し、拡張機能へのアクセス制御を実行する機能を有する。アクセス制御実行部120は、拡張機能呼出し依頼部220から呼出しが依頼された拡張機能が呼出し可能と判断すれば、拡張機能管理部110に対して拡張機能の呼出しを依頼する。
ライフサイクル管理部130は、アプリ構成情報の更新依頼があった場合に起動され、必要に応じて、現在実行中のウェブアプリケーションに対応するアプリ構成情報の更新を行う機能を有する。このため、ライフサイクル管理部130は、遷移先ページにアプリ構成情報が含まれるか判定する機能や、ウェブアプリケーションの開始、終了、実行継続の判定を行う機能を持つ。
本実施形態の情報処理装置10では、ライフサイクル管理部130が、ウェブアプリケーションの実行中にページの遷移があるたびに、遷移先ページの内容によってウェブアプリケーションの開始、終了、継続実行を自動的に判断する。そして、ウェブアプリケーションの実行中に拡張機能の呼出し要求があった場合には、アクセス制御実行部120が、ライフサイクル管理部130が管理しているアプリ構成情報に含まれる利用証明書リストをもとに、拡張機能のアクセス制御を行う。
図6は、図3に示した情報処理装置10内部の機能的な構成をより詳細化した機能ブロック図である。以下、図6を用いて情報処理装置10の詳細な構成を説明する。
拡張機能管理部110は、拡張機能ロード部111と、拡張機能呼出し部112と、を備える。
拡張機能ロード部111は、ストレージ13に格納されている拡張機能を列挙して主記憶メモリ12へロードする。ストレージ13に格納されている拡張機能の列挙には、特定の拡張子を持つファイル名による区別や、拡張機能に特定関数が用意されているかどうかによる区別、特定のファイルに予め拡張機能のファイル名を列挙しておくなどの手段を用いればよい。拡張機能のロードに際して、拡張機能ロード部111は、各拡張機能の識別子ごとに、拡張機能が持つ関数のアドレスと関数名の対応関係を、図4に示した管理テーブルとして主記憶メモリ12に保存する。この対応関係の取得には、拡張機能の特定関数を呼び出す方法や、予め別ファイルに対応関係を記述しておく方法などがある。
拡張機能呼出し部112は、ブラウザ部200の拡張機能呼出し依頼部220から拡張機能の呼出し依頼があった場合に、呼出す拡張機能の識別子と関数名を受け取り、拡張機能の呼出しを行う。拡張機能呼出し部112は、拡張機能ロード部111が主記憶メモリ12に保存した拡張機能の管理テーブルから、受け取った識別子と関数名に対応する関数のアドレスを取得し、そのアドレスに存在する拡張機能の関数を実際に呼出す処理を行う。
アクセス制御実行部120は、拡張機能アクセス検出部121と、拡張機能呼出し可否判定部122と、を備える。
拡張機能アクセス検出部121は、拡張機能呼出し依頼部220からの呼出し依頼と呼出し情報を受信し、拡張機能呼出し可否判定部122を呼出す。呼出し情報には、呼出す拡張機能の識別子と関数名が含まれる。拡張機能アクセス検出部121は、この拡張機能の識別子と関数名を渡して拡張機能呼出し可否判定部122を呼出し、該当する拡張機能の呼出し可否の判定および拡張機能の呼出しを依頼する。
拡張機能呼出し可否判定部122は、拡張機能アクセス検出部121からの依頼を受け、呼出す拡張機能の識別子と関数名を受け取り、拡張機能の呼出し可否を判定する。この呼出し可否の判定のために、拡張機能呼出し可否判定部122は、ライフサイクル管理部130の後述する拡張機能利用証明書保存部136から現在実行中のウェブアプリケーションに対応するアプリ管理情報の利用証明書リストを取得する。そして、拡張機能呼出し可否判定部122は、呼出す拡張機能についての利用証明書が利用証明書リストに含まれていれば、呼出しが許可されていると判断し、拡張機能呼出し部112に対して、呼出す拡張機能の識別子と関数名を渡して呼出しを依頼する。
ライフサイクル管理部130は、ページ遷移検出部131と、ページ種別振分け部132と、アプリ設定ロード部133と、アプリ終了判定部134と、アプリ範囲管理部135と、拡張機能利用証明書保存部136と、を備える。
ページ遷移検出部131は、ブラウザ部200で実行中のページが切り替わったことを検出し、ページ種別振分け部132に対して、遷移先ページの位置識別子であるURLを通知する。
ページ種別振分け部132は、遷移先ページのページファイルのMIMEタイプや拡張子、ページファイルの内容に特定タグが付加された情報が存在するかどうかなどにより、そのページファイルにアプリ構成情報が含まれているか否かを判定する。そして、ページ種別振分け部132は、ページファイルにアプリ構成情報が含まれているか否かの判定結果に基づき、新たなウェブアプリケーションの開始かどうかを判定する。本実施形態では、ウェブアプリケーションで最初に実行されるページファイルに、アプリ構成情報が含まれている。したがって、ページ種別振分け部132は、遷移先ページのページファイルにアプリ構成情報が含まれていれば、新たなウェブアプリケーションの開始であると判定することができる。新たなアプリケーションの開始と判定した場合、ページ種別振分け部132は、アプリ設定ロード部133を呼出す。
アプリ設定ロード部133は、遷移先ページのページファイルに含まれる、新たなウェブアプリケーションに対応したアプリ構成情報をロードする。その際、アプリ設定ロード部133は、アプリ範囲管理部135に対して、アプリ構成情報のURLリストを渡し、URLリストの保存命令を出す。さらに、アプリ設定ロード部133は、拡張機能利用証明書保存部136に対して、アプリ構成情報の利用証明書リストを渡し、利用証明書リストの保存命令を出す。
アプリ終了判定部134は、ページファイルの遷移時に、現在実行中のウェブアプリケーションが終了したかどうかを判定する。具体的には、アプリ終了判定部134は、アプリ範囲管理部135から現在実行中のウェブアプリケーションの範囲を表すURLリストを取得し、遷移先ページの位置識別子であるURLが、そのURLリストに含まれるか否かを判定する。そして、アプリ終了判定部134は、遷移先ページのURLがURLリストに含まれる場合にはウェブアプリケーションの実行継続と判定し、遷移先ページのURLがURLリストに含まれない場合には、ウェブアプリケーションの終了と判定する。アプリ終了判定部134は、ウェブアプリケーションの終了と判定した場合、アプリ範囲管理部135に対して、保存しているURLリストの消去命令を出すとともに、拡張機能利用証明書保存部136に対して、保存している利用証明書リストの消去命令を出す。
アプリ範囲管理部135は、URLリストの保存命令、取得命令、消去命令を受け取り、その命令に応じて、主記憶メモリ12に保存してあるURLリストの更新や取得を行う。
拡張機能利用証明書保存部136は、利用証明書リストの保存命令、取得命令、消去命令を受け取り、その命令に応じて、主記憶メモリ12に保存してある利用証明書リストの更新や取得を行う。
次に、図7を参照して、ブラウザ部200の起動時の処理手順について説明する。図7は、ブラウザ部200が起動した際の処理手順を示すフローチャートである。ブラウザ部200が起動すると、拡張機能のロード処理、より詳しくは拡張機能の識別子を取得する処理と、拡張機能が持つ関数を列挙する処理とが行われる。以下は、その詳細である。
ブラウザ部200が起動すると、ブラウザ部200は、まず、拡張機能アクセス制御プログラムをストレージ13から主記憶メモリ12にロードする(ステップS101)。これにより、拡張機能アクセス制御部100が実現される。続いて、ブラウザ部200の拡張機能呼出し依頼部220が、拡張機能アクセス制御部100の拡張機能ロード部111に対して、拡張機能初期化要求を送信する(ステップS102)。
拡張機能ロード部111は、拡張機能呼出し依頼部220からの初期化要求を受け取り、ストレージ13から拡張機能を1件取り出す処理を行う(ステップS103)。ここで、拡張機能ロード部111は、未処理の拡張機能がストレージ13内に存在するか否かを判定し(ステップS104)、未処理の拡張機能が存在した場合には(ステップS104:Yes)、その拡張機能の識別子を取得する(ステップS105)。さらに拡張機能ロード部111は、取得した識別子で示される拡張機能が持つ関数名と、その関数が格納されたアドレス(関数アドレス)との対応関係を取得する(ステップS106)。そして、拡張機能ロード部111は、ステップS105で取得した識別子と、ステップS106で取得した関数名およびその関数アドレスとを対応付けて、主記憶メモリ12に保存する(ステップS107)。
その後、拡張機能ロード部111は、拡張機能の初期化関数を呼出す(ステップS108)。この際、初期化関数については予め関数名が決まっているため、関数名と関数アドレスとの対応関係から関数アドレスを決定できる。
その後、拡張機能ロード部111は、ステップS103に戻って、ストレージ13内に未処理の拡張機能が存在しなくなるまで、ステップS103〜ステップS108の処理を繰り返す。その結果、拡張機能ロード部111により図4に示したような管理テーブルが構築される。そして、ストレージ13内のすべての拡張機能に対する処理が終了すると(ステップS104:No)、拡張機能ロード部111は、拡張機能呼出し依頼部220に対して、拡張機能の識別子のリストを返す(ステップS109)。これにより、起動処理が完了し、ブラウザ部200は、ストレージ13に存在する拡張機能の一覧を知ることができる。
次に、図8および図9を参照して、ページ遷移時の処理手順について説明する。図8は、ページ遷移時の概略的な処理手順を示すフローチャートであり、図9は、ページ遷移時の詳細な処理手順を示すフローチャートである。ページ遷移時にはウェブアプリケーションの開始、終了、実行継続の判定と、アプリ構成情報の更新処理が行われる。
まず、図8を用いて、ページ遷移時の処理の概略について説明する。ページ遷移が発生すると、まず、遷移先ページの位置識別子であるURLが取得され(ステップS201)、遷移先ページのページファイルがアプリ構成情報を含んでいるか否かが判定される(ステップS202)。そして、遷移先のページのページファイルにアプリ構成情報が含まれていれば(ステップS202:Yes)、新たなウェブアプリケーションの開始と判断され、それまで実行していたウェブアプリケーションに対応するアプリ構成情報が削除され(ステップS203)、新たに実行するウェブアプリケーションに対応するアプリ構成情報が保存される(ステップS204)。このアプリ構成情報には、上述したように、ウェブアプリケーションの範囲(ウェブアプリケーションに含まれるページファイル)を表すURLリストと、ウェブアプリケーションでどの拡張機能の利用が許可されているかを示す利用証明書リストとが含まれる。
一方、遷移先のページのページファイルにアプリ構成情報が含まれていなければ(ステップS202:No)、現在実行中のウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストが取得され(ステップS205)、遷移先ページのURLがURLリストに含まれているか否かが判定される(ステップ206)。そして、遷移先のページのURLがURLリストに含まれていれば(ステップS206:Yes)、ウェブアプリケーションの実行継続と判断され、そのまま処理を終了する。一方、遷移先のページのURLがURLリストに含まれていなければ(ステップS206:No)、ウェブアプリケーションの終了と判断され、それまで実行していたウェブアプリケーションに対応するアプリ構成情報が削除される(ステップS207)。
次に、図9を用いて、ページ遷移時の処理をより詳細に説明する。ページ遷移が発生すると、まずブラウザ部200のアプリケーション実行部210が、拡張機能アクセス制御部100のライフサイクル管理部130内にあるページ遷移検出部131に対して、ページ遷移が発生したことを遷移先ページのURLとともに通知する(ステップS301)。ページ遷移検出部131は、アプリケーション実行部210から遷移先ページのURLを取得すると(ステップS302)、遷移先ページのURLを渡してページ種別振分け部132を呼出す(ステップS303)。
ページ種別振分け部132は、新たなウェブアプリケーションの開始かどうかを判断するために、遷移先ページのページファイルを取得し、そのページファイルにアプリ構成情報が含まれているか否かを判定する(ステップS304)。この判定は、例えば、遷移先ページのページファイルの拡張子やMIMEタイプが、アプリ構成情報を含むページファイルに特有の拡張子やMIMEタイプであるか否か、あるいはページファイル内に図5−2に示した<appinfo>や</appinfo>といった特別なタグが含まれているか否かを判定基準として実施すればよい。
遷移先ページのページファイルにアプリ構成情報が含まれている場合(ステップS304:Yes)、ページ種別振分け部132は、新たなウェブアプリケーションが開始されたものと判断し、遷移先ページファイルに含まれるアプリ構成情報を渡してアプリ設定ロード部133を呼出す(ステップS305)。
アプリ設定ロード部133は、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135に対してURLリストの削除命令を出すとともに(ステップS306)、拡張機能利用証明書保存部136に対して利用証明書リストの削除命令を出す(ステップS307)。その後、アプリ設定ロード部133は、新たなウェブアプリケーションに対応するアプリ構成情報を保存するために、アプリ範囲管理部135に対して、アプリ構成情報に含まれるURLリストを通知して保存命令を出すとともに(ステップS308)、拡張機能利用証明書保存部136に対して、アプリ構成情報に含まれる利用証明書リストを通知して保存命令を出す(ステップS309)。アプリ範囲管理部135および拡張機能利用証明書保存部136は、アプリ設定ロード部133からの命令に従ってURLリストや利用証明書リストの削除、保存を行う。これにより、新たなウェブアプリケーションに対応したアプリ構成情報に含まれるURLリストおよび利用証明書リストが主記憶メモリ12に保存される。
一方、遷移先ページのページファイルにアプリ構成情報が含まれていない場合(ステップS304:No)、ページ種別振分け部132は、現在実行中のアプリケーションが継続実行、終了のいずれかであると判断し、そのどちらかであるかを判断するために、遷移先ページのURLを渡してアプリ終了判定部134を呼出す。
アプリ終了判定部134は、ページ種別振分け部132から遷移先ページのURLを取得すると、まず、アプリ範囲管理部135に対してURLリストの取得命令を出す。アプリ範囲管理部135は、アプリ終了判定部134からのURLリストの取得命令に応じて、主記憶メモリ12に保存されているURLリストを取得する処理を行って、取得したURLリストをアプリ終了判定部134に返す(ステップS310)。このとき、アプリ終了判定部134は、アプリ範囲管理部135が取得したURLリストの有無を判定し(ステップS311)、アプリ範囲管理部135が取得したURLリストがなければ(ステップS311:No)、そのまま処理を終了する。一方、アプリ範囲管理部135が取得したURLリストがあれば(ステップS311:Yes)、ページ種別振分け部132から取得した遷移先ページのURLがそのURLリストに含まれているか否かを判定する(ステップS312)。
そして、遷移先ページのURLがURLリストに含まれている場合(ステップS312:Yes)、アプリ終了判定部134は、同一のウェブアプリケーションの実行が継続されているものと判断し、そのまま処理を終了する。一方、遷移先ページのURLがURLリストに含まれていない場合(ステップS312:No)、アプリ終了判定部134は、それまで実行していたウェブアプリケーションが終了したものと判断し、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135に対してURLリストの削除命令を出すとともに(ステップS313)、拡張機能利用証明書保存部136に対して利用証明書リストの削除命令を出す(ステップS314)。アプリ範囲管理部135および拡張機能利用証明書保存部136は、アプリ設定ロード部133からの命令に従って、URLリストや利用証明書リストの削除を行う。
次に、図10を参照して、拡張機能呼出し時の処理手順について説明する。図10は、拡張機能呼出し時の処理手順を示すフローチャートである。拡張機能呼出し時には、主に拡張機能呼出し可否判定部122が現在実行中のウェブアプリケーションの利用証明書リストに基づいて、呼出す拡張機能の利用が現在実行中のウェブアプリケーションで許可されているかどうかを判定し、利用が許可されていれば、実際にその拡張機能を呼出す処理を行う。
拡張機能の呼出し要求が発生すると、まず、ブラウザ部200の拡張機能呼出し依頼部220が、呼び出し要求のあった拡張機能の識別子、関数名、関数に渡す引数などを渡して拡張機能アクセス制御部100のアクセス制御実行部120内の拡張機能アクセス検出部121を呼出し、拡張機能の呼出しを依頼する(ステップS401)。拡張機能アクセス検出部121は、それを受け取り、拡張機能呼出し可否判定部122に対して、呼出し要求のあった拡張機能の識別子、関数名、関数に渡す引数を渡して、拡張機能呼出し可否の判定と呼出しを依頼する(ステップS402)。
拡張機能呼出し可否判定部122は、呼出し要求のあった拡張機能の識別子を取得し(ステップS403)、実際にその拡張機能が存在するか確認するために、拡張機能ロード部111が主記憶メモリ12に保存した拡張機能の識別子のリストを主記憶メモリ12から読み出す(ステップS404)。次に、拡張機能呼出し可否判定部122は、そのリストの中に呼出し要求があった拡張機能の識別子があるかどうか判定する(ステップS405)。そして、呼出し要求のあった拡張機能の識別子がリストの中に存在しなければ(ステップS405:No)、拡張機能呼出し依頼部220に対してエラーを通知する(ステップS406)。
一方、呼出し要求のあった拡張機能の識別子がリストの中に存在する場合には(ステップS405:Yes)、拡張機能呼出し可否判定部122は、現在実行しているウェブアプリケーションでその拡張機能の利用が許可されているか否かを判断するために、まず拡張機能利用証明書保存部136に対して利用証明書リストの取得要求を出し、拡張機能利用証明書保存部136から利用証明書リストを取得する(ステップS407)。そして、拡張機能呼出し可否判定部122は、取得した利用証明書リストの中に呼出し要求のあった拡張機能の識別子に対応する利用証明書があるかどうかを判定し(ステップS408)、対応する利用証明書がない場合には(ステップS408:No)、現在実行されているウェブアプリケーションでは呼出し要求のあった拡張機能の利用が許可されていないものと判断して、拡張機能呼出し依頼部220にエラーを通知する(ステップS406)。
一方、利用証明書リストの中に対応する利用証明書があった場合には(ステップS408:Yes)、拡張機能呼出し可否判定部122は、呼出し要求のあった拡張機能の利用が許可されているものと判断し、拡張機能呼出し部112に対して、拡張機能の識別子、関数名、関数に渡す引数などを渡して、拡張機能の呼び出しを依頼する。拡張機能呼出し部112は、実際に拡張機能を呼出すために、拡張機能ロード部111が保存した図4のような管理テーブルを参照し、呼出す拡張機能の識別子に対応する関数名から呼出す関数のアドレスを取得する(ステップS409)。そして、拡張機能呼出し部112は、関数に渡す引数を引数として、取得したアドレスの関数(拡張機能)の呼出しを実行する(ステップS410)。そして、拡張機能呼出し部112は、拡張機能呼出し依頼部220に対して、関数の呼出し結果、すなわち拡張機能の呼出した関数の戻り値を返す(ステップS411)。
以上説明したように、本実施形態では、ウェブアプリケーションの範囲を表すURLリストを含むアプリ構成情報を、ウェブアプリケーションで最初に実行されるページファイルに格納している。そして、情報処理装置10がウェブアプリケーションを実行する際に、実行中のウェブアプリケーションに対応するアプリ構成情報を保存し、ウェブアプリケーションの実行中にページ遷移が発生した場合に、遷移先ページのページファイルがアプリ構成情報を含んでいるか、さらに、遷移先ページのページファイルがアプリ構成情報を含まない場合には、遷移先のページのURLがURLリストに含まれるか否かを判定することで、ウェブアプリケーションの開始、実行継続、実行終了を判定するようにしている。
したがって、本実施形態によれば、従来は困難であったウェブアプリケーション間の遷移を検出できるので、ウェブアプリケーション単位で拡張機能へのアクセス制御を行うことができる。これにより、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができるため、従来はセキュリティ上の理由から公開が困難であった一部の拡張機能について、アクセス許可を限定して公開することができるようになり、ウェブアプリケーションで作成できるアプリケーションの幅を広げることが可能となる。例えば、前述のローカルファイルアクセス拡張機能の一部としてファイル削除などの機能を提供したい場合には、すべてのウェブアプリケーション作成者に機能を公開してしまうとユーザ環境を破壊するようなウィルスも作成されてしまう危険性があるが、本実施形態により、拡張機能の利用者を限定することによりリスクを軽減することができる。
また、本実施形態により拡張機能の利用の幅が広がることで、従来はC/C++などの言語で開発していたプラットホーム特有のアプリケーションを、従来のウェブアプリケーションで記述できない機能のみをC/C++言語などにより拡張機能として開発し、残りのユーザインタフェースの部分などをウェブアプリケーションで開発できるといった利点もある。一般に、C/C++のようなネイティブアプリケーションでアプリケーションを開発するコストに比べて、ウェブアプリケーションの開発コストは低いため、ソフトウェア開発コストが削減できる。
このように、本実施形態では、ウェブアプリケーションを構成するページファイルの一覧(URLリスト)を用意し、その一覧を元にウェブアプリケーションを識別しその範囲でセキュリティを適用する。
従来のOMTP(Open Mobile Terminal Platform)BONDI規格(非特許文献1)などのウィジェット規格の中には、ウェブアプリケーションの技術を用いてアプリケーションを構成するものもある。しかし、従来のウィジェット規格の多くは、予めアプリケーションの開発者が複数のページファイルやメディアファイルを圧縮技術により一つのファイル(ウィジェットアーカイブファイル)にまとめておき、それを一つのアプリケーションとみなし、セキュリティ適用を行うものが多い。しかし、ウィジェットアーカイブファイルにまとめてしまうと、ページファイルの一部を修正した場合でも、ウィジェットアーカイブファイルを再度アップデートする必要があるため効率が悪い。また、ウェブアプリケーションにおいては、サーバ装置側で動的にページファイルやメディアファイルを生成するような場合もあり、それらにウィジェットアーカイブファイルによる方式を適用するのは困難である。
これに対して、本実施形態では、ページの一部を更新する場合には修正したいページファイルのみを修正するだけでよく、アプリケーションアップデートの手間が小さいという利点がある。
また、従来の一部の技術(特許文献1、非特許文献1)では、ページファイル単位でセキュリティポリシを記述することも可能である。しかし、特許文献1、非特許文献1では、ページ単位でセキュリティポリシを記述するため、アプリケーションが多くのページファイルから構成される場合、セキュリティポリシが膨大になる。また、アプリケーション全体でセキュリティポリシをアップデートする場合には、個々のページファイルのセキュリティポリシをアップデートする必要があり、セキュリティポリシ管理の手間が大きい。
これに対して、本実施形態では、ウェブアプリケーション単位でセキュリティポリシを記述すればよいため、ウェブアプリケーション全体のセキュリティポリシをアップデートする場合にもコストが小さく、また、セキュリティポリシも膨大になりにくいという利点がある。
また、従来、複数のページ単位で同一のセキュリティポリシを適用する規格としては、HTML5規格のSame−origin policy(非特許文献2)が存在する。これは、同一ドメインのページファイルではオブジェクトへの相互アクセスを許可するものであり、ドメイン間でのアクセス許可やセキュリティポリシの使い分けはできない。ウェブアプリケーションにおいては、マッシュアップと呼ばれる複数のサービスを連携させて新しいアプリケーションを作る技術が一般的なものとなっているが、Same−origin policyは、マッシュアップ時のアプリケーション作成の枷となっている。
これに対して、本実施形態では、ウェブアプリケーションを構成するページファイルを記述する際に、個々のページファイルのドメインが一致している必要はない。すなわち、ドメインを跨いでの同一セキュリティポリシの適用が可能となるため、機器機能を利用するマッシュアップも可能になるという利点がある。
(第2の実施形態)
次に、第2の実施形態について説明する。図11は、第2の実施形態の情報処理装置10−2を含む情報処理システムのハードウェア構成図である。図1に示した第1の実施形態の構成と比較すると、サーバ装置20−2のストレージ21−2に、コンフィギュレーションファイルと呼ばれるファイルが格納されている点が異なっている。以下、第1の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第2の実施形態の特徴部分についてのみ説明する。
次に、第2の実施形態について説明する。図11は、第2の実施形態の情報処理装置10−2を含む情報処理システムのハードウェア構成図である。図1に示した第1の実施形態の構成と比較すると、サーバ装置20−2のストレージ21−2に、コンフィギュレーションファイルと呼ばれるファイルが格納されている点が異なっている。以下、第1の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第2の実施形態の特徴部分についてのみ説明する。
第1の実施形態では、ページファイルの内部に、ページ表示情報や配置情報に加えて、アプリ構成情報が含まれていた。これに対して、第2の実施形態では、ページファイルとは別のファイルとして、アプリ構成情報のみが含まれるファイルを用意する。このアプリ構成情報のみが含まれるファイルをコンフィギュレーションファイルと呼ぶ。
図12は、コンフィギュレーションファイルのデータ構造の一例を示す図である。コンフィギュレーションファイル中には、ウェブアプリケーションの範囲と利用可能な拡張機能を示すアプリ構成情報が含まれている。「アプリ構成情報開始識別子」と「アプリ構成情報終了識別子」とに挟まれた部分の情報が、アプリ構成情報である。アプリ構成情報内の「位置識別子情報開始識別子」と「位置識別子情報終了識別子」とに挟まれた部分の情報がURLリストであり、アプリ構成情報内の「拡張機能利用証明書開始識別子」と「拡張機能利用証明書終了識別子」とに挟まれた部分の情報が、利用証明書リストである。また、コンフィギュレーションファイル中のアプリ構成情報には、当該コンフィギュレーションファイルのロード後に遷移する先のページファイル(ウェブアプリケーションで最初に実行されるページファイル)の位置識別子(スタートアップURL)が記述されている。
図13は、第2の実施形態の情報処理装置10−2内部の機能的な構成を示す機能ブロック図である。図6に示した第1の実施形態の構成と比較すると、拡張機能アクセス制御部100−2のライフサイクル管理部130−2内のアプリ設定ロード部133−2の機能が、第1の実施形態のアプリ設定ロード部133と異なっている。すなわち、第2の実施形態のアプリ設定ロード部133−2は、第1の実施形態におけるアプリ設定ロード部133の機能に加えて、さらに、コンフィギュレーションファイルへのアクセス時に自動的に遷移するページファイルの情報(スタートアップURL)を得る機能と、遷移命令を出す機能とを有する。
図14は、第2の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、利用証明書リストを保存する処理(ステップS509)の後に、コンフィギュレーションファイルからウェブアプリケーションで最初に実行されるページファイルへと自動的に遷移する処理(ステップS510、ステップS511)が加わっている点が異なる。図14のステップS501からステップS509までの処理は、図9に示したステップS301からステップS309までの処理と同じである。ただし、ステップS504でYesと判定されるのは、遷移先ページがコンフィギュレーションファイルの場合となる。
第2の実施形態では、ステップS509で利用証明書リストを保存した後、アプリ設定ロード部133−2が、コンフィギュレーションファイルから実行するページファイルの位置識別子(スタートアップURL)を取得し(ステップS510)、アプリケーション実行部210に対してスタートアップURLと遷移命令を通知して、スタートアップURLに遷移する(ステップS511)。その後の処理、すなわち、図14のステップS512からステップS516までの処理は、図9に示したステップS310からステップS314までの処理と同じである。
第2の実施形態では、ウェブアプリケーションの範囲と利用可能な拡張機能を示すアプリ構成情報が、ページファイルとは分離された独立のコンフィギュレーションファイルとして提供されるため、ページファイルには手を加える必要がなくなる。すなわち、ページファイルは従来のページファイルを全く変更しなくてもよいため、ウェブアプリケーションの既存資産を最大限活用することができる。また、第2の実施形態では、新たにコンフィギュレーションファイルを生成するだけでよいため、アプリケーション開発コストも従来のアプリケーション開発コストと大きく変わらないという利点がある。
(第3の実施形態)
次に、第3の実施形態について説明する。第1の実施形態では、拡張機能利用証明書保存部136が拡張機能ごとの利用証明書のリストである利用証明書リストを管理し、拡張機能呼出し可否判定部122が、拡張機能ごとに呼出し可否を判定するようにしていた。これに対して第3の実施形態では、拡張機能に付随するセキュリティポリシを管理し、1つの拡張機能に含まれる複数の機能のうちで利用を許可する機能を限定できるようにしている。
次に、第3の実施形態について説明する。第1の実施形態では、拡張機能利用証明書保存部136が拡張機能ごとの利用証明書のリストである利用証明書リストを管理し、拡張機能呼出し可否判定部122が、拡張機能ごとに呼出し可否を判定するようにしていた。これに対して第3の実施形態では、拡張機能に付随するセキュリティポリシを管理し、1つの拡張機能に含まれる複数の機能のうちで利用を許可する機能を限定できるようにしている。
図15は、第3の実施形態の情報処理装置10−3内部の機能的な構成を示す機能ブロック図である。図6に示した第1の実施形態の構成と比較すると、拡張機能アクセス制御部100−3の拡張機能管理部110−3内にセキュリティポリシ管理部113が付加されている点が異なっている。以下、第1の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第3の実施形態の特徴部分についてのみ説明する。
図16は、セキュリティポリシ管理部113の内部構成を示すブロック図である。セキュリティポリシ管理部113は、図16に示すように、セキュリティポリシロード部113aと、セキュリティポリシ取得部113bと、を備える。
セキュリティポリシロード部113aは、拡張機能の識別子を受信して、対応する拡張機能のセキュリティポリシを主記憶メモリ12にロードする。
図17−1は、第3の実施形態においてセキュリティポリシロード部113aによりロードされるセキュリティポリシのデータ構造の一例を示す図である。図17−1のデータ構造を持った拡張機能のセキュリティポリシが格納されたファイル(セキュリティポリシファイル)は、拡張機能ごとに用意される。セキュリティポリシファイルは、例えば、拡張機能の識別子と同名のファイル名など、識別子からファイル名が決定できるように命名されていてもよい。また、セキュリティポリシファイルは、特定の拡張子が決められており、セキュリティポリシのデータ構造の中に対応する識別子が記述されるようにしてもよい。セキュリティポリシファイルは、ストレージ13内に配置されている。セキュリティポリシは、1個以上のセキュリティポリシエレメント部から構成される。セキュリティポリシエレメント部には、セキュリティポリシエレメント識別子とそのセキュリティポリシエレメントを適用した場合に呼出しを許可する関数の関数名が列挙されている。関数名は、ワイルドカードや正規表現などを使って条件を指定してもよい。
図17−2は、図17−1のデータ構造に従って記述されたセキュリティポリシファイルの一例を示す図である。例えば、dlna−player−policy1という識別子を持ったセキュリティポリシエレメントを適用する場合には、hoge、foo、barといった名前の関数呼出しが許可される。
セキュリティポリシ取得部113bは、拡張機能の識別子とセキュリティポリシエレメント識別子を受信して、対応するセキュリティポリシエレメントの内容を返す。
図18−1は、第3の実施形態におけるアプリ構成情報のデータ構造の一例を示す図であり、図18−2は、図18−1のデータ構造に従って記述されたアプリ構成情報の一例を示す図である。この図18に例示するアプリ構成情報は、図5に示した第1の実施形態におけるアプリ構成情報と比較して、URLリストの各利用証明書の中に適用するセキュリティポリシの識別子が含まれている点が異なっている。すなわち、図5の例では、利用証明書リストに、利用が許可された拡張機能の識別子(MIMEタイプなど)のみが記述されていたが、図18の例では、利用が許可された拡張機能の識別子に加えて、適用するセキュリティポリシエレメント識別子も記述されている。このセキュリティポリシエレメント識別子は、図17に示したセキュリティポリシファイルのセキュリティポリシエレメント識別子と対応する。
図19は、図17−2に示したセキュリティポリシファイルと図18−2に示したアプリ構成情報との対応関係を示す図である。図18−2に示したアプリ構成情報を持つウェブアプリケーションでは、識別子がvideo/dlna−playerという拡張機能を利用する場合、dlna−player−policy2というセキュリティポリシエレメントが適用され、そのセキュリティポリシの内容は、図17−2から、hoge、bar2などの関数の呼出しを許可するものであることがわかる。
第3の実施形態では、アクセス制御実行部120−3の拡張機能呼出し可否判定部122−3が、セキュリティポリシ管理部113と拡張機能利用証明書保存部136との双方と連携し、ウェブアプリケーション単位でセキュリティポリシの適用を行うようにしている。これにより、同じ拡張機能であっても、ウェブアプリケーションによって適用するセキュリティポリシを切り替えることが可能となる。
図20は、第3の実施形態においてブラウザ部200が起動した際の処理手順を示すフローチャートである。図7に示した第1の実施形態の処理手順と比較すると、ストレージ13内の拡張機能の識別子を取得(ステップS605)した後に、セキュリティポリシロード部113aがセキュリティポリシをロードする処理(ステップS606〜ステップS609)が加わっている点が異なる。図20のステップS601からステップS605までの処理は、図7に示したステップS101からステップS105までの処理と同じである。第3の実施形態では、拡張機能ロード部111がステップS605で拡張機能の識別子を取得した後、その識別子をセキュリティポリシロード部113aに渡し、対応するセキュリティポリシのロードを依頼する。
セキュリティポリシロード部113aは、受け取った拡張機能の識別子などから対応するセキュリティポリシのファイル名に変換を行い、セキュリティポリシファイルを取り出す処理を行う(ステップS606)。例えば、セキュリティポリシのファイル名の命名規則を、識別子.cfgというように決めておけば、単純に、識別子がvideo/dlna−playerの拡張機能については、video/dlna−player.cfgのように変換することができる。
次に、セキュリティポリシロード部113aは、ステップS605で取得した識別子に対応するセキュリティポリシファイルをステップS606で取り出せたかどうか(対応するセキュリティポリシファイルが存在したかどうか)を判定する(ステップS607)。そして、セキュリティポリシファイルが存在しなかった場合には(ステップS607:No)、セキュリティポリシロード部113aは、予め定めたデフォルトのセキュリティポリシを取り出す(ステップS608)。このデフォルトのセキュリティポリシは、例えば、全関数の呼び出し拒否、呼出し許可などといった単純なポリシとしておく。
一方、セキュリティポリシファイルが存在した場合は(ステップS607:Yes)、ステップS608の処理は行わずに、ステップS609に進む。その後、セキュリティポリシロード部113aは、ステップS606またはステップS608で取り出したセキュリティポリシを、拡張機能の識別子と対応付けて主記憶メモリ12に保存し(ステップS609)、拡張機能ロード部111に処理を返す。その後の処理、すなわち、図20のステップS610からステップS613までの処理は、図7に示したステップS106からステップS109までの処理と同じである。
図21は、第3の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図10に示した第1の実施形態の処理手順と比較すると、呼出し要求のあった拡張機能に対応する利用証明書があると判定された後に(ステップS708:Yes)、呼出し要求のあった拡張機能に対応するセキュリティポリシエレメントを取得して、拡張機能の利用証明書とセキュリティポリシとの双方から拡張機能の利用可否を判定する処理(ステップS709〜ステップS711)が加わっている点が異なる。図21のステップS701からステップS708までの処理は、図10に示したステップS401からステップS408までの処理と同じである。
第3の実施形態では、拡張機能呼出し可否判定部122−3が、適用するセキュリティポリシエレメントの内容を得るために、呼出し要求のあった拡張機能に対応する利用証明書があると判定した場合に(ステップS708:Yes)、アプリ構成情報に記述されている適用するセキュリティポリシエレメントの識別子を取得する(ステップS709)。その後、拡張機能呼出し可否判定部122−3は、取得したセキュリティポリシエレメント識別子と拡張機能の識別子とをセキュリティポリシ取得部113bに渡し、対応するセキュリティポリシエレメントの取得を依頼する。セキュリティポリシ取得部113bは、セキュリティポリシロード部113aが主記憶メモリ12に保存したセキュリティポリシから、該当するセキュリティポリシエレメントを返す(ステップS710)。
拡張機能呼出し可否判定部122−3は、呼び出す関数名が、取得したセキュリティポリシエレメントにあるかどうか、もしくはセキュリティポリシエレメントの関数名が条件で指定されている場合には、その条件に合致するかどうかにより、関数の呼出しが許可されているか否かを判定する(ステップS711)。そして、関数の呼出しが許可されていないと判定した場合は(ステップS711:No)、ステップS706において拡張機能呼出し依頼部220にエラーを通知する。一方、関数の呼出しが許可されていると判定した場合は(ステップS711:Yes)、拡張機能呼出し部112に対して、拡張機能の識別子、関数名、関数に渡す引数などを渡して、拡張機能の呼び出しを依頼する。その後の処理、すなわち、図21のステップS712からステップS714までの処理は、図10に示したステップS409からステップS411までの処理と同じである。
以上説明したように、第3の実施形態によれば、アプリ構成情報の利用証明書リストにセキュリティポリシの情報を付加して提供するようにしているので、ウェブアプリケーションに対して利用を許可する拡張機能の内容を、拡張機能に含まれる個々の機能単位で限定することができる。また、アプリ構成情報の利用証明書リストにセキュリティポリシの識別子を記述するとともに、拡張機能のセキュリティポリシを識別子で管理するようにしているので、拡張機能の開発者が利用を許可する拡張機能のポリシを変えたい場合には、ウェブアプリケーション側の利用証明書を更新する必要なく、ポリシを更新するだけで利用を許可する拡張機能のポリシを変更することができる。すなわち、第3の実施形態により、ウェブアプリケーションのリボーク機能を実現することが可能である。
なお、第3の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。
(第4の実施形態)
次に、第4の実施形態について説明する。上述した第1乃至第3の実施形態では、拡張機能の利用証明書に対する安全性検証を行っていなかった。このため、悪意あるアプリケーション開発者が開発したウェブアプリケーションのページファイルやコンフィギュレーションファイルに拡張機能の不正な利用証明書を添付して、不正に拡張機能を利用される虞があった。第4の実施形態では、拡張機能の作成者など信頼できる者がウェブアプリケーションごとに署名の付いた正当な拡張機能の利用証明書を発行し、アプリケーション開発者は、アプリ構成情報にその正当な拡張機能の利用証明書を含めるようにする。さらに、第4の実施形態では、情報処理装置10−4が拡張機能の利用証明書についての完全性検証を行うことにより、拡張機能の作成者の意図しない拡張機能の不正利用を防止するようにしている。
次に、第4の実施形態について説明する。上述した第1乃至第3の実施形態では、拡張機能の利用証明書に対する安全性検証を行っていなかった。このため、悪意あるアプリケーション開発者が開発したウェブアプリケーションのページファイルやコンフィギュレーションファイルに拡張機能の不正な利用証明書を添付して、不正に拡張機能を利用される虞があった。第4の実施形態では、拡張機能の作成者など信頼できる者がウェブアプリケーションごとに署名の付いた正当な拡張機能の利用証明書を発行し、アプリケーション開発者は、アプリ構成情報にその正当な拡張機能の利用証明書を含めるようにする。さらに、第4の実施形態では、情報処理装置10−4が拡張機能の利用証明書についての完全性検証を行うことにより、拡張機能の作成者の意図しない拡張機能の不正利用を防止するようにしている。
図22は、第4の実施形態の情報処理装置10−4内部の機能的な構成を示す機能ブロック図である。図15に示した第3の実施形態の構成と比較すると、拡張機能アクセス制御部100−4にデータ検証部150が付加されている点が異なっている。以下、第1乃至第3の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第4の実施形態の特徴部分についてのみ説明する。
データ検証部150は、署名検証部151を備える。図23は、署名検証部151の内部構成を示すブロック図である。署名検証部151は、図23に示すように、データ正規化部151aと、アプリケーション固有データ生成部151bと、ハッシュ計算部151cと、鍵保存部151dと、証明書有効性検証部151eと、証明書解析部151fと、復号処理部151gと、を備える。
図24は、第4の実施形態においてセキュリティポリシロード部113aによりロードされるセキュリティポリシのデータ構造の一例を示す図である。図17−1に示した第3の実施形態におけるセキュリティポリシのデータ構造と比較して、証明書検証用公開鍵が含まれる点が異なっている。第4の実施形態では、この証明書検証用公開鍵を用いて利用証明書の検証を行う。この証明書検証用公開鍵は、拡張機能ごともしくは拡張機能の制作者ごとに生成される。また、証明書検証用公開鍵に対応する秘密鍵は、拡張機能の制作者のみが持ち、アプリ構成情報に含まれる拡張機能の利用証明書に付加する利用証明書検証用データを作成する際に利用される。
図25は、第4の実施形態におけるアプリ構成情報のデータ構造の一例を示す図である。図18−1に示した第3の実施形態におけるアプリ構成情報のデータ構造と比較して、利用証明書検証データが含まれている点が異なっている。この利用証明書検証データは、拡張機能の利用証明書1件につき、1つずつ含まれている。
署名検証部151は、アプリ構成情報に含まれる利用証明書を検証する。具体的には、署名検証部151は、データ正規化部151aにより、拡張機能の利用証明書の正規化処理を行う。そして、正規化処理後のデータとアプリケーション固有データ生成部151bが生成したデータを合成した後、ハッシュ計算部151cにより、そのデータのハッシュ値を計算する。さらに、復号処理部151gにより、拡張機能の利用証明書に添付されたハッシュ値を鍵保存部151dが保存した拡張機能の証明書検証用公開鍵で復号し、ハッシュ計算部151cが計算したハッシュ値と比較することで改ざん検証を行う。さらに、証明書有効性検証部151eによる利用証明書の有効期間の検証や、リボークリストに基づく有効性の検証などを、必要に応じて行うようにしてもよい。
第4の実施形態では、拡張機能の利用証明書に、拡張機能の秘密鍵で暗号化されたハッシュ値(利用証明書検証データ)と、対象拡張機能の識別子と、セキュリティポリシの管理を行う場合にはセキュリティポリシエレメントの識別子と、が少なくとも含まれる。署名検証部151は、証明書解析部151fが、アプリケーション固有データ生成部151bと連携して、拡張機能の利用証明書の改ざん検証を行うようにしている。以下、第4の実施形態において特徴的な署名検証部151の処理についてさらに詳しく説明する。
証明書解析部151fは、アプリ構成情報を受け取り、拡張機能の利用証明書を解析する。アプリ構成情報に複数の利用証明書が含まれる場合には利用証明書を分離して、データ正規化部151a、アプリケーション固有データ生成部151b、ハッシュ計算部151c、鍵保存部151d、証明書有効性検証部151e、および復号処理部151gと連携して、利用証明書が改ざんされていないか、現在実行中のウェブアプリケーション向けに発行された利用証明書であるかどうか判断する。さらに、これらの結果から利用証明書が有効と判断された場合には、その利用証明書を主記憶メモリ12に保存する。
データ正規化部151aは、利用証明書データを受け取り、この利用証明書データの正規化処理を行う。なお、拡張機能の利用証明書やセキュリティポリシファイルは、例えばXMLなどのデータ記述言語を用いて記述することができる。XMLなどのデータ記述言語では、データの順序などが異なった場合でも同じ意味をなす場合があり、処理によってはデータを正規化する必要があるために、データ正規化部151aを利用する。拡張機能の利用証明書の正規化が必要ない場合には、データ正規化部151aは不要となる。
アプリケーション固有データ生成部151bは、ウェブアプリケーションに固有なデータを生成する。このアプリケーション固有データとしては、例えば、アプリ構成情報に含まれるURLリストのハッシュ値や、署名が付いたウェブアプリケーションのIDなどを用いることができる。また、第2の実施形態のようにアプリ構成情報をコンフィギュレーションファイルとして独立のファイルで提供する場合には、コンフィギュレーションファイルのURL自体をアプリケーション固有データとして用いるようにしてもよい。ただし、アプリケーション固有データは、偽装や他者がコピー不可能な情報である必要がある。
ハッシュ計算部151cは、データ正規化部151aにより正規化処理が行われたデータとアプリケーション固有データ生成部151bが生成したデータとを合成したデータのハッシュ値を計算する。ハッシュ値の計算アルゴリズムとしては、SHA1やMD5などの一般的に知られたアルゴリズムを用いればよい。また、ハッシュ値の格納形式などは、X.509、XML Signatureなどの既存の方式を用いればよい。
復号処理部151gは、利用証明書に格納されたデータから暗号化されたハッシュ値を抜き出し、鍵保存部151dから取得した鍵データ(証明書検証用公開鍵)でハッシュ値を復号する。暗号・復号アルゴリズムとしては、RSAなど、よく知られた公開鍵暗号の仕組みを使えばよい。
鍵保存部151dは、各拡張機能に対応する証明書検証用公開鍵を命令に応じて保存または取得する。
証明書有効性検証部151eは、利用証明書が有効かどうか判定する。判定の方法としては、例えば、利用証明書に有効期限のデータが格納されている場合には、現在の日時との比較を行い有効期限の範囲内かどうかを判定するといった方法が考えられる。また、利用証明書のリボークリストを別途用意して利用証明書が有効であるかどうかを判定するといった方法も考えられる。なお、条件に合致しない利用証明書を失効させる必要がない場合には、この証明書有効性検証部151eは不要である。
図26は、第4の実施形態においてブラウザ部200が起動した際の処理手順を示すフローチャートである。図20に示した第3の実施形態の処理手順と比較すると、セキュリティポリシロード部113aがステップS805で取得した識別子に対応するセキュリティポリシファイルが存在する場合に(ステップS807:Yes)、署名検証部151の鍵保存部151dが、ステップS805で取得した識別子で示される拡張機能に対応する証明書検証用公開鍵を保存する処理(ステップS809)が加わっている点が異なる。図26のステップS801からステップS807までの処理は、図20に示したステップS601からステップS608までの処理と同じである。
第4の実施形態では、セキュリティポリシロード部113aが、ステップS805で取得した識別子に対応するセキュリティポリシファイルが存在すると判定した場合に(ステップS807:Yes)、拡張機能ごとの証明書検証用公開鍵を保存するために、鍵保存部151dを呼出して拡張機能の識別子とセキュリティポリシデータを渡す。そして、鍵保存部151dは、セキュリティポリシに含まれる鍵データ(証明書検証用公開鍵)を、拡張機能の識別子と対応付けて主記憶メモリ12に保存する(ステップS809)。これにより、拡張機能ごとの鍵データが主記憶メモリ12に保存され、拡張機能の識別子から対応する鍵データを取得できるようになる。その後の処理、すなわち、図26のステップS810からステップS814までの処理は、図20に示したステップS609からステップS613までの処理と同じである。
図27は、第4の実施形態におけるページ遷移時の処理手順のうち、拡張機能の利用証明書リストを保存する処理(図9のステップS309に相当)を抜き出したものである。第4の実施形態におけるページ遷移時の処理のうち、拡張機能の利用証明書リストを保存する処理以外の処理は、図9に示した第1の実施形態の処理手順と同様である。
利用証明書リストの保存処理が開始されると、まず、署名検証部151の証明書解析部151fが、アプリケーション固有データ生成部151bに対してアプリケーション固有データの生成を依頼する。アプリケーション固有データ生成部151bは、アプリケーション固有データを取り出して、証明書解析部151fに返す(ステップS901)。このアプリケーション固有データとしては、例えば、アプリ構成情報に含まれるURLリストのハッシュ値や、偽装や他者がコピー不可能な署名が付いたウェブアプリケーションのアプリケーションIDなどを用いることができる。また、アプリ構成情報をページファイルとは別のコンフィギュレーションファイルとして提供する場合には、そのコンフィギュレーションファイルのURLなどをアプリケーション固有データとして用いることができる。このアプリケーション固有データは、拡張機能の利用証明書がどのウェブアプリケーションに対して発行されたか、不正に別アプリケーションの拡張機能の利用証明書を利用していないか確認するためのデータである。
次に、証明書解析部151fは、各拡張機能の利用証明書を検証するために、アプリ構成情報に含まれる利用証明書リストから利用証明書を1件取り出す処理を行い、利用証明書が取り出せたか否かを判定する(ステップS902)。ここで、利用証明書を取り出せなかった場合には(ステップS902:No)、そのまま処理を終了する。一方、利用証明書を取り出せた場合には(ステップS902:Yes)、利用証明書のデータからその証明書に対応する拡張機能の識別子を取得する(ステップS903)。さらに証明書解析部151fは、利用証明書の予め定められた部分(改ざんされては困る部分であり、図25に示したアプリ構成情報の例では、対応拡張機能識別子や対応セキュリティポリシエレメント識別子のデータ)を取り出し、正規化部151aに渡してデータの正規化を依頼する。正規化部151aは、証明書解析部151fから渡されたデータに対して正規化処理を行い、その結果を証明書解析部151fに返す(ステップS904)。この際の計算には、暗号化されたハッシュ値データ(図25に示した検証データ)は含まれない。
さらに証明書解析部151fは、ステップS901で取り出したアプリケーション固有データとステップS904で正規化されたデータとの結合を行う(ステップS905)。この結合は、データが文字列データの場合は、単純に、ステップS901で取り出したアプリケーション固有データの後に、ステップS904で正規化されたデータを結合すればよい。この結合によって得られるデータが、改ざん検出用の元データとなる。
さらに証明書解析部151fは、検証データを生成するためにステップS905で結合したデータをハッシュ計算部151cに渡してハッシュの計算を依頼する。ハッシュ計算部151cは、何らかのハッシュ計算アルゴリズムを用いて、与えられたハッシュ値を計算して証明書解析部151fに返す(ステップS906)。
さらに証明書解析部151fは、利用証明書に添付された暗号化されたハッシュ値(図25に示した利用証明書検証データ)を復号するために、鍵保存部151dに拡張機能の識別子を渡し、鍵保存部151dが起動時に保存した拡張機能に対応する鍵データ(証明書検証用公開鍵)を取得する(ステップS907)。そして、証明書解析部151fは、ステップS907で取得した鍵データと、利用証明書に添付された暗号化されたハッシュ値(図25に示した検証データ)とを復号処理部151gに渡し、復号を依頼する。なお、利用証明書に添付された暗号化されたハッシュ値(図25に示した検証データ)は、拡張機能の作成者が利用証明書の作成時に上記の証明書検証用公開鍵に対応する暗号鍵で暗号化したハッシュ値である。復号処理部151gは、この暗号化されたハッシュ値を、証明書検証用公開鍵を用いて復号し、結果を証明書解析部151fに返す(ステップS908)。
証明書解析部151fは、ステップS906で計算されたハッシュ値と、ステップS908で復号されたハッシュ値とを比較し、両者が一致するかどうかを判定する(ステップS909)。そして、両者が一致しない場合(ステップS909:No)、証明書解析部151fは、利用証明書が改ざんされた、あるいは不正に別のウェブアプリケーション向けの拡張機能の利用証明書を利用していると判断して、エラーの発生を通知する(ステップS910)。一方、両者が一致した場合には(ステップS909:Yes)、証明書解析部151fは、その拡張機能の利用証明書が正しいと判断する。
すなわち、アプリケーション固有データや、証明書データのうちの一部のデータとして何を用いるか、ハッシュ計算のアルゴリズム、暗号化のアルゴリズムとして何を使うかを予め決めておき、拡張機能の作成者は、アプリケーションの作成者に対して拡張機能の利用証明書を発行する際に、これらの決まりに従って、暗号化されたハッシュ値(図25の検証データ)のデータを生成する(アプリケーション固有データと証明書データの一部のデータを結合し、結合したデータのハッシュ値を計算し、そのハッシュ値を拡張機能の作成者が持つ暗号鍵で暗号化する)ことで、上記の処理により、拡張機能の利用証明書の不正利用を判定することができる。
さらに、証明書有効性検証部151eを設けた場合には、証明書有効性検証部151eに利用証明書データを渡し、利用証明書が有効かどうかの判定を依頼する。証明書有効性検証部151eは、例えば、利用証明書に有効期限のデータが格納されている場合には、現在の日時との比較を行い有効期限の範囲内かどうかを判定するといった方法や、利用証明書のリボークリストを用意する場合には、そのリストのデータから利用証明書が有効であるか判定することといった方法で、利用証明書データの有効性を検証し、結果を証明書解析部151fに返す(ステップS911)。証明書解析部151fは、検証結果を受け取り、利用証明書が有効でない場合には(ステップS911:No)、ステップS910においてエラーの発生を通知する。一方、利用証明書が有効な場合には(ステップS911:Yes)、主記憶メモリ12に利用証明書を保存して(ステップS912)、ステップS902に戻る。その後、拡張機能の利用証明書がなくなるまでステップ902以降の処理を繰り返す。その結果、正当な拡張機能の利用証明書のみが主記憶メモリ12に保存されることになる。
以上説明したように、第4の実施形態によれば、拡張機能の利用証明書に対する完全性検証を行うようにしているため、拡張機能の不正利用を有効に防止することができる。
なお、第4の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。
(第5の実施形態)
次に、第5の実施形態について説明する。ウェブアプリケーションにおいては、複数のアプリケーションをタブもしくはウィンドウと呼ばれる実行単位に分けて並列実行することができる。この1つの実行単位のことをコンテキストと呼ぶ。第1乃至第4の実施形態においては、複数のコンテキストを同時に実行する場合、ブラウザ部200や拡張機能アクセス制御部100をコンテキストの数だけ用意する必要がある。これは、いわば複数のブラウザを立ち上げた状態になり、主記憶メモリ12などのリソースの使用効率の悪化を招く。これに対して、第5の実施形態では、実行中のコンテキストを識別する機能を拡張機能アクセス制御部100−5に付加することで、複数のコンテキストを並列実行する場合にも、リソースの重複を最低限にして効率のよい処理を行えるようにしている。
次に、第5の実施形態について説明する。ウェブアプリケーションにおいては、複数のアプリケーションをタブもしくはウィンドウと呼ばれる実行単位に分けて並列実行することができる。この1つの実行単位のことをコンテキストと呼ぶ。第1乃至第4の実施形態においては、複数のコンテキストを同時に実行する場合、ブラウザ部200や拡張機能アクセス制御部100をコンテキストの数だけ用意する必要がある。これは、いわば複数のブラウザを立ち上げた状態になり、主記憶メモリ12などのリソースの使用効率の悪化を招く。これに対して、第5の実施形態では、実行中のコンテキストを識別する機能を拡張機能アクセス制御部100−5に付加することで、複数のコンテキストを並列実行する場合にも、リソースの重複を最低限にして効率のよい処理を行えるようにしている。
図28は、第5の実施形態の情報処理装置10−5内部の機能的な構成を示す機能ブロック図である。図22に示した第4の実施形態の構成と比較すると、拡張機能アクセス制御部100−5のライフサイクル管理部130−5内にコンテキスト判定部137が付加されている点が異なっている。以下、第1乃至第4の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第5の実施形態の特徴部分についてのみ説明する。
コンテキスト判定部137は、ページ遷移時や拡張機能の呼出しなどの各イベント発生時に、そのイベントがどのコンテキストで発生したかを判定する。コンテキスト判定部137は、コンテキスト識別子取得命令を受け取り、コンテキストごとに一意の番号や文字列で表現されるコンテキスト識別子を返す。
第5の実施形態におけるアプリ範囲管理部135−5は、アプリ構成情報に含まれるURLリストの保存命令、取得命令、消去命令を受け取り、命令に応じた処理をコンテキストごとに行う。すなわち、アプリ範囲管理部135−5は、URLリストの保存命令を受け取った場合には、コンテキスト判定部137からコンテキスト識別子を取得し、呼出し元から渡されたURLリストを、コンテキスト識別子に対応付けて主記憶メモリ12に保存する。また、アプリ範囲管理部135−5は、URLリストの取得命令を受け取った場合には、主記憶メモリ12に保存してあるURLリストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応するURLリストを返す。また、アプリ範囲管理部135−5は、URLリストの消去命令を受け取った場合には、主記憶メモリ12に保存してあるURLリストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応するURLリストを消去する処理を行う。
第5の実施形態における拡張機能利用証明書保存部136−5は、利用証明書リストの保存命令、取得命令、消去命令を受け取り、命令に応じた処理をコンテキストごとに行う。すなわち、拡張機能利用証明書保存部136−5は、利用証明書リストの保存命令を受け取った場合には、コンテキスト判定部137からコンテキスト識別子を取得し、呼出し元から渡された利用証明書リストを、コンテキスト識別子に対応付けて主記憶メモリ12に保存する。また、拡張機能利用証明書保存部136−5は、利用証明書リストの取得命令を受け取った場合には、主記憶メモリ12に保存してある利用証明書リストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応する利用証明書リストを返す。また、拡張機能利用証明書保存部136−5は、利用証明書リストの消去命令を受け取った場合には、主記憶メモリ12に保存してある利用証明書リストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応する利用証明書リストを消去する処理を行う。
以上のように、第5の実施形態の情報処理装置10−5はコンテキスト判定部137を備え、アプリ範囲管理部135−5と拡張機能利用証明書保存部136−5が、コンテキスト判定部137と連携してコンテキストごとにアプリ構成情報のURLリストや利用証明書リストを管理するようにしている。
図29は、第5の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、ステップS1006、ステップS1008、ステップS1010、ステップS1012、ステップS1014、ステップS1018、およびステップS1020でコンテキストを取得する処理が加わっている点が異なっている。図29のステップS1001からステップS1005までの処理は、図9に示したステップS301からステップS305までの処理と同じである。
第5の実施形態では、遷移先ページのページファイルにアプリ構成情報が含まれていると判定され(ステップS1004:Yes)、アプリ設定ロード処理が開始されると(ステップS1005)、アプリ設定ロード部133が、イベントが発生したコンテキストで今まで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135−5に対してURLリストの削除命令を出す。アプリ範囲管理部135−5は、アプリ設定ロード部133からのURLリストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1006)、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストを削除する処理を行う(ステップS1007)。
次に、アプリ設定ロード部133は、拡張機能利用証明書保存部136−5に対して利用証明書リストの削除命令を出す。拡張機能利用証明書保存部136−5は、アプリ設定ロード部133からの利用証明書リストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1008)、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを削除する処理を行う(ステップS1009)。
また、アプリ設定ロード部133は、イベントが発生したコンテキストで新たに実行するウェブアプリケーションに対応するアプリ構成情報を保存するために、アプリ範囲管理部135−5に対してURLリストの保存命令を出す。アプリ範囲管理部135−5は、アプリ設定ロード部133からのURLリストの保存命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1010)、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に、新たなウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストを保存する処理を行う(ステップS1011)。
次に、アプリ設定ロード部133は、拡張機能利用証明書保存部136−5に対して利用証明書リストの保存命令を出す。拡張機能利用証明書保存部136−5は、アプリ設定ロード部133からの利用証明書リストの保存命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1012)、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に、新たなウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを保存する処理を行う(ステップS1013)。これにより、新たなウェブアプリケーションに対応したアプリ構成情報に含まれるURLリストおよび利用証明書リストが主記憶メモリ12に保存される。
一方、遷移先ページのページファイルにアプリ構成情報が含まれていない場合(ステップS1004:No)、ページ種別振分け部132は、現在実行中のウェブアプリケーションが継続実行、実行終了のいずれかであると判断し、そのどちらかであるかを判断するためにアプリ終了判定部134を呼び出して、遷移先ページのURLを渡す。
アプリ終了判定部134は、ページ種別振分け部132から遷移先ページのURLを取得すると、まず、アプリ範囲管理部135−5に対してURLリストの取得命令を出す。アプリ範囲管理部135−5は、アプリ終了判定部134からのURLリストの取得命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1014)、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に保存されているURLリストを取得する処理を行って、取得したURLリストをアプリ終了判定部134に返す(ステップS1015)。このとき、アプリ終了判定部134は、アプリ範囲管理部135−5が取得したURLリストの有無を判定し(ステップS1016)、アプリ範囲管理部135−5が取得したURLリストがなければ(ステップS1016:No)、そのまま処理を終了する。一方、アプリ範囲管理部135−5が取得したURLリストがあれば(ステップS1016:Yes)、ページ種別振分け部132から取得した遷移先ページのURLがそのURLリストに含まれているか否かを判定する(ステップS1017)。
そして、遷移先ページのURLがURLリストに含まれている場合(ステップS1017:Yes)、アプリ終了判定部134は、同一のウェブアプリケーションの実行が継続されているものと判断し、そのまま処理を終了する。一方、遷移先ページのURLがURLリストに含まれていない場合(ステップS1017:No)、アプリ終了判定部134は、それまで実行していたウェブアプリケーションが終了したものと判断し、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135−5に対してURLリストの削除命令を出す。アプリ範囲管理部135−5は、アプリ終了判定部134からのURLリストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1018)、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストを削除する処理を行う(ステップS1019)。
次に、アプリ終了判定部134は、拡張機能利用証明書保存部136−5に対して利用証明書リストの削除命令を出す。拡張機能利用証明書保存部136−5は、アプリ設定ロード部133からの利用証明書リストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得し(ステップS1020)、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを削除する処理を行う(ステップS1021)。
図30は、第5の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図21に示した第3の実施形態の処理手順と比較すると、ステップS1104で取得した拡張機能識別子のリストの中に、呼出し要求のあった拡張機能の識別子があると判定された場合に(ステップS1105:Yes)、拡張機能の呼出しが起きたコンテキストが持つ拡張機能の利用証明書を元に拡張機能のアクセス制御を行う処理が加わっている点が異なる。図30のステップS1101からステップS1106までの処理は、図21に示したステップS701からステップS706までの処理と同じである。
第5の実施形態では、呼出し要求のあった拡張機能の識別子がリストの中に存在する場合(ステップS1105:Yes)、拡張機能呼出し可否判定部122は、拡張機能利用証明書保存部136−5に対して利用証明書リストの取得命令を出す。拡張機能利用証明書保存部136−5は、拡張機能呼出し可否判定部122からの利用証明書リストの取得命令に応じて、コンテキスト判定部137から拡張機能の呼出し要求があったコンテキストの識別子を取得し(ステップS1107)、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域から利用証明書リストを取得して、拡張機能呼出し可否判定部122に返す(ステップS1108)。その後の処理、すなわち、図30のステップS1109からステップS1115までの処理は、図21に示したステップS708からステップS714までの処理と同じである。これにより、コンテキストで実行中のウェブアプリケーションごとに、利用証明書の使い分けが可能になる。
図31は、コンテキスト判定部137によるコンテキスト識別子の取得時の処理手順を示すフローチャートである。
コンテキスト判定部137は、コンテキスト識別子の取得要求が来た場合、まず発生したイベントの種別を取得する(ステップS1201)。このイベントには、ページ遷移と、拡張機能へのアクセスとが存在する。そこで、コンテキスト判定部137は、ステップS1201で取得したイベントの種別から、発生したイベントが拡張機能へのアクセスか否かを判定する(ステップS1202)。ここで、発生したイベントが拡張機能へのアクセスではない、つまりページ遷移である場合は(ステップS1202:No)、コンテキスト判定部137は、イベントが発生したコンテキストのコンテキスト識別子を取得する(ステップS1203)。
一方、拡張機能はオブジェクトという形でコンテキストに紐付けされるが、発生したイベントが拡張機能へのアクセスである場合は(ステップS1202:Yes)、コンテキスト判定部137は、拡張機能のオブジェクトが存在するコンテキスト識別子ではなく、拡張機能のアクセス命令を発行したコンテキストの識別子を取得する(ステップS1204)。もちろんオブジェクトが存在するコンテキスト識別子とアクセス命令を発行したコンテキストの識別子が一致してもよい。最後に、コンテキスト判定部137の呼出し元に対して、取得したコンテキスト識別子を返して(ステップS1205)、処理が終了する。
拡張機能はオブジェクトで管理され、別コンテキストで実行しているウェブアプリケーションから別コンテキストの拡張機能を参照して間接的に拡張機能を呼出すことが可能である。第5の実施形態のコンテキスト判定部137は、拡張機能へのアクセス時には、拡張機能のオブジェクトが存在するコンテキストではなく、拡張機能のオブジェクトへのアクセスを行ったコンテキストを判定する。これにより、拡張機能の利用証明書を持つウェブアプリケーションの拡張機能が、拡張機能の利用証明書を持たないウェブアプリケーションのコンテキストから間接的に不正利用されることを有効に防止することが可能となる。
さらに、第5の実施形態において、第4の実施形態で説明したセキュリティポリシ管理部113や署名検証部151と連携してセキュリティポリシの分離や利用証明書の安全性検証を行う場合には、利用証明書の保存処理において図27のフローチャートで示した処理を行い、起動時の処理として図26のフローチャートで示した処理を行うようにすればよい。
以上説明したように、第5の実施形態によれば、拡張機能アクセス制御部100−5のライフサイクル管理部130−5内にコンテキスト判定部137を付加するのみで、複数のウェブアプリケーションの並列実行を効率的に行うことが可能になる。主記憶メモリ12についても、URLリストおよび利用証明書リストの格納領域をコンテキスト数に応じて増やすだけで、複数のウェブアプリケーションの並列実行が可能になるため、利用効率がよい。
ウェブアプリケーションでは、並列実行しているコンテキスト間のオブジェクトの相互アクセスも可能である。拡張機能もオブジェクトで管理されるため、別コンテキストで実行しているウェブアプリケーションから間接的に拡張機能を呼出すことが可能である。第5の実施形態におけるコンテキスト判定部137は、拡張機能へのアクセス時には、拡張機能のオブジェクトが存在するコンテキストではなく、拡張機能のオブジェクトへアクセスを行ったコンテキストを判定する。これにより、拡張機能の利用証明書を持たないウェブアプリケーションから拡張機能の利用証明書を持つウェブアプリケーションの拡張機能のオブジェクトが不正利用されることを防ぐことが可能となる。また、コンテキスト間のオブジェクトアクセスによる拡張機能の不正アクセスについても防止することが可能である。
なお、第5の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。
(第6の実施形態)
次に、第6の実施形態について説明する。第1乃至第5の実施形態では、アプリ構成情報を含むページファイルへのアクセスをもってウェブアプリケーション起動と判定していた。これに対して、第6の実施形態では、ウェブアプリケーションの起動に専用命令を用いるようにしている。これにより、ページ遷移時の処理が単純になり、処理負荷の軽減を図ることが可能となる。
次に、第6の実施形態について説明する。第1乃至第5の実施形態では、アプリ構成情報を含むページファイルへのアクセスをもってウェブアプリケーション起動と判定していた。これに対して、第6の実施形態では、ウェブアプリケーションの起動に専用命令を用いるようにしている。これにより、ページ遷移時の処理が単純になり、処理負荷の軽減を図ることが可能となる。
図32は、第6の実施形態の情報処理装置10−6内部の機能的な構成を示す機能ブロック図である。図28に示した第5の実施形態の構成と比較すると、拡張機能アクセス制御部100−6のライフサイクル管理部130−6内に、ページ種別振分け部132に代えて起動命令検出部138が設けられている点が異なっている。以下、第1乃至第5の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第6の実施形態の特徴部分についてのみ説明する。
第6の実施形態のブラウザ部200−6のアプリケーション実行部210−6は、ページ遷移時にページ遷移検出部131−6を呼び出す機能に加え、アプリ起動命令の実行時に、起動命令の引数として設定されたウェブアプリケーションの識別情報を渡して起動命令検出部138を呼出す機能を有する。このウェブアプリケーションの識別情報としては、例えば、アプリ構成情報が含まれるページファイル(ウェブアプリケーションで最初に実行されるページファイル)のURLを用いればよい。また、アプリ構成情報をページファイルとは別のコンフィギュレーションファイルとして提供する場合は、コンフィギュレーションファイルのURLを用いればよい。
起動命令検出部138は、アプリケーション実行部210−6から渡されたウェブアプリケーションの識別情報を元に、アプリ構成情報を含むページファイルのダウンロードを行い、アプリ構成情報を取得する。さらに、起動命令検出部138は、アプリ設定ロード部133に対して取得したアプリ構成情報を渡し、アプリ構成情報に含まれるURLリストや利用証明書リストの読み込み依頼を出す。
第6の実施形態のページ遷移検出部131−6は、アプリケーション実行部210−6から渡されたページファイルのURLなどの識別情報をアプリ終了判定部134に渡して、ウェブアプリケーションが実行継続か、実行終了かの判定依頼を出す。第1乃至第5の実施形態では、さらにページ種別振分け部132が、遷移先ページのページファイルのURLがアプリ構成情報のURLリストに含まれるかの判断を行っていたが、第6の実施形態においてはその処理は必要ない。
図33は、第6の実施形態におけるウェブアプリケーション起動時の処理手順を示すフローチャートである。第6の実施形態では、アプリ起動命令を実行することでウェブアプリケーションが起動する。
まず、アプリケーション実行部210−6が、アプリ構成情報を更新するために、起動命令検出部138にアプリ起動命令を出す。この際、アプリ起動命令の引数として指定されるページファイルのURLなどのウェブアプリケーションの識別情報を渡す(ステップS1301)。
次に、起動命令検出部138が、アプリケーション実行部210−6から渡されたウェブアプリケーションの識別情報を元に、対応するウェブアプリケーションのアプリ構成情報を含むページファイルをダウンロードする(ステップS1302)。なお、アプリ構成情報を含むページファイルとは別のコンフィギュレーションファイルとして提供する場合は、起動命令検出部138は、このコンフィギュレーションファイルをダウンロードする。
次に、起動命令検出部138は、ダウンロードしたページファイルの中からアプリ構成情報を取り出し、アプリ構成情報を保存するために、アプリ設定ロード部133に渡す。これにより、アプリ設定ロード処理が開始され(ステップS1303)、それまで実行していたウェブアプリケーションに対応するURLリストおよび利用証明書リストの削除(ステップS1304、ステップS1305)と、新たに実行されるウェブアプリケーションに対応するURLリストおよび利用証明書リストの保存(ステップS1306、ステップS1307)が行われる。
図34は、第6の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、図9のステップS303からステップS309に相当する処理は行わず、ステップS1403の処理が加わっている点が異なっている。図34のステップS1401、ステップS1402の処理は、図9に示したステップS301、ステップS302の処理と同じである。
第6の実施形態では、上述したように、ウェブアプリケーションの起動には専用のアプリ起動命令を用いるため、ページ遷移時にウェブアプリケーションの開始かどうかを判定する必要がない。したがって、ページ遷移検出部131−6は、遷移先ページのURLを取得した後、ページ種別振分け部132を呼出すのではなく、アプリ終了判定部134を直接呼出す(ステップS1403)。その後の処理、すなわち、図34のステップS1404からステップS1408までの処理は、図9に示したステップS310からステップS314までの処理と同じである。
以上説明したように、第6の実施形態によれば、ウェブアプリケーションの起動に専用のアプリ起動命令を用いるようにしているので、ページ遷移時の処理が単純になり、処理負荷が軽減される。したがって、本実施形態は、リソースが限られる環境にも適用することができる。
なお、第6の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。
(第7の実施形態)
次に、第7の実施形態について説明する。第1乃至第6の実施形態では、ウェブアプリケーションを構成する複数のページファイルやメディアファイルがパッケージングされずに、独立してサーバ装置20に格納されている場合を想定していた。このようにページファイルやメディアファイルを独立させる構成では、ウェブアプリケーションのアップデートやページファイルを動的に生成する場合などにおいて自由度が高くなる一方で、ウェブアプリケーションのデータを一括して配布し、端末にインストールして利用するような場合に手間がかかる。このため、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部を1つのアーカイブファイルにパッケージングしてサーバ装置20に格納しておくことも想定される。第7の実施形態は、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が1つのアーカイブファイルにパッケージングされている場合に対応できるようにしたものである。
次に、第7の実施形態について説明する。第1乃至第6の実施形態では、ウェブアプリケーションを構成する複数のページファイルやメディアファイルがパッケージングされずに、独立してサーバ装置20に格納されている場合を想定していた。このようにページファイルやメディアファイルを独立させる構成では、ウェブアプリケーションのアップデートやページファイルを動的に生成する場合などにおいて自由度が高くなる一方で、ウェブアプリケーションのデータを一括して配布し、端末にインストールして利用するような場合に手間がかかる。このため、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部を1つのアーカイブファイルにパッケージングしてサーバ装置20に格納しておくことも想定される。第7の実施形態は、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が1つのアーカイブファイルにパッケージングされている場合に対応できるようにしたものである。
図35は、第7の実施形態の情報処理装置10−7内部の機能的な構成を示す機能ブロック図である。図28に示した第5の実施形態の構成と比較すると、拡張機能アクセス制御部100−7のライフサイクル管理部130−7内にアプリ展開部139およびコンフィグ生成部140が付加されている点が異なっている。以下、第1乃至第6の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第7の実施形態の特徴部分についてのみ説明する。
アプリ展開部139は、複数のファイルがパッケージングされたアーカイブファイルのデータを受け取り、アーカイブファイルを複数のファイルの状態に展開してストレージ13もしくは主記憶メモリ12に格納する。また、アプリ展開部139は、展開したアーカイブファイルの中に格納されているページファイル(アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合はコンフィギュレーションファイル)に含まれるアプリ構成情報を読み取り、その内容を渡してコンフィグ生成部140を呼出し、コンフィグ生成部140に対してアプリ構成情報の動的な生成を依頼する。アーカイブファイルの方式としては、例えばzip形式など一般に知られた方式を使えばよい。
コンフィグ生成部140は、アプリ展開部139が展開したファイルの中から特定ファイル名(例:index.html)が付けられたページファイルに含まれるアプリ構成情報を読み取る。また、コンフィグ生成部140は、アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合は、アプリ展開部139が展開したファイルの中から特定ファイル名(例:configuration.dat)が付けられたコンフィギュレーションファイルの内容を読み取る。さらに、コンフィグ生成部140は、アーカイブファイルに含まれるページファイルを列挙してURLリストを動的に生成し、アプリ範囲情報と結合する。
ウェブアプリケーションがアーカイブファイルに含まれるページファイルのみから構成される場合には、アプリ構成情報にURLリストを含める必要はない。これは、1つのアーカイブファイルにパッケージングされているページファイルは、同一のウェブアプリケーションのファイルであることは明白なためである。一方で、アーカイブファイルに含まれないページファイルが、同じセキュリティポリシを適用するウェブアプリケーションの一部となる場合には、アプリ構成情報には、アーカイブファイルに含まれないページファイルのURLと、利用証明書リストとが含まれる。このため、コンフィグ生成部140は、アーカイブファイルに含まれるページファイルを列挙して動的に生成したURLリストをアプリ範囲情報と結合することで、アーカイブファイルに含まれないページファイルも含めて、1つのウェブアプリケーションの範囲を表すURLリストを生成する。
第7の実施形態におけるページ種別振分け部132−7は、第1の実施形態におけるページ種別振分け部132の機能に加えて、遷移先ページファイルのMIMEタイプや遷移先ページファイルの拡張子からそのファイルがアーカイブファイルであるかどうか判定する機能を持つ。さらにページ種別振分け部132−7は、遷移先ファイルがアーカイブファイルである場合には、アプリ展開部139にファイルのデータを渡し、パッケージングされたアーカイブファイルの展開を依頼する。さらにページ種別振分け部132−7は、コンフィグ生成部140で動的に生成されたURLリストが結合されたアプリ構成情報をアプリ展開部139から受け取り、アプリ設定ロード部133に対してアプリ構成情報の保存を依頼する。
第7の実施形態におけるアプリ終了判定部134−7は、第1の実施形態におけるアプリ終了判定部134の機能に加えて、ウェブアプリケーションの終了時に、アプリ展開部139が展開したデータを削除する機能を持つ。
図36は、第7の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、ページ種別振分け部132−7の呼出し(ステップS1503)の後に、遷移先ページのファイルがアーカイブファイルか否かを判定する処理(ステップS1504)と、遷移先ページのファイルがアーカイブファイルの場合に、アーカイブファイルを展開してからウェブアプリケーションを実行するための処理(ステップS1516〜ステップS1519)が加わっている点が異なる。図36のステップS1501からステップS1503までの処理は、図9に示したステップS301からステップS303までの処理と同じである。
第7の実施形態では、ページ種別振分け部132−7が、ページ遷移検出部131から遷移先ページのURLを受け取ると、まず、遷移先ページのファイルのMIMEタイプや拡張子から、そのファイルがアーカイブファイルであるかどうかを判定する(ステップS1504)。遷移先ページのファイルがアーカイブファイルでない場合には(ステップS1504:No)、遷移先ページのページファイルにアプリ構成情報が含まれるか否かの判定(ステップS1505)に移り、その後のステップS1506からステップS1515において、第1の実施形態と同様の処理、すなわち、図9に示したステップS305からステップS314までと同じ処理を行う。
一方、遷移先ページのファイルがアーカイブファイルである場合には(ステップS1504:Yes)、ページ種別振分け部132−7は、アーカイブファイル内に格納されたウェブアプリケーションの実行を開始するために、アーカイブファイルのデータをアプリ展開部139に渡して、アーカイブファイルの展開を依頼する。そして、アプリ展開部139は、ページ種別振分け部132−7から受け取ったアーカイブファイルを複数のファイルの状態に展開してストレージ13もしくは主記憶メモリ12に格納する(ステップS1516)。
その後、アプリ展開部139は、展開を行ったファイルの中からウェブアプリケーションで最初に実行するページファイル(アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合はコンフィギュレーションファイル)を探し、そのページファイルに含まれるアプリ構成情報を読み込んで、ページ種別振分け部132−7に返す(ステップS1517)。ここでページファイルから読み込まれたアプリ構成情報には、アーカイブファイルに含まれないウェブアプリケーションを構成するページファイルのURLや利用証明書リストが含まれる。ただし、このアプリ構成情報には、アーカイブファイルにパッケージングされたページファイルのURLは含まれないため、アーカイブファイルにパッケージングされたページファイルを含めたアプリ範囲情報を生成する必要がある。
そこで、ページ遷移振分け部132−7は、コンフィグ生成部140にステップS1517で読み込まれたアプリ構成情報を渡して、アプリ構成情報の生成を依頼する。コンフィグ生成部140は、まず、アーカイブファイルに含まれるページファイルを列挙して、アーカイブファイルに含まれる各ページファイルのURLを取得する(ステップS1518)。そして、コンフィグ生成部140は、ページ種別振分け部132−7から渡されたアプリ構成情報と、ステップS1518で取得した各ページファイルのURLを結合して、ウェブアプリケーションに対応するアプリ構成情報を生成して、ページ種別振分け部132−7に返す(ステップS1519)。
その後、ページ種別振分け部132−7は、コンフィグ生成部140が生成したアプリ構成情報をアプリ設定ロード部133に渡して、アプリ設定ロード処理を依頼する。そして、アプリ設定ロード部133は、ステップS1506からステップS1510において、第1の実施形態と同様の処理、すなわち、図9のステップS305からステップS309までの処理と同じ処理を行う。
以上説明したように、第7の実施形態によれば、遷移先ページがアーカイブファイルにパッケージングされている場合に、アプリ展開部139がアーカイブファイルを展開し、コンフィグ生成部140がアーカイブファイルに含まれるページファイルのURLとアプリ構成情報とを結合して、ウェブアプリケーションに対応するアプリ構成情報を生成する。したがって、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が1つのアーカイブファイルにパッケージングされていたとしても、自動的にウェブアプリケーションの開始処理を行うことができる。また、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部のみをアーカイブファイルとしてパッケージングし、動的に変更する部分はアーカイブしないようにすることもでき、ウェブアプリケーションを構成するページファイルの提供の形態によらず、ウェブアプリケーションにおいて同じセキュリティポリシで拡張機能のアクセス制御を行えるようになるため、ウェブアプリケーションの開発の幅を広げることが可能となる。
なお、第7の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。
(第8の実施形態)
次に、第8の実施形態について説明する。第1乃至第7の実施形態では、ウェブアプリケーションごとのアプリ構成情報に拡張機能の利用証明書が付属していた。これに対して、第8の実施形態では、アプリ構成情報に拡張機能の利用証明書は付属せず、拡張機能のセキュリティポリシのみからアクセス制御を行う。これにより、ウェブアプリケーションの作成者がウェブアプリケーションを開発する際に利用証明書を添付する手間を減らすことが可能になる。
次に、第8の実施形態について説明する。第1乃至第7の実施形態では、ウェブアプリケーションごとのアプリ構成情報に拡張機能の利用証明書が付属していた。これに対して、第8の実施形態では、アプリ構成情報に拡張機能の利用証明書は付属せず、拡張機能のセキュリティポリシのみからアクセス制御を行う。これにより、ウェブアプリケーションの作成者がウェブアプリケーションを開発する際に利用証明書を添付する手間を減らすことが可能になる。
図37は、第8の実施形態の情報処理装置10−8内部の機能的な構成を示す機能ブロック図である。図15に示した第3の実施形態の構成と比較すると、拡張機能アクセス制御部100−8のライフサイクル管理部130−8内に、拡張機能利用証明書保存部136に代えてアプリケーション固有データ生成部141が設けられている点が異なっている。以下、第1乃至第7の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第8の実施形態の特徴部分についてのみ説明する。
アプリケーション固有データ生成部141は、アクセス制御実行部120−8内の拡張機能呼出し可否判定部122−8からの依頼に応じて、アプリ構成情報が格納されたページファイルのURLなど、アプリケーション作成者による偽装が不可能なアプリケーション固有データを生成する。
第8の実施形態における拡張機能管理部110−8内のセキュリティポリシ管理部113−8は、図38に示すようなセキュリティポリシの管理を行う。図38は、第8の実施形態においてセキュリティポリシ管理部113−8によりロードされるセキュリティポリシのデータ構造の一例を示す図である。図17−1に示したセキュリティポリシのデータ構造と比較すると、個々のセキュリティポリシエレメントの適用対象となるウェブアプリケーションのアプリケーション固有データを含む点が異なっている。一つのセキュリティポリシエレメントに複数の対象アプリケーションの固有データを含んでいてもよい。
第8の実施形態におけるセキュリティポリシ管理部113−8は、第3の実施形態におけるセキュリティポリシ管理部113と同じく、拡張機能の識別子を受信して対応する拡張機能のセキュリティポリシを主記憶メモリ12にロードする機能を持つ。さらに、第8の実施形態におけるセキュリティポリシ管理部113−8は、アプリケーション固有データを受けて、対応するセキュリティポリシエレメントを返す機能を有する。
図39は、第8の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図21に示した第3の実施形態の処理手順と比較すると、呼出し要求のあった拡張機能があると判定された後に(ステップS1605:Yes)、アプリケーション固有データを取得するとともに、セキュリティポリシ管理部113−8が管理するセキュリティポリシから対応するセキュリティポリシエレメントを取得する処理(ステップS1607、ステップS1608)が加わり、対応する利用証明書があるかどうかを判定する処理がない点が異なる。図39のステップS1601からステップS1606までの処理は、図21に示したステップS701からステップS706までの処理と同じである。
第8の実施形態では、呼出し要求のあった拡張機能があると判定されると(ステップS1605:Yes)、拡張機能呼出し可否判定部122−8が、呼出し要求のあった拡張機能をウェブアプリケーションで利用することが許可されているかどうかを判定するために、アプリケーション固有データ生成部141に対して、アプリケーション固有データの取得を依頼する。アプリケーション固有データ生成部141は、現在実行中のウェブアプリケーションのアプリケーション固有データ、例えばアプリ構成情報が格納されたページファイルのURLなどを取得して、拡張機能呼出し可否判定部122−8に返す(ステップS1607)。
次に、拡張機能呼出し可否判定部122−8は、セキュリティポリシ管理部113−8に対して、アプリケーション固有データ生成部141から取得したアプリケーション固有データに対応するセキュリティポリシエレメントの取得を依頼する。セキュリティポリシ管理部113−8は、起動時にロードしたセキュリティポリシの中から、アプリケーション固有データ生成部141から取得したアプリケーション固有データに対応するセキュリティポリシエレメントを取得して拡張機能呼出し可否判定部122−8に返す(ステップS1608)。
次に、拡張機能呼出し可否判定部122−8は、呼び出す関数がセキュリティポリシエレメントに含まれるかどうかにより、呼出し要求があった拡張機能の呼出しが許可されているか否かを判定する(ステップS1609)。その後の処理、すなわち、図39のステップS1610からステップS1612までの処理は、図21に示したステップS712からステップS713までの処理と同じである。
図40は、第8の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、アプリケーション固有データを生成する処理(ステップS1708)やアプリケーション固有データを削除する処理(ステップS1713)が加わり、利用証明書リストを削除する処理(ステップS307、ステップS314)や利用証明書リストを保存する処理(ステップS309)がない点が異なる。図40のステップS1701からステップS1707までの処理は、図9に示したステップS301からステップS308(ステップS307は除く)までの処理と同じである。また、図40のステップS1709からステップS1712までの処理は、図9に示したステップS310からステップS313までの処理と同じである。
第8の実施形態では、ウェブアプリケーション終了時に、アプリ設定ロード部133−8がアプリケーション固有データ生成部141を呼出し、それまで実行していたウェブアプリケーションに対応するアプリケーション固有データの削除処理を行う(ステップS1713)。また、アプリケーションの開始時には、アプリ設定ロード部133−8がアプリケーション固有データ生成部141を呼出し、アプリケーション固有のデータの生成と保存を依頼する(ステップS1708)。
以上説明したように、第8の実施形態によれば、アプリ構成情報に拡張機能の利用証明書は付属せず、セキュリティポリシのみから拡張機能のアクセス制御を行うようにしているので、ウェブアプリケーションの作成者はウェブアプリケーションを開発する際に利用証明書を添付する必要はなく、ウェブアプリケーションの作成者の負担を軽減することができる。また、セキュリティポリシデータは拡張機能に付属するため、ウェブアプリケーションの作成者による改ざんなどの心配がない。すなわち、ウェブアプリケーションから拡張機能の不正利用を防ぎたい場合にも、第4の実施形態で説明したような拡張機能の利用証明書の検証処理を行うことなく、拡張機能の不正利用を有効に防止することが可能となる。
以上説明したとおり、第1乃至第8の実施形態によれば、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができる。
第1乃至第8の実施形態の情報処理装置10〜10−8において、拡張機能アクセス制御部100〜100−8による上述した各機能は、情報処理装置10〜10−8のCPU11がストレージ13に格納された拡張機能アクセス制御プログラムを実行することにより実現できる。
情報処理装置10〜10−8のCPU11が実行する拡張機能アクセス制御プログラムは、例えば、インストール可能な形式又は実行可能な形式のファイルでCD−ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD−R(Compact Disk Recordable)、DVD(Digital Versatile Disc)などのコンピュータで読み取り可能な記録媒体に記録されてコンピュータプログラムプロダクトとして提供される。
また、情報処理装置10〜10−8のCPU11が実行する拡張機能アクセス制御プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、情報処理装置10〜10−8のCPU11が実行する拡張機能アクセス制御プログラムを、インターネットなどのネットワーク経由で提供または配布するように構成してもよい。
また、情報処理装置10〜10−8のCPU11が実行する拡張機能アクセス制御プログラムを、情報処理装置10〜10−8のストレージ13に予め組み込んで提供するように構成してもよい。
情報処理装置10〜10−8のCPU11が実行する拡張機能アクセス制御プログラムは、拡張機能アクセス制御部100〜100−8の各処理部(拡張機能管理部110〜110−8、アクセス制御実行部120〜120−8およびライフサイクル管理部130〜130−8など)を含むモジュール構成となっており、実際のハードウェアとしては、例えば、CPU11(プロセッサ)がストレージ13から拡張機能アクセス制御プログラムを主記憶メモリ12に読み出して実行することにより、上記各部が主記憶メモリ12上にロードされ、上述した各部が主記憶メモリ12上に生成されるようになっている。
以上、本発明の実施形態を説明したが、ここで説明した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。ここで説明した新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここで説明した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
10 情報処理装置
20 サーバ装置
100 拡張機能アクセス制御部
110 拡張機能管理部
111 拡張機能ロード部
112 拡張機能呼出し部
113 セキュリティポリシ管理部
120 アクセス制御実行部
121 拡張機能アクセス検出部
122 拡張機能呼出し可否判定部
130 ライフサイクル管理部
131 ページ遷移検出部
132 ページ種別振分け部
133 アプリ設定ロード部
134 アプリ終了判定部
135 アプリ範囲管理部
136 拡張機能利用証明書保存部
137 コンテキスト判定部
138 起動命令検出部
139 アプリ展開部
140 コンフィグ生成部
141 アプリケーション固有データ生成部
150 データ検証部
151 署名検証部
200 ブラウザ部
20 サーバ装置
100 拡張機能アクセス制御部
110 拡張機能管理部
111 拡張機能ロード部
112 拡張機能呼出し部
113 セキュリティポリシ管理部
120 アクセス制御実行部
121 拡張機能アクセス検出部
122 拡張機能呼出し可否判定部
130 ライフサイクル管理部
131 ページ遷移検出部
132 ページ種別振分け部
133 アプリ設定ロード部
134 アプリ終了判定部
135 アプリ範囲管理部
136 拡張機能利用証明書保存部
137 コンテキスト判定部
138 起動命令検出部
139 アプリ展開部
140 コンフィグ生成部
141 アプリケーション固有データ生成部
150 データ検証部
151 署名検証部
200 ブラウザ部
Claims (13)
- ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、
ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存するアプリ範囲管理部と、
前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する終了判定部と、
前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する利用可否判定部と、
実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す拡張機能呼出し部と、を備えることを特徴とする情報処理装置。 - ウェブアプリケーションの実行開始時に、該ウェブアプリケーションで利用が許可された前記拡張機能を表す情報である利用証明書を受信して前記記憶部に保存する利用証明書保存部をさらに備え、
前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する利用証明書が前記記憶部に保存されているか否かにより、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用することが許可されているか否かを判定することを特徴とする請求項1に記載の情報処理装置。 - 前記アプリ範囲情報および前記利用証明書は、ウェブアプリケーションにおいて最初に実行されるページファイルに格納されており、
前記アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションにおいて最初に実行されるページファイルから前記アプリ範囲情報を読み出して前記記憶部に保存し、
前記利用証明書保存部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションにおいて最初に実行されるページファイルから前記利用証明書を読み出して前記記憶部に保存することを特徴とする請求項2に記載の情報処理装置。 - 前記アプリ範囲情報および前記利用証明書は、ウェブアプリケーションを構成するページファイルと異なるコンフィギュレーションファイルに格納されており、
前記アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、前記コンフィギュレーションファイルから前記アプリ範囲情報を読み出して前記記憶部に保存し、
前記利用証明書保存部は、ウェブアプリケーションの実行開始時に、前記コンフィギュレーションファイルから前記利用証明書を読み出して前記記憶部に保存することを特徴とする請求項2に記載の情報処理装置。 - 前記拡張機能は複数の関数を含み、
前記拡張機能ごとに、複数の関数のうち利用を許可する関数の組み合わせであるセキュリティポリシ要素を複数記述したセキュリティポリシ情報を受信して前記記憶部に保存するセキュリティポリシ保存部をさらに備え、
前記利用証明書は、実行中のウェブアプリケーションに対して適用される前記セキュリティポリシ要素を含み、
前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する利用証明書が保存されている場合に、呼出しが要求された前記拡張機能のうち、利用証明書に含まれる前記セキュリティポリシ要素で示される関数の利用が許可されていると判定することを特徴とする請求項2に記載の情報処理装置。 - 実行中のウェブアプリケーションに固有のデータを用いて前記利用証明書の正当性を検証する証明書検証部をさらに備えることを特徴とする請求項2に記載の情報処理装置。
- 前記拡張機能は複数の関数を含み、
前記拡張機能ごとに、複数の関数のうち利用を許可する関数の組み合わせであるセキュリティポリシ要素を複数記述するとともに、各セキュリティポリシ要素を適用するウェブアプリケーションを記述したセキュリティポリシ情報を受信して前記記憶部に保存するセキュリティポリシ保存部をさらに備え、
前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する複数のセキュリティポリシ要素のなかに、実行中のウェブアプリケーションに対して適用されるセキュリティポリシ要素がある場合に、該セキュリティポリシ要素で示される関数の利用が許可されていると判定することを特徴とする請求項1に記載の情報処理装置。 - 前記ブラウザ部が複数のウェブアプリケーションを並列実行している場合に、前記拡張機能の呼出しがあったウェブアプリケーションを判別する判別部をさらに備え、
前記利用可否判定部は、呼出しが要求された前記拡張機能が、前記判別部が判別したウェブアプリケーションで利用が許可されているか否かを判定することを特徴とする請求項1または7に記載の情報処理装置。 - 前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルに前記アプリ範囲情報および前記利用証明書が格納されている場合に、新たなウェブアプリケーションの実行が開始されたと判定する開始判定部をさらに備え、
前記アプリ範囲管理部は、前記開始判定部により新たなウェブアプリケーションの実行が開始されたと判定された場合に、新たなウェブアプリケーションに対応する前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項3に記載の情報処理装置。 - 予め定められた所定の命令を検出した場合に、新たなウェブアプリケーションの実行が開始されたと判定する開始判定部をさらに備え、
前記アプリ範囲管理部は、前記開始判定部により新たなウェブアプリケーションの実行が開始されたと判定された場合に、新たなウェブアプリケーションに対応する前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項1または7に記載の情報処理装置。 - 前記ブラウザ部が複数のページファイルを含むアーカイブファイルを受信した場合に、該アーカイブファイルを複数のページファイルに展開するファイル展開部と、
前記ファイル展開部により展開された複数のページファイルと、前記アーカイブファイルに含まれないファイルとを含む前記アプリ範囲情報を生成する生成部と、をさらに備え、
前記アプリ範囲管理部は、前記生成部が生成した前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項1または7に記載の情報処理装置。 - ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、記憶部と、を備える情報処理装置において実行される情報処理方法であって、
ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する工程と、
前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する工程と、
前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する工程と、
実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す工程と、を含むことを特徴とする情報処理方法。 - ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、記憶部と、を備える情報処理装置に、
ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する機能と、
前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する機能と、
前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する機能と、
実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す機能と、を実現させるプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011184767A JP5575071B2 (ja) | 2011-08-26 | 2011-08-26 | 情報処理装置、情報処理方法、およびプログラム |
US13/533,077 US9317681B2 (en) | 2011-08-26 | 2012-06-26 | Information processing apparatus, information processing method, and computer program product |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011184767A JP5575071B2 (ja) | 2011-08-26 | 2011-08-26 | 情報処理装置、情報処理方法、およびプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2013045400A JP2013045400A (ja) | 2013-03-04 |
JP5575071B2 true JP5575071B2 (ja) | 2014-08-20 |
Family
ID=47745662
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011184767A Expired - Fee Related JP5575071B2 (ja) | 2011-08-26 | 2011-08-26 | 情報処理装置、情報処理方法、およびプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US9317681B2 (ja) |
JP (1) | JP5575071B2 (ja) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001093226A (ja) | 1999-09-21 | 2001-04-06 | Sony Corp | 情報通信システムおよび方法、ならびに、情報通信装置および方法 |
JP5662391B2 (ja) | 2012-08-17 | 2015-01-28 | 株式会社東芝 | 情報操作装置、情報出力装置および情報処理方法 |
US20180343174A1 (en) * | 2012-10-09 | 2018-11-29 | Google Inc. | Rule based page processing and network request processing in browsers |
CN103002019B (zh) * | 2012-11-14 | 2016-01-13 | 北京奇虎科技有限公司 | 浏览器及浏览器发送页游消息的方法 |
JP6131817B2 (ja) | 2013-10-08 | 2017-05-24 | 富士通株式会社 | 通信端末、通信処理方法および通信処理プログラム |
US9338057B2 (en) * | 2013-10-30 | 2016-05-10 | Netapp, Inc. | Techniques for searching data associated with devices in a heterogeneous data center |
US9930095B2 (en) * | 2014-03-26 | 2018-03-27 | Google Llc | System for managing extension modifications to web pages |
RU2632141C2 (ru) * | 2015-06-30 | 2017-10-02 | Общество С Ограниченной Ответственностью "Яндекс" | Способ и компьютерное устройство для динамической индексации и загрузки кодов модулей |
JP6023858B1 (ja) * | 2015-08-17 | 2016-11-09 | 日本電信電話株式会社 | 計算システム、計算装置、その方法、およびプログラム |
JP6440100B2 (ja) * | 2016-03-31 | 2018-12-19 | 京セラドキュメントソリューションズ株式会社 | 電子機器 |
US10326603B2 (en) * | 2016-05-06 | 2019-06-18 | Blackberry Limited | Inter-workspace communications |
RU2706873C1 (ru) * | 2018-12-28 | 2019-11-21 | Акционерное общество "Лаборатория Касперского" | Система и способ проверки ЭЦП файла |
RU2708353C1 (ru) * | 2018-12-28 | 2019-12-05 | Акционерное общество "Лаборатория Касперского" | Система и способ стойкой к атакам проверки ЭЦП файлов |
CN116700768B (zh) * | 2022-10-20 | 2024-04-02 | 荣耀终端有限公司 | 一种应用的处理方法及相关装置 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8448059B1 (en) * | 1999-09-03 | 2013-05-21 | Cisco Technology, Inc. | Apparatus and method for providing browser audio control for voice enabled web applications |
US6859879B2 (en) * | 2000-05-26 | 2005-02-22 | International Business Machine Corporation | Method and system for secure pervasive access |
JP2003202929A (ja) * | 2002-01-08 | 2003-07-18 | Ntt Docomo Inc | 配信方法および配信システム |
US7664948B2 (en) * | 2004-05-21 | 2010-02-16 | Bea Systems, Inc. | Certificate lookup and validation |
CN100385852C (zh) * | 2004-06-22 | 2008-04-30 | 腾讯科技(深圳)有限公司 | 一种网页插件选择下载的实现方法及其装置 |
US8307291B2 (en) | 2004-08-11 | 2012-11-06 | American Express Travel Related Services Company, Inc. | Web page security system and method |
US7394377B2 (en) * | 2005-08-22 | 2008-07-01 | Bea Systems, Inc. | RFID edge server with security plug-ins |
WO2007097439A1 (ja) * | 2006-02-21 | 2007-08-30 | Nec Corporation | プログラムの実行制御システム、実行制御方法、実行制御用コンピュータプログラム |
WO2009039434A2 (en) * | 2007-09-21 | 2009-03-26 | Breach Security, Inc. | System and method for detecting security defects in applications |
US8180886B2 (en) * | 2007-11-15 | 2012-05-15 | Trustwave Holdings, Inc. | Method and apparatus for detection of information transmission abnormalities |
JP5078660B2 (ja) * | 2008-02-20 | 2012-11-21 | 株式会社リコー | 認証制御装置、認証制御方法及びプログラム |
US9081956B2 (en) * | 2008-05-26 | 2015-07-14 | Trusteer Ltd. | Remote DOM access |
US20100250903A1 (en) * | 2009-03-26 | 2010-09-30 | Celio Technology Corporation | Apparatuses and systems including a software application adaptation layer and methods of operating a data processing apparatus with a software adaptation layer |
US8601363B2 (en) * | 2009-07-20 | 2013-12-03 | Facebook, Inc. | Communicating information about a local machine to a browser application |
KR101092024B1 (ko) * | 2010-02-19 | 2011-12-12 | 박희정 | 웹 서비스의 실시간 취약성 진단 및 결과정보 제공 서비스 시스템 |
JP5523220B2 (ja) * | 2010-06-30 | 2014-06-18 | キヤノン株式会社 | 情報処理装置及びその制御方法、プログラム |
US8819768B1 (en) * | 2011-05-03 | 2014-08-26 | Robert Koeten | Split password vault |
-
2011
- 2011-08-26 JP JP2011184767A patent/JP5575071B2/ja not_active Expired - Fee Related
-
2012
- 2012-06-26 US US13/533,077 patent/US9317681B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US9317681B2 (en) | 2016-04-19 |
US20130055340A1 (en) | 2013-02-28 |
JP2013045400A (ja) | 2013-03-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5575071B2 (ja) | 情報処理装置、情報処理方法、およびプログラム | |
JP6797290B2 (ja) | メッセージングサービス向けのコンテンツ管理機能 | |
JP6376851B2 (ja) | 情報処理装置、情報処理装置の制御方法、及びプログラム | |
US9864736B2 (en) | Information processing apparatus, control method, and recording medium | |
KR102045602B1 (ko) | 애플리케이션 코드 실행이 없는 라이브 타일들 | |
JP2020501213A (ja) | カーネルイベントトリガ | |
JP2016529599A (ja) | コンテンツクリップボードの同期 | |
KR20150004877A (ko) | 네트워크 스토리지 서비스에서 어플리케이션과 파일타입의 관련 | |
US20140304313A1 (en) | Terminal and method for providing application-related data | |
US20150149411A1 (en) | Comparison of file system snapshots stored in a remote sorage system using a network file system command | |
US10855746B2 (en) | Generating content fragments for content distribution | |
JP2008146601A (ja) | 情報処理装置及び情報処理方法 | |
JP2017162506A (ja) | 対応するプライマリ・アプリケーションデータから導出される識別子に基づく補足データへのアクセス | |
JP7231518B2 (ja) | パッケージ化支援システムおよびパッケージ化支援方法 | |
US10466997B2 (en) | Apparatus and method for modifying application | |
CN105095785A (zh) | 分布式文件系统的文件访问处理、访问方法及装置 | |
JP4651690B2 (ja) | 家電ログインシステム | |
JP5867540B2 (ja) | プログラム生成装置、プログラム生成装置の制御方法、およびプログラム | |
CN103841178A (zh) | 网络附连存储环境的带内管理的方法和系统 | |
US10579374B2 (en) | Method for converting application and computing device | |
CN116126812B (zh) | 一种工程行业文件存储与集成的方法与系统 | |
JP4909432B2 (ja) | コンテンツマネジメントシステム | |
KR101973236B1 (ko) | 서버 기반 미디어 스캔을 위한 장치 및 방법 | |
KR20100069229A (ko) | 컨텐츠 바로가기 서비스 제공 시스템 및 방법 | |
JP2011164875A (ja) | ファイル同期装置、ファイル同期管理装置、ファイル同期方法、およびファイル同期管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130909 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20140428 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140603 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140701 |
|
LAPS | Cancellation because of no payment of annual fees |