Oracle® Mobile Application Framework Oracle Mobile Application Frameworkのインストール 2.4.1.0.0 E89896-01 |
|
前 |
この章の内容は次のとおりです。
このリリースのMAFに移行するお客様は、アプリケーションに影響する可能性のある、このリリースおよび以前のリリースのMAF (たとえば、MAF 2.3.0)での次の変更に注意する必要がある場合があります。
MAFでは、MAFアプリケーションを作成し、iOSプラットフォームにデプロイするのにXcode 8.3.xが必要になり、『Oracle Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のデバイスの署名およびエクスポート・オプションの設定に関する項の説明に示すように、「プリファレンス」ダイアログの「iOSプラットフォーム」ページの「メソッド」ドロップダウン・リストからエクスポート方法(非定型、App Store、開発、またはエンタープライズ)を選択する必要があります。「Xcode 8.3.xの使用およびMAF 2.4.1を使用したiOS 10へのデプロイ」の説明に示すように、異なるバージョンのMAF用に2つの別個の開発環境を維持する場合、2つの別個のXcodeのインストールを維持できることにも注意してください。
このリリースでの新機能の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』の「このガイドでのMAFリリース2.4.1の新機能」を参照してください。
以前のリリースのMAFでは、移行するアプリケーションに影響する可能性のある、次の変更が行われました。
MAF 2.4.0:
Gradleを使用して、MAFアプリケーションをビルドし、Androidプラットフォームにデプロイします。初めてMAFアプリケーションをAndroidにデプロイするときに、MAFはGradleをダウンロードしてインストールします。Gradleが正しくインストールされるよう、Gradleのプロキシ設定を構成する必要がある場合があります。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のGradleのプロキシ情報の構成に関する項を参照してください。
MAFが使用するCordovaエンジンのバージョン(Android: 6.0.0、iOS: 4.3.0、Windows: 4.4.3)が更新されました。そのため、「Cordovaプラグインの旧リリースからMAF 2.4.1への移行」の説明に従って、移行後のアプリケーションで使用するカスタムCordovaプラグインを更新する必要がある場合があります。
以前のリリースで非推奨のAPIが削除されました。このリリースにアップグレードする前に、ビルド時に報告された非推奨の警告を確認し、サポート対象のAPIを使用するようにアプリケーションを変更してください。これを行わない場合、このリリースへのアップグレード後、移行後のアプリケーションがビルドに失敗する場合があります。MAFがサポートするAPIの詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
AndroidプラットフォームにデプロイするMAFアプリケーションのHTTPSプロトコルがTLS 1.2
にデフォルト設定されました。お薦めはしませんが、「MAFリリース2.4.0以上でのセキュリティの変更」の説明に従って、このデフォルトの動作を上書きできます。
MAF 2.3.3以降では、MAFアプリケーションを開発してiOSプラットフォームにデプロイするためにXcode 8が必要です。また、iOS 10プラットフォーム上で稼働しているデバイスへのアプリケーションのデプロイメントもサポートしています。「Xcode 8.3.xの使用およびMAF 2.4.1を使用したiOS 10へのデプロイ」を参照してください。
MAF 2.3.2以降:
移行したMAFアプリケーションのjava.security
ファイルを、MAFで生成した新バージョンのファイルで置き換えます。MAFでは、元のファイルがjava.security.orig
というファイル名で保存されます。以前にこのファイルに対して変更を加えていた場合、その変更内容を新バージョンのjava.security
ファイルにコピーする必要がある場合があります。
iOS 9で実行される移行済のアプリケーションは、WKWebViewを使用するように構成できます(「iOS 9およびiOS 10でWKWebViewを使用する場合のAMXコンテンツを含むアプリケーション機能の構成」を参照)。
MAF 2.3.1以降では、RESTサービスにオフラインの読取りおよび書込みサポートを提供するクライアント・データ・モデル機能が含まれています。以前にA-Team Mobile Persistence Accelerator (AMPA)拡張機能を使用して、これらの機能を持つアプリケーションを開発している場合は、「AMPAを使用して開発されたアプリケーションのMAF 2.4.1への移行」の説明に従って、このリリースのMAFにそのアプリケーションを移行できます。
MAF 2.3.0以降では、新しいバージョンのCordova (4.x)が使用されます。移行されたMAFアプリケーションでサード・パーティ製のCordovaプラグインを使用している場合は、そのプラグインにこのリリースのMAFで使用されるAndroidおよびiOSバージョンのCordovaとの互換性があることを確認してください。「Cordovaプラグインの旧リリースからMAF 2.4.1への移行」を参照してください。
RestServiceAdapter
インタフェースでは、新しいパッケージの場所(oracle.maf.api.dc.ws.rest
)が使用されています。このインタフェースで指定される機能は変わりません。REST Webサービス・アダプタの作成の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のWebサービスにアクセスするためのRestサービス・アダプタの作成に関する項を参照してください。
MAF 2.3.0では、以前のリリースで非推奨になった次の機能のサポートが削除されています。
Mobile-Social認証サーバー・タイプ。MAFでサポートされる、OAuthなどの別の認証タイプを使用することをお薦めします。
SOAP Webサービス。REST WebサービスとJSONオブジェクトを使用することをお薦めします。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のMAFアプリケーションでのWebサービスの使用に関する項を参照してください。
MAF 2.3.0以降、MAFにはjQuery JavaScriptライブラリがバンドルされなくなりました。これは、AMXページまたはコンポーネントで使用されなくなりました。jQuery JavaScriptライブラリを使用する必要があるお客様は、機能インクルードを使用して明示的にjQueryを含める必要があります。
MAF 2.3.0リリースでは、ユニバーサルWindowsプラットフォーム(UWP)へのMAFアプリケーションのデプロイメントがサポートされるようになりました。移行後のMAFアプリケーションに、MAFアプリケーションが特定のプラットフォームで実行されている場合にのみ実行されるプラットフォーム固有のコードが含まれている場合、この新しくサポートされるプラットフォームでそのMAFアプリケーションを実行するには、UWP用のプラットフォーム固有コードを含めるようにMAFアプリケーションを修正してください。UWPへのMAFアプリケーションのデプロイの詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のユニバーサルWindowsプラットフォームへのMAFアプリケーションのデプロイに関する項を参照してください。
MAFでは、このリリースに移行するアプリケーションのアプリケーション・トランスポート・セキュリティ(ATS)がデフォルトで有効になります。「MAFリリース2.2.1以上でのセキュリティの変更」を参照してください。移行対象のアプリケーションがURLスキームを使用して他のアプリケーションを起動する場合は、「カスタムURLスキームを使用して他のアプリケーションを起動するMAFアプリケーションの移行」の説明に従って移行対象アプリケーションを構成します。
MAF 2.1.0リリースには大幅な変更が導入されており、それもこの章で説明しています。この章の情報は、MAF 2.1.0より前のリリースで作成したアプリケーションをMAF 2.3.0に移行する場合に使用します。
MAF 2.1.0では、新しいバージョンのApache CordovaとJavaが使用されていました。また、JDeveloperによるMAFアプリケーションへのCordovaプラグインの登録方法も変更されました。SSL用には、新しいCAルート証明書が含まれているcacerts
ファイルが提供されていました。
MAF 2.1.0で作成されたアプリケーションまたは以前にMAF 2.1.0に移行したアプリケーションをMAF 2.3.0に移行する場合、MAFでは、JDK 8への移行、Cordovaプラグインの管理、および新しいcacerts
ファイルに必要な変更は事前に行われます。
この章の後続の項では、これらの変更がMAFアプリケーションのMAF 2.1.0以降への移行にどのような影響を与えるかについて説明しているので、参照してください。
また、MAF 2.1.0ではSQLiteデータベースとJDBCドライバが更新されていました。移行対象のMAFアプリケーションで、SQLiteデータベースに接続するコードを確認し、必要に応じて移行してください。SQLiteデータベースへの接続方法の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のローカルSQLiteデータベースの使用方法に関する項を参照してください。
このリリースのMAFを提供するMAF拡張機能をインストールした後、JDeveloperでMAFアプリケーションを閉じて、再度開きます。これにより、MAFアプリケーションを現在のリリースのMAFに移行するマイグレータを起動します。MAFアプリケーションをこのリリースに移行したら、JDeveloperの「すべてクリーン」コマンドを起動します。こうすることで、このリリースに移行する前に、ビルド・アーティファクトのアプリケーションがビルドから消去されます。これを行うには、JDeveloperのメイン・メニューで「ビルド」→「すべてクリーン」をクリックします。
MAF 2.4.1以降では、MAFアプリケーションを開発してiOSプラットフォームにデプロイするためにXcode 8.3.xが必要です。
このリリース(MAF 2.4.1)では、MAFは新しい「メソッド」ドロップダウンを表示し、そこでMAFアプリケーションのアーカイブをパッケージ化してiOSデバイスにデプロイするためにエクスポートするときにXcodeが使用する配布方法(非定型、App Store、開発、またはエンタープライズ)を選択する必要があります。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のデバイスの署名およびエクスポート・オプションの設定に関する項を参照してください。
MAF 2.4.1より前では、Xcode 8の使用とiOS 10へのデプロイメントをサポートするために、次に示す追加の変更が行われました。この情報を確認し、移行済のMAFアプリケーションを適切に変更して、デプロイメントが正しく実行されるようにします。
開発チームの識別子を表示する、新しい入力フィールド(「チーム」)が公開されました。MAFは、このフィールドにプロビジョニング・プロファイルから抽出した値を自動的に移入します。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のデバイスの署名およびエクスポート・オプションの設定に関する項を参照してください。
「iOS用MAFのデプロイメント・プロファイルのプロパティ」ダイアログの「iOSオプション」ページに、プッシュ通知環境ドロップダウン・リストが表示されるようになりました。このドロップダウン・リストでは、Production
またはDevelopment
を選択して、デプロイ済アプリケーションをApple Push Notification Service (APNs)に登録する必要があります(デプロイ済アプリケーションがプッシュ通知をサポートしている場合)。デフォルト値はProduction
です。このリリースに移行するMAFアプリケーションには、デフォルト値を使用してください。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のiOSのビルド・オプションの定義に関する項およびプッシュ通知の有効化に関する項を参照してください。
iOS 10にデプロイされるMAFアプリケーションは、そのアプリケーションがユーザーのプライベート・データにアクセスする可能性のあるデバイス機能(カメラなど)を使用する場合、使用方法の説明が必要になります。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のiOSのデバイス機能にアクセスするプラグインの使用方法の説明の提供に関する項を参照してください。
MAF 2.4.0以降、MAFは、AndroidプラットフォームにデプロイするMAFアプリケーションのHTTPSプロトコルをTLS 1.2
にデフォルト設定します。
サポート対象のプラットフォームでは、TLS 1.1
を使用するようにアプリケーションのJava VMレイヤーを構成する次の例に示すように、maf.properties
ファイルで代わりの値をJavaのコマンド行の引数に指定して、この動作を上書きできます。
// Configure Java VM layer of the MAF app to use TLSv1.1 java.commandline.argument=-Dhttps.protocols=TLSv1.1 // Configure the HTTPS cipher suite(s) that an application uses by // providing a comma-separated list as a value java.commandline.argument=-Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA
Androidのバージョンがレガシー・プロトコルをサポートしている場合、Androidの認証機構はmaf.properties
ファイルのプロパティを尊重します。たとえば、Android 7以降を実行しているデバイスは、TLS 1
をサポートせず、RC4ベースの暗号化スイートを無効化します。
iOSおよびユニバーサルWindowsプラットフォームでは、maf.properties
ファイルでこれらのプロパティを指定しても、アプリケーションの認証機構は変更されません。これはプラットフォーム自体で管理されます。ただし、REST呼び出しなどのアプリケーション・コードはこれらのプロパティによる影響を受けることがあります。
アプリケーションのデフォルトのMAFの動作を維持することをお薦めします。そうしない場合、アプリケーションがセキュリティ上の危険にさらされることがあります。古いバージョンのSSLまたは非推奨の暗号化スイートを使用するサーバーでアプリケーションをテストする必要がある場合、ここでの説明に従って、デフォルトの動作を上書きしてください。
MAF 2.4.0以降では、新しいバージョンのCordovaが使用されます。各ターゲット・プラットフォームが使用するバージョンについては、maf-application.xml
ファイルの概要エディタの、Cordovaエンジンのバージョンの項を参照してください。
移行を完了して、移行済のMAFアプリケーションで以前使用していたプラグインを確実に使用できるようにするには、このリリースのMAFでそのバージョンのプラグインがサポートされていることを確認します。「Cordovaエンジンのバージョン」に、ご使用のリリースのMAFで使用されるバージョンが表示されます(図3-1を参照)。現在のMAFリリースで使用されるものよりも古いリリースのCordovaを使用してプラグインが作成されている場合は、新しいバージョンのプラグインを取得してください。MAFアプリケーションのmaf-plugins.xml
ファイルがプラグインを正しく参照するように、プラグインへの相対パスを設定します。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のMAFアプリケーションへの追加のプラグインの登録に関する項を参照してください。maf-plugins.xml
ファイルで、相対パスを使用してプラグインを正しく参照していない場合、maf-application.xml
ファイルの概要エディタで必須入力フィールドのパス*が空になり、maf-plugins.xml
に検証失敗が表示されます(図3-1を参照)。
以前のリリースのMAF (MAF 2.1.0より前)を使用して開発されたMAFアプリケーションでは、maf-application
ファイルにプラグインが登録されていました。MAF 2.1.0以降のリリースでは、maf-plugins.xml
ファイルにプラグインを登録します。アプリケーションの移行時に、JDeveloperでは、プラグインを使用している以前のリリースのアプリケーションに次の変更を加えます。
maf-application.xml
ファイル内でプラグインを参照していたエントリをコメント・アウトします。たとえば、JDeveloperではエントリを次のようにコメント・アウトします。
<!--<adfmf:cordovaPlugins> <adfmf:plugin fullyQualifiedName="BarcodeScanner" implementationClass="com.phonegap.plugins. barcodescanner.BarcodeScanner" platform="Android" name="BarcodeScanner"> ..... </adfmf:cordovaPlugins>-->
次の例に示すように、maf-plugins.xml
ファイルにプラグインを登録します。
<cordova-plugins> ... <cordova-plugin id="c3" pluginId="org.apache.cordova.barcodeScanner"> <platform id="p3" name="ios" enabled="true"/> <platform id="p4" name="android" enabled="false"/> </cordova-plugin> </cordova-plugins>
図3-1 プラグインへのパスが指定されていないMAFアプリケーション
MAFアプリケーションをiOS 9デバイスにデプロイした場合、MAF 2.3.3のリリース以降のMAFを使用して作成した新しいMAFアプリケーションは、デフォルトでWKWebViewを使用してAMXコンテンツ・タイプをレンダリングします。今回のリリースのMAFに移行したMAFアプリケーションでは、このWebビューの使用を選択できます。
新しいWKWebViewでは、UIWebViewと比較すると、パフォーマンスが改善されています。
次の例は、移行済MAFアプリケーションにAMXコンテンツを含むアプリケーション機能を構成し、新しいWKWebViewを使用する方法を示します。UIWebViewの使用に戻すには、value
属性をlegacy
に設定します。WKWebViewを使用する、AMXコンテンツを含むアプリケーション機能ごとにmaf-features.xml
ファイルでこれらのプロパティを構成します。
<adfmf:feature id="WKWebViewExample" name="WKWebViewExample"> <adfmf:constraints> <adfmf:constraint property="device.os" operator="contains" value="iOS" id="c6"/> </adfmf:constraints> <adfmf:content id="WKWebViewExample.1"> <adfmf:amx file="WKWebViewExample/home.amx"/> </adfmf:content> <adfmf:properties id="wkp1"> <adfmf:property id="wkp1-1" name="iOSWebView" value="modern" /> <!-- To revert to using UIWebView, set to legacy --> <!-- name="iOSWebView" value="legacy" --> </adfmf:properties> </adfmf:feature>
このWebビューでは、JavaScript APIにアクセスするための仮想パス/~maf.device~/
をサポートしているので、ローカルHTMLまたはリモートURLコンテンツ・タイプを使用するアプリケーション機能では、引き続きUIWebViewが使用されます。
iOSWebView
プロパティが不足しているかdefault
に設定されている場合は、AMXコンテンツにはWKWebViewが使用され、ローカルHTMLおよびリモートURLコンテンツ・タイプにはUIWebViewが使用されます。/~maf.device~/
仮想パスを使用する必要がない場合、この値をmodern
に設定すると、ローカルHTMLおよびリモートURLコンテンツ・タイプ用にWKWebViewを使用することを選択できます。
WKWebViewは、iOS 9+でのみ使用されます。UIWebViewは、常にiOS 8上で使用されます。
A-Team Mobile Persistence Accelerator (AMPA)拡張機能および以前のリリースのMAFを使用して開発されたアプリケーションをこのリリースのMAFに移行する方法について説明します。
MAF 2.3.1以降には、MAFのクライアント・データ・モデル機能の一部として、永続性およびデータ同期化フレームワークであるAMPAが組み込まれています。アプリケーション開発者は、MAFクライアント・データ・モデルのデザインタイムおよびランタイム機能を使用して新しいMAFアプリケーションを開発して、アプリケーションのデータ・モデルを生成し、エンド・ユーザーのデバイスで永続化するデータ・オブジェクトを決定し、生成されたクライアント・データ・モデルのサービス・オブジェクトから作成されるデータ・コントロールから完全なユーザー・インタフェースを生成できます。『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のMAFアプリケーションでのクライアント・データ・モデルの作成に関する項を参照してください。
次のタスクを実行することで、AMPA拡張機能および以前のリリースのMAFを使用して開発されたアプリケーションをこのリリースのMAFに移行できます。
persistence-mapping.xml
ファイルでネームスペースを変更する
maf-application.xml
ファイルでライフサイクル・リスナーを変更する
MAFクライアント・データ・モデルのパッケージ名を使用するようにAMPAクラスのパッケージ名を変更する
persistence-mapping.xmlファイルでネームスペースを変更する
次の例に示すように、MAFクライアント・データ・モデル値を使用するようにpersistence-mapping.xml
ファイルでネームスペースを変更します。
<mobileObjectPersistence xmlns="http://xmlns.oracle.com/adf/mf/amx/cdm/persistenceMapping" ...
persistence-mapping.xml
ファイルは、移行したアプリケーションのApplicationControllerプロジェクトの次のディレクトリにあります。
/ApplicationController/src/META-INF
maf-application.xmlファイルでライフサイクル・リスナーを変更する
maf-application.xml
ファイルでlistener-class
属性の値を、oracle.ateam.sample.mobile.lifecycle.InitDBLifeCycleListener
から次の例に示すMAFクライアント・データ・モデル値に変更します。
<adfmf:application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:adfmf="http://xmlns.oracle.com/adf/mf" ... listener-class="oracle.maf.impl.cdm.lifecycle.InitDBLifeCycleListener">
maf-application.xml
ファイルは、移行したアプリケーションの次のディレクトリにあります。
./.adf/META-INF/maf-application.xml
MAFクライアント・データ・モデルのパッケージ名にAMPAパッケージ名を変更する
移行したアプリケーションでのJavaクラスのパッケージ名を、MAFクライアント・データ・モデルで使用されるパッケージ名に変更します。AMPAパッケージとMAFクライアント・データ・モデル・パッケージとの対応は次のとおりです。
oracle.ateam.sample.mobile -----> oracle.maf.impl.cdm oracle.ateam.sample.mobile.v2.security -----> oracle.maf.impl.cdm.security oracle.ateam.sample.mobile.v2.persistence -----> oracle.maf.impl.cdm.persistence
たとえば、このリリースのMAFに移行するAMPAアプリケーションにoracle.ateam.sample.mobile.mcs.analytics.AnalyticsEvent
をインポートするJavaクラスが含まれている場合、移行したアプリケーションでそのJavaクラスをoracle.maf.impl.cdm.mcs.analytics.AnalyticsEvent
をインポートするように変更します。
注意:
oracle.maf.impl.cdm
パッケージのクラスはMAFクライアント・データ・モデルの内部クラスで、変更される可能性があります。これらのクラスは、MAFの以降のリリースでリファクタされる可能性がありますが、現時点では、これらのクラスを拡張しないことをお薦めします。 oracle.maf.api.cdm...
パッケージのすべてのクラスは、拡張できる公開クラスです。たとえば、このリリースのMAFに移行するAMPAアプリケーションにoracle.ateam.sample.mobile.mcs.storage.StorageObject
をインポートするJavaクラスが含まれている場合、そのJavaクラスをoracle.maf.api.cdm.mcs.storage.StorageObject
をインポートするように変更します。
次のリストに、oracle.maf.api.cdm
パッケージの公開クラスを示します。
controller.bean.ConnectivityBean exception.RestCallException mcs.storage.StorageObject mcs.storage.StorageObjectService persistence.cache.EntityCache persistence.db.BindParamInfo persistence.manager.DBPersistenceManager persistence.manager.MCSPersistenceManager persistence.manager.RestJSONPersistenceManager persistence.manager.RestXMLPersistenceManager persistence.metadata.AttributeMapping persistence.metadata.AttributeMappingDirect persistence.metadata.AttributeMappingOneToMany persistence.metadata.AttributeMappingOneToOne persistence.metadata.ClassMappingDescriptor persistence.model.Entity persistence.service.DataSynchAction persistence.service.DataSynchService persistence.service.ValueHolderInterface persistence.util.EntityUtils
前述のリストの公開クラスについてAMPAでのパッケージ名を確認し、MAFクライアント・データ・モデルでのパッケージ名を使用するように変更するために、Javaリファレンス・ドキュメントでAMPAフレームワークを参照してください。MAFの公開クラスの詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
MAFクライアント・データ・モデルに実装されている、その他の変更については、前述のリファレンス・ドキュメントも参照してください。このドキュメントにはAMPAも含まれています。たとえば、AMPAと拡張クラス参照定数(SQL_SELECT_KEYWORD
など)を使用して開発されたアプリケーションでDBPersistenceManager
を拡張した場合は、これらの定数がDBPersistenceManager
のMAFクライアント・データ・モデルの実装で提供されなくなるため、拡張クラスで独自の定数を指定する必要があります。
移行したアプリケーションおよびpageDefinition.xml
ファイルで、AMPAパッケージ名を使用してJavaマネージドBeanを参照するすべてのJavaクラスに対し前述の変更を行います。
前述の変更の他に、移行するアプリケーションがサポートされているクラスおよびメソッドを使用していることを確認してください。たとえば、AMPAの最新リリースではoracle.ateam.sample.mobile.util.MCSManager
が非推奨になっています。このリリースのMAFに移行し、AMPA非推奨のMCSManager
を使用するすべてのアプリケーションを、oracle.maf.api.cdm.persistence.manager.MCSPersistenceManager
を使用するように変更する必要があります。
MAF 2.2.0以前からMAF 2.3.0以降にアプリケーションを移行する場合は、移行されたアプリケーションの構成を変更して、アプリケーションがこのリリースのMAFでサポートされる最新のセキュリティ標準に準拠するようにする必要があります。
MAF 2.2.1以降、iOS上のMAFアプリケーションからサーバーへのすべての接続では、TLS 1.2のHTTPSを使用することが必要です。非HTTPS接続およびTLS1.2未満のSSLバージョンを使用するすべてのMAFアプリケーションは、iOSでは実行できません。MAFは、Apple iOS 9の要件を満たすためにこの動作を行い、TLS 1.2のHTTPSの使用が必要なアプリケーション・トランスポート・セキュリティ(ATS)を使用します。次の説明に従って、ATSの使用を無効にすることもできます。
また、MAFアプリケーションは、Java 8のJVMによって実施されるデフォルトの動作に従って、最新のSSLバージョンと暗号化スイートを使用します。このような新しいバージョンを使用するためにサーバーのアップグレードをお薦めします。ただし、次の説明に従ってMAFアプリケーションを構成すると、古いSSLバージョンでサーバーを使用した際に発生する可能性があるSSLエラーを回避することができます。
iOSデバイス上のMAFアプリケーションでのアプリケーション・トランスポート・セキュリティの無効化
このリリースのMAFに移行するMAFアプリケーションでは、ATSがデフォルトで有効になります。MAFアプリケーションのATSを次のように無効化できます。
JDeveloperで、「アプリケーション」→「アプリケーション・プロパティ」→「デプロイメント」を選択します。
「デプロイメント」ページで、iOSデプロイメント・プロファイルをダブルクリックします。
「iOSオプション」を選択します。
「アプリケーション・トランスポート・セキュリティの無効化」を選択して「OK」をクリックします。
注意:
ATSを無効にしないことをお薦めします。Appleでは、2017年1月1日からATSの使用を強制する予定です。ATSを無効にするMAFアプリケーションは、Apple App Storeによる公開を承認されません。SSL構成の変更
TLS 1.2未満のSSLバージョン、非推奨の暗号化スイートまたは非推奨の暗号化アルゴリズムを使用するユーザーには、「invalid cipher suite」
、「close notify」
、「TLS error」
などのSSLエラーが表示されます。Java 8では、最新のSSLバージョンと暗号化スイートの使用が実施されます。セキュアでないSSLバージョンの使用はデフォルトで無効化されています。新しいSSLバージョンを使用するためにサーバーの更新をお薦めします。これができない場合は、前述したSSLエラーを回避するために次の構成を使用します。
使用するSSLバージョンを含むようにmaf.properties
ファイルを更新します。たとえば、TLS 1を使用するには次のエントリをmaf.properties
ファイルに追加します。
java.commandline.argument=-Dhttps.protocols=TLSv1
アプリケーションで必要なすべての暗号化スイートのリストを指定してmaf.properties
ファイルを更新します。Javaでサポートされる暗号化スイートのリストは、このページの暗号化スイートに関する項を参照してください。
たとえば、SSL_RSA_WITH_RC4_128_MD5
を有効にするには、次を追加します。
java.commandline.argument=-D SSL_RSA_WITH_RC4_128_MD5
非推奨のアルゴリズムを有効化するようにjava.security
ファイルを更新します。既存のMAFアプリケーションにこのファイルを含めることはできないため、新しい空のMAFアプリケーションを作成し、新しいMAFアプリケーションの/resources/security
に作成されたjava.security
ファイルを、既存のアプリケーションの同じディレクトリにコピーします。
たとえば、RC4アルゴリズムは、java.security
ファイルの次のエントリに基づいてデフォルトで無効になっています。
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768
RC4アルゴリズムを必要とする暗号化スイート(SSL_RSA_WITH_RC4_128_MD5
など)を使用すると、実行時にSSL接続を確立する際にエラーがスローされます。これを回避するため、java.security
エントリを次のように変更してRC4アルゴリズムを有効にします。
jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768
MAF 2.2.2以降に移行するアプリケーションが、カスタムURLスキームを使用して別のアプリケーションを起動する場合は、maf-application.xml
ファイルの概要エディタの「セキュリティ」ページで「許可されるスキーム」リストにスキームを追加します。
この変更点は、アプリケーションが他のアプリケーションの起動に使用するURLスキームを宣言するというiOS 9の要件に対応しています。図3-2に示すように、「セキュリティ」ページの「許可されるスキーム」セクションの「追加」アイコンをクリックして、カスタムURLスキームを追加します。
図3-2 MAFアプリケーションが別のアプリケーションの起動に使用するカスタムURLスキームの登録
MAF 2.1.0以降で作成するMAFアプリケーションは、JDK 8を使用します。以前のバージョンのJavaを使用してコンパイルされたMAFアプリケーションを移行する場合、MAF 2.1.0以降ではJDK 8が必要なことと、Java SE Embedded 8 Compact2プロファイルを使用してアプリケーションがコンパイルされることに注意してください。
MAF 2.1.0より前のリリースから移行したアプリケーションを初めて開くときに、JDeveloperでは次の変更が行われます。
JVMの起動パラメータを指定する構成ファイルの名前をcvm.properties
からmaf.properties
に変更します。maf.properties
ファイルの詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のJavaコードおよびJavaScriptのデバッグを有効にする方法に関する項を参照してください。
アプリケーションのJavaソース・ファイルに記載された次のimport文のインスタンスを置き換えます(存在する場合)。
com.sun.util.logging
次に置き換えます。
java.util.logging
アプリケーションのlogging.properties
ファイルに記載された次のエントリを置き換えます。
.handlers=com.sun.util.logging.ConsoleHandler .formatter=com.sun.util.logging.SimpleFormatter
次に置き換えます。
.handlers=java.util.logging.ConsoleHandler .formatter=java.util.logging.SimpleFormatter
logging.properties
ファイルの詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のプロパティ・ファイルを使用したロギングの構成方法に関する項を参照してください。
MAF 2.2.0では、このリリースを使用して作成されたMAFアプリケーションがAndroidシステムの戻るボタンの使用に応答する方法が変更されました。前のリリースで作成し、MAF 2.2.0以降に移行したMAFアプリケーションでは、新しい動作が使用されます。
図3-3に、エンド・ユーザーが3つのアプリケーション機能(Customer、SalesおよびBilling)間でBillingアプリケーション機能のBilling Page 3ページにナビゲートした場合のMAFアプリケーションのナビゲーション・フローを示します。
図3-3 MAFアプリケーションのアプリケーション機能とページ間のナビゲーション・フロー
リリースMAF 2.2.0より前では、エンド・ユーザーがAndroidシステムの戻るボタンをタップした場合のMAFアプリケーションのデフォルト動作は次のとおりでした。
Billing Page 3はSalesアプリケーション機能にナビゲートする
Salesアプリケーション機能はCustomersアプリケーション機能にナビゲートする
CustomerアプリケーションはMAFアプリケーションを終了する
MAF 2.2.0以降では、エンド・ユーザーがAndroidシステムの戻るボタンをタップした場合のMAFアプリケーションのデフォルト動作は次のとおりです。
「Billing Page 3」は「Billing Page 2」にナビゲート
「Billing Page 2」は「Billing Page 1」にナビゲート
「Billing Page 1」はMAFアプリケーションを休止
『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のAndroidの戻るボタンを使用したMAFアプリケーションのナビゲートに関する項の説明に従って、エンド・ユーザーがAndroidシステムの戻るボタンをタップした場合のMAFアプリケーションの動作をカスタマイズできます。
「Androidの戻るボタンの使用に対してMAF 2.2.0より前のアプリケーションの動作を維持する方法」の説明に従ってmaf-config.xml
でプロパティを設定することで、MAF 2.2.0より前のアプリケーションの動作(アプリケーション機能間のナビゲート)を示すようにMAFアプリケーションを構成することもできます。
maf-config.xml
ファイルのlegacyBack
要素を構成して、エンド・ユーザーがAndroidの戻るボタンをタップしたときにMAFアプリケーションがMAF 2.2.0より前の動作を示すようにすることができます。
例3-1 Androidの戻るボタンの使用に対してMAF 2.2.0より前のアプリケーションの動作を維持するためのlegacyBack要素
<?xml version="1.0" encoding="UTF-8" ?> <adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config"> ... <legacyBack>true</legacyBack> </adfmf-config>
MAF 2.1.0は、MAFアプリケーションで使用する新しいcacerts
ファイルを提供しました。エンド・ユーザーのインストール用に公開するアプリケーションにパッケージ化されたcacerts
ファイルに、エンド・ユーザーがMAFアプリケーションの使用時に接続するHTTPSサーバーと同じCAルート証明書が含まれていることを確認します。
MAFアプリケーションのcacerts
ファイルにない証明書がHTTPSサーバーに含まれている場合、MAFアプリケーションのcacerts
ファイルに新しい証明書をインポートする必要があります。同様に、HTTPSサーバーにない証明書がMAFアプリケーションで使用されている場合、MAFアプリケーションが接続するHTTPSサーバーのシステム管理者は、新しい証明書をインポートする必要があります。
JDK 8のkeytool
ユーティリティを使用すると、MAFアプリケーションのcacerts
ファイル内の証明書を表示および管理できます。次の例は、JDK 8のkeytool
ユーティリティを使用してcacerts
ファイル内の証明書リストを表示する方法を示しています。
JDK8install
/bin/keytool -list -v -keystore
dirPathToCacertsFile
/cacerts –storepass changeit | grep "Issuer:"
JDK 8のkeytool
ユーティリティを使用して証明書を管理する方法の詳細は、http://docs.oracle.com/javase/8/docs/technotes/tools/#security
を参照してください。たとえば、Windowsでkeytool
ユーティリティを使用する場合は、http://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html
を参照してください。UNIXベースのオペレーティング・システムの場合は、http://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
を参照してください。
cacerts
ファイルについて、およびSSLを使用してMAFアプリケーションを保護する方法の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のSSLのサポートに関する項を参照してください。
例3-2に、MAF 2.1.0のcacerts
ファイルに含まれているCAルート証明書の発行者を示します。このファイル内の証明書を管理してMAFアプリケーションの使用環境の要件を満たすには、前述のJDK 8のkeytool
ユーティリティを使用します。
例3-2 MAF 2.1.0用cacertsファイル内のCAルート証明書の発行者
Issuer: CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US Issuer: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE Issuer: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH Issuer: CN=SwissSign Silver CA - G2, O=SwissSign AG, C=CH Issuer: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Issuer: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US Issuer: CN=SecureTrust CA, O=SecureTrust Corporation, C=US Issuer: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA Issuer: CN=AffirmTrust Networking, O=AffirmTrust, C=US Issuer: CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US Issuer: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE Issuer: CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US Issuer: CN=QuoVadis Root CA 3, O=QuoVadis Limited, C=BM Issuer: CN=QuoVadis Root CA 2, O=QuoVadis Limited, C=BM Issuer: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US Issuer: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network Issuer: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US Issuer: CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Issuer: CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Issuer: CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US Issuer: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE Issuer: CN=Buypass Class 3 Root CA, O=Buypass AS-983163327, C=NO Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US Issuer: CN=Buypass Class 2 Root CA, O=Buypass AS-983163327, C=NO Issuer: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE Issuer: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Issuer: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE Issuer: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US Issuer: CN=Class 3P Primary CA, O=Certplus, C=FR Issuer: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 Issuer: CN=UTN - DATACorp SGC, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: OU=Security Communication RootCA2, O="SECOM Trust Systems CO.,LTD.", C=JP Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US Issuer: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP Issuer: CN=AffirmTrust Commercial, O=AffirmTrust, C=US Issuer: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE Issuer: CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 Issuer: CN=Class 2 Primary CA, O=Certplus, C=FR Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US Issuer: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Issuer: CN=Starfield Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US Issuer: CN=Sonera Class2 CA, O=Sonera, C=FI Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA Issuer: CN=Sonera Class1 CA, O=Sonera, C=FI Issuer: CN=QuoVadis Root Certification Authority, OU=Root Certification Authority, O=QuoVadis Limited, C=BM Issuer: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US Issuer: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US Issuer: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB Issuer: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR Issuer: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US Issuer: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Issuer: CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US Issuer: CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US Issuer: CN=SwissSign Gold CA - G2, O=SwissSign AG, C=CH Issuer: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net Issuer: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd.", C=TW Issuer: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU Issuer: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US Issuer: CN=AffirmTrust Premium, O=AffirmTrust, C=US Issuer: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US