5 Oracle REST Data Servicesのその他の構成オプション
この項では、リクエストをルーティングして複数のデータベースに接続するようにOracle REST Data Servicesを構成する方法を説明し、その他の構成情報については、その他のドキュメント・ソースを参照します。
ノート:
構成の変更後、Oracle REST Data Servicesを再起動する必要があります。高可用性を確保するために、複数のORDSインスタンスの前にロード・バランサを使用して、ローリング再起動を実行できるようにすることをお薦めします。トピック:
5.1 MySQL DatabaseでのREST対応SQLサービスの使用
独自のORDSインスタンスを設定して、JDBC上のMySQLデータベースでREST対応SQLサービスを使用できます。接続の詳細は、他のORDS接続プールに指定する方法と同じように指定されます。MySQL JDBC接続の場合、db.connectionType
は常にcustomurl
です。db.customURL
プロパティは、データベースの有効なJDBC接続文字列である必要があります。データベースを実行しているホスト・マシンは、ORDSインスタンスが実行されているホスト・マシンからアクセスできる必要があります。使用するMySQLデータベース・アカウントは、ORDSインスタンスが実行されているホスト・マシンからのログインを許可するように構成する必要があります。ORDSは、MySQLデータ・サービスやMySQLサーバーを実行するOracle Computeインスタンスなど、OracleがホストするMySQLデータベース・サーバーへの接続をサポートします。
5.1.1 データベース資格証明のソース設定の理解
db.credentials
ソース構成プロパティを使用して指定されます。使用可能な値は、POOL
(デフォルト値)またはREQUEST
です。
ノート:
REST対応SQLサービスにアクセスするには、クライアントがORDS SQL開発者ロールを持っている必要がありますPOOL
を使用すると、プール構成の資格証明がリクエスト内のSQL文の処理に使用されます。ただし、クライアントはアイデンティティ管理システムの資格証明を指定して、それらを認可し、SQL開発者ロールを割り当てる必要があります。そうして初めて、クライアントはREST対応SQLサービスにアクセスできます。
値がREQUEST
に設定されている場合、プール構成で指定されたユーザー名とパスワードは引き続き必要です。ただし、これらの資格証明は、プールが初めて使用されるときに、プール内の接続の詳細を検証するためにのみ使用されます。基本認可ヘッダーのユーザー名とパスワードは、ターゲット・データベースとの新しいJDBC接続を確立するために使用されます。接続が確立されると、クライアントはSQL開発者ロールを持つとみなされます。これにより、REST対応SQLサービスの起動が認可されます。新しいJDBC接続は、リクエスト・ライフサイクル中に使用され、その後閉じられます。
5.1.2 MySQLデータベースのプールの構成
MySQLデータベースでORDSを使用するには、プール構成が必要です。プールは、ORDSコマンドライン・インタフェースを使用して構成できます。
顧客管理環境で実行されているOracle REST Data Services (ORDS)でMySQLデータベースを使用できるようにORDSを構成する必要があります。顧客管理対象環境のためにOracle REST Data Servicesをインストールする場所に応じて、次のいずれかを実行します。
-
Oracle REST Data Servicesの顧客管理対象環境がOracle Cloud Infrastructureで実行されている場合、Oracle YUMリポジトリを使用して、ORDSのYUMインストールを実行します。
-
Oracle REST Data Servicesの顧客管理対象環境が他の環境で実行されている場合、Oracle REST Data Servicesのダウンロード・ページからORDSをダウンロードします。
ORDSをMySQLデータベースで使用するためにデータベースへのインストールは必要ではなく、プールの構成のみが必要です。プールは、ORDSコマンドライン・インタフェースを使用して構成できます。
MySQLデータベースのプールを構成するには、次のステップを実行します。
ノート:
リクエスト内の資格証明は、SQL文の実行に使用されます。MySQLデータベースに指定されたdb.username
は、接続を作成するためのすべての権限を持つユーザーで、プール構成の詳細全体を検証するために使用されます。
ords config --db-pool mysql set db.connectionType customurl
ords config --db-pool mysql set db.customURL "jdbc:mysql://10.0.1.23/?sslMode=REQUIRED"
ords config --db-pool mysql set db.username user_only_has_permission_to_connect_and_nothing_more
ords config --db-pool mysql set db.credentialsSource request
ords config --db-pool mysql set restEnabledSql.active true
ords config --db-pool mysql secret db.password
- JDBCドライバに関連するプロパティは、
db.customURL
プロパティで指定できます。前述の例では、db.customURL
値sslMode
は、ORDSとMySQLサーバー間のセキュアな接続を確保するために、デフォルト値PREFERRED
ではなくREQUIRED
に設定されています。 - データベース・プールは
mysql
と呼ばれます。ただし、プールには任意の名前を付けることができます。デフォルト・プールは、MySQL接続プールとして構成できます。使用する必要がある数のMySQLデータベースに対して複数のプールを定義できます。 - 指定された
db.username
は、接続を作成するための十分な権限を持つMySQLデータベース・ユーザーです。このデータベースアカウントは、プール構成全体の詳細を確認するために使用されます。
5.1.2.1 サポートされているコンテナのORDSの構成
構成場所の指定
ords serve
コマンドを使用してスタンドアロン・モードでORDSを実行する場合、構成ディレクトリの場所を指定するオプションがあります。ords.war
をApache TomcatやWebLogic Serverなどのサポートされているコンテナにデプロイする場合は、config.url
システム・プロパティを設定して構成ディレクトリの場所を指定する必要があります。これを実行するメカニズムは、コンテナ製品によって異なります。
-
Apache Tomcatを起動する前に
config.url
システム・プロパティを設定するには、次のコマンドを実行します。export JAVA_OPTS="-Dconfig.url=/scratch/my_ords_config"
-
WebLogic Serverを起動する前に
config.url
システム・プロパティを設定するには、次のコマンドを実行します。export JAVA_OPTIONS="-Dconfig.url=/scratch/my_ords_config"
-
または、
ords war
コマンドを使用して、config.url
コンテキスト・パラメータが明示的に設定され、lib/ext
フォルダからのjar
ファイルが含まれるデプロイ可能なWebアプリケーション・アーカイブ・ファイルを作成します。
ORDS用MySQL JDBC Jar
OCI YUM mysql-connector-java
を使用するか、https://www.mysql.com/
からMySQL Connector/Jをダウンロードし、スタンドアロン、Apache TomcatまたはWebLogicサーバーのいずれかのサーバー・モードの関連する場所にjar
ファイルをコピーします。
ノート:
MySQL Connector/Jの最小限必要なバージョンは8.0.27です。ORDSのOCI YUM RPMディストリビューションにより、OCI YUM mysql-connector-java
JDBC jarへのシンボリック・リンクが作成されます。
OCI YUM RPM
-- Install MySQL Connector/J community edition
sudo yum install mysql-connector-java
-- Confirm JDBC jar is installed
ls -l /usr/share/java/mysql-connector-java.jar
-- Install ORDS from OCI YUM repository
sudo yum install ords
-- Note that ORDS RPM install will create a symbolic link to ORDS installation lib/ext/ directory
ls -l /opt/oracle/ords/lib/ext/
5.1.2.1.1 スタンドアロン・モードでのORDSの実行
スタンドアロン・モードでORDSを実行するときにランタイム・クラスパスに存在するには、最初にMySQL JDBC jarをExtensionフォルダに追加する必要があります。ExtensionフォルダはORDSディストリビューションのlib/ext
ディレクトリで、前の項で説明したOCI YUM RPMインストール・プロセスを使用して作成されます。
5.1.2.1.2 Apache TomcatにデプロイされたORDS
ノート:
Apache Tomcatを使用する場合、java.sql.SQLException: No suitable driver
エラーを回避するために、プールにJDBCドライバのクラス名を明示的に設定する必要があります。
プールにJDBCドライバ・クラス名を設定するには、次のコマンドを実行します。
ords config --db-pool mysql set jdbc.driverName com.mysql.cj.jdbc.Driver
ORDSがApache Tomcatにデプロイされたときにランタイム・クラスパスに存在するためには、MySQL JDBC jar
をサーバー・クラスパスまたはデプロイされたWebアプリケーションに追加する必要があります。jar
をサーバー・クラスパスに追加するには、いくつかの方法がありますが、最も一般的な方法は、jar
ファイルを$CATALINA_HOME/lib
ディレクトリに追加する方法です。
最適なデプロイメント環境を決定するためのオプションおよびガイドラインについては、Apache Tomcatのドキュメントを参照してください。
デプロイされたWebアプリケーションにJDBC jar
を含めるには、それがlib/ext/
フォルダにあり、ords war
コマンドを使用してデプロイ可能なWebアプリケーション・アーカイブ・ファイルを作成していることを確認します。このアーカイブ・ファイルにはconfig.url
コンテキスト・パラメータが明示的に設定され、lib/ext
フォルダにあるすべてのjar
ファイルが含まれています。
関連項目:
Apache Tomcat 85.1.2.1.3 Weblogic ServerにデプロイされたORDS
ORDSがWebLogic Serverにデプロイされたときにランタイム・クラスパスに存在するためには、MySQL JDBC jar
をサーバー・クラスパスまたはデプロイされたWebアプリケーションに追加する必要があります。jar
ファイルをサーバー・クラスパスに追加する1つの方法は、commEnv.cmd/sh
スクリプトのWEBLOGIC_CLASSPATH
環境変数にjar
の場所を指定する方法です。
最適なデプロイメント環境を決定するためのオプションおよびガイドラインについては、WebLogic Serverのドキュメントを参照してください。
デプロイされたWebアプリケーションにJDBC jar
を含めるには、それがlib/ext/
フォルダにあり、ords war
コマンドを使用してデプロイ可能なWebアプリケーション・アーカイブ・ファイルを作成していることを確認します。このアーカイブ・ファイルにはconfig.url
コンテキスト・パラメータが明示的に設定され、lib/ext
にあるすべてのjar
ファイルが含まれています。
5.2 ORDSスタンドアロン・モードでのJettyの構成
この項では、ORDSスタンドアロン・モードで使用されるEclipse Jettyサーバーを構成する方法について説明します。
${configuration.directory}/global/standalone/etc
)で定義されている特定のORDS設定を使用して変更できます。
ノート:
ORDSがApache TomcatやOracle WebLogic Serverなどのコンテナにデプロイされている場合、これらの設定は無効です。関連項目:
5.2.1 Javaシステム・プロパティの使用
この項では、Javaシステム・プロパティを指定して、ORDSで使用されるJetty構成の設定を変更する方法について説明します。
システム・プロパティを指定するには、コマンドラインで--java-option
を使用し、パラメータとしてJavaシステム・プロパティ定義を指定する必要があります。
例:
例5-1 --java-option
コマンドライン・オプションの使用
ords --java-option '-Dthreads.max=300 -Djetty.request.header.size=8192' --config /path/to/config/ serve
関連項目:
JDK Javaのオプション5.2.2 Javaシステム・プロパティ
この項では、Javaシステム・プロパティを示します。
表5-1 Javaシステム・プロパティ
Javaシステム・プロパティ名 | 説明 | デフォルト値 |
---|---|---|
threads.min |
Jettyサーバー(id="Server" )のスレッド・プール内のスレッドの最小数を指定します。
|
10 |
threads.max |
Jettyサーバー(id="Server" )のスレッド・プール内のスレッドの最大数を指定します。
|
200 |
threads.timeout |
Jettyサーバー( この期間より長くアイドル状態になっているスレッドは停止できます。 |
60000 |
jetty.send.xpoweredBy |
Jetty HttpConfiguration (id="httpConfig") のSendXPoweredBy 設定を指定します |
false |
jetty.output.buffer.size |
Jetty HttpConfiguration (id="httpConfig") のOutputBufferSize 設定を指定します |
32768 |
jetty.request.header.size |
Jetty HttpConfiguration (id="httpConfig") のRequestHeaderSize 設定を指定します |
65536 |
jetty.response.header.size |
Jetty HttpConfiguration (id="httpConfig") のResponseHeaderSize 設定を設定します |
8192 |
jetty.send.server.version |
Jetty HttpConfiguration (id="httpConfig") のSendServerVersion 設定を指定します |
false |
jetty.send.date.header |
Jetty HttpConfiguration (id="httpConfig") のSendDateHeader 設定を指定します |
false |
jetty.dump.start |
Jettyサーバー(id="Server" )のDumpAfterStart 設定を指定します
|
false |
jetty.dump.stop |
Jettyサーバー(id="Server" )のDumpAfterStop 設定を指定します
|
false |
5.2.3 Jetty XML構成ファイルの使用
この項では、Jetty XML構成ファイルを使用した、追加機能のためのJettyサーバーの構成方法について説明します。
${configuration.directory}/global/standalone/
です。Jettyホームのetc
ディレクトリに構成XMLファイルを配置すると、Jetty XML構文を使用して追加機能用にJettyサーバーを構成できます。これを実行する機能は、Eclipse Jettyサーバー製品を介して提供されます。
関連項目:
Eclipse Jettyのドキュメント例
${configuration.directory}/global/standalone/etc/
例5-2 特定のアクセス・ログ形式の使用
構成設定standalone.access.log
が指定されている場合、ORDSはアクセス・ログを生成できます。
/global/standalone/etc/jetty-access-log.xml
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Ref id="Handlers">
<Call name="addHandler">
<Arg>
<New id="RequestLog" class="org.eclipse.jetty.server.handler.RequestLogHandler">
<Set name="requestLog">
<New id="RequestLogImpl" class="org.eclipse.jetty.server.CustomRequestLog">
<Arg>/ords/ords-access.log</Arg>
<Arg>%{remote}a - %u %t "%r" %s %O "%{Referer}i" "%{User-Agent}i"</Arg>
</New>
</Set>
</New>
</Arg>
</Call>
</Ref>
</Configure>
例5-3 常にレスポンスで特定のヘッダーを返す
これは、ORDSの前にロード・バランサまたはリバース・プロキシを使用して実現することもできます。ORDSサーバーからのすべてのレスポンスで特定のヘッダーが返されるようにする場合、次のサンプル・コード・スニペットを使用します:
/global/standalone/etc/jetty-response.xml
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Call name="insertHandler">
<Arg>
<New class="org.eclipse.jetty.rewrite.handler.RewriteHandler">
<Get id="Rewrite" name="ruleContainer" />
<Call name="addRule">
<Arg>
<New id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
<Set name="pattern">*</Set>
<Set name="name">Strict-Transport-Security</Set>
<Set name="value">max-age=31536000;includeSubDomains</Set>
</New>
</Arg>
</Call>
</New>
</Arg>
</Call>
</Configure>
5.3 Oracle RAC Fast Connection Failoverのサポート
Oracle REST Data Servicesは、Oracle Real Application Clusters (Oracle RAC)のFast Connection Failover (FCF)機能をサポートします。
Oracle REST Data Servicesは、WebLogic、Tomcatなど、サポートするすべてのApplication Server環境でUniversal Connection Pool (UCP)とともに実行されます。また、UCPはFast Connection Failoverをサポートします。FCFを有効化するには、Oracle Notification Service (ONS)が有効化されている必要があります。ONSを有効化するには、次のコード・スニペットに示すように、Oracle REST Data Services settings.xml
構成ファイルにあるプロパティのリストにエントリを追加します。
<entry key="jdbc.enableONS">true</entry>
<entry key= "jdbc.ONSConfig">nodes=racnode1:4200,racnode2:4200\nwalletfile=/oracle11/onswalletfile</entry>
<entry key="db.connectionType">customurl</entry>
<entry key="db.customURL">jdbc:oracle:thin:@(DESCRIPTION=(FAILOVER=ON)(ADDRESS_LIST=
(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=prod_scan.example.com)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=ISPRD)))</entry>
defaults.xml
構成ファイルを更新した後、Oracle REST Data Servicesを再起動するまで変更は有効になりません。
-
計画外の停止: RACはインスタンス障害を検出するとFAN Downイベントを生成し、それをFCFが捕捉します。 FCFは失敗したインスタンスへのすべての接続を終了し、それ以降のすべてのリクエストを、残っているRACインスタンスに送ります。
-
計画的な停止: たとえば、データベース管理者(DBA)が、一部のメンテナンス・アクティビティを実行するためにRACインスタンスを正常にシャットダウンすることがあります。インスタンス・シャットダウンはFAN Planned Downイベントを生成し、それをFCFが捕捉します。 続いてFCFはすべての新しいリクエストを他のRACインスタンスに送り、現在アクティブなトランザクションを排出するか完了させます。
ノート:
長い間実行されているトランザクションは、強制終了が必要な場合があります。5.4 Kerberos設定を使用したORDSの構成
この項では、ORDSをKerberosファイルベースのチケット・キャッシュを参照し、ORDS実行権限を持つOracle Database Kerberos認証済ユーザーに接続するように構成する方法について説明します。
- 外部認証を使用した新規ユーザーの作成
- 環境変数の設定
- 有効なチケットの指定
- ORDSプール設定の追加
5.5 Oracle Data Guardで保護されているユーザーにアクセスするためのOracle REST Data Servicesの認可
Oracle Data Vault Realmで保護されているデータベース・スキーマ・オブジェクトにアクセスするには、Oracle REST Data Services Publicユーザーにプロキシ・ユーザー認可を付与する必要があります。
ORDS_PUBLIC_USER
がデータベースのHR
ユーザーのプロキシとして動作することを認可します。begin
DBMS_MACADM.AUTHORIZE_PROXY_USER('ORDS_PUBLIC_USER','HR');
end;
/
5.6 REST対応SQLサービス設定の構成
この項では、REST対応SQLサービスを構成する方法について説明します。
ノート:
REST対応SQLサービスを有効にすると、Oracle RESTデータ・サービス対応のデータベース・スキーマに対する認証が有効になります。これにより、データベース・パスワードを使用して、データベース・スキーマがHTTPS経由でアクセス可能になります。Oracleでは、強力かつ安全なデータベース・パスワードを指定することをお薦めします- 次のコマンドを実行します。
ords --config <configuration_folder> config [--db-pool <pool_name>] set restEnabledSql.active true
- Oracle REST Data Servicesを再起動します。
5.7 問合せから戻される行の最大数の構成
- 次のコマンドを実行します。
ords --config <configuration_folder> config set [--db-pool <pool_name>] misc.pagination.maxRows <number>
ノート:
misc.pagination.maxRows
のデフォルト値は10000です。 - Oracle REST Data Servicesを再起動します。
5.8 ウィルス・スキャン用のICAPサーバー統合の構成
この項では、ウイルス・スキャン用にICAPサーバーと統合するようにORDSを構成する方法について説明します。
ORDS PL/SQLゲートウェイでは、ファイル・アップロード時に、Internet Content Adaptation Protocol (ICAP)準拠のウイルス・スキャン・サーバーにウイルス・スキャンの職責を任せることができます。ウィルス・スキャン・サーバーのホスト名とポートは、icap.server
、icap.port
およびicap.secure.port
グローバル構成プロパティで指定します。
APEXではORDS PL/SQLゲートウェイが使用されます。このICAP統合は、構成すると、APEXでのファイル・アップロードにも適用されます。
- 次のコマンドを実行します。
ords --config <configuration_folder> config [--db-pool <pool_name>] set icap.port <number> ords --config <configuration_folder> config [--db-pool <pool_name>] set icap.server <name_or_ip>
- Oracle REST Data Servicesを再起動します。
- ICAPバージョン1.0
- AVSCANという名前のウイルス対策サービス
- action=SCANに対応しているウイルス対策サービス
- 4バイト以上のプレビュー
- X-Infectionという名前のヘッダーを返す
RESPMOD icap://<icap_server>:<icap_port>/AVSCAN?action=SCAN ICAP/1.0
Host: <icap_server>:<icap_port>
Preview: 4
Allow: 204
Encapsulated: req-hdr=0 res-hdr=153 res-body=200
5.9 カスタム・エラー・ページの構成
この項では、Oracle REST Data Servicesにより生成されたエラー・ページではなく、カスタム・エラー・ページを構成する方法について説明します。
-
次のコマンドを実行します。
ords --config /path/to/conf config set error.externalPath /path/to/error/pages/folder/
説明:
/path/to/error/pages/folder
は、エラー・ページを定義するファイルが格納されているフォルダのパスです。ファイルは、{status}.html
形式で格納されます。ここで、{status}
は、カスタム・エラー・ページを作成するHTTPステータス・コードです。 -
Oracle REST Data Servicesを再起動します
例5-4 HTTP 404ステータス・コードのカスタム・エラー・ページの構成
「HTTP 404 – Not Found」ステータスのカスタム・エラー・ページを構成するには、次のステップを実行します。
-
404.html
という名前のファイルを作成します。 -
/usr/local/share/ords/error-pages/
フォルダに保存します。 -
/usr/local/share/ords/errro-pages/
フォルダを指すように、error.externalPath
パラメータを構成します。 -
Oracle REST Data Servicesを再起動します。
5.10 ORDS管理者権限の管理
ORDS_ADMIN
PL/SQLパッケージへのアクセス権は、ORDS_ADMINISTRATOR_ROLE
を介してプロビジョニングします。ORDS_ADMIN
パッケージを介してこのロールをプロビジョニングして、追加のORDS管理者を作成できます。
5.10.1 ユーザーへのORDS_ADMINISTRATOR_ROLEのプロビジョニング
この項では、ORDS_ADMINISTRATOR_ROLE
ロールをユーザーにプロビジョニングする方法について説明します。
データベースのGRANT
コマンドまたはORDS_ADMIN.PROVISION_ADMIN_ROLE
PL/SQLメソッド(ORDS管理者)を使用して、ORDS_ADMINISTRATOR_ROLE
ロールをユーザーにプロビジョニングできます。
例5-5 Grantコマンドの使用
GRANT ORDS_ADMINISTRATOR_ROLE TO HR_ADMIN;
例5-6 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.PROVISION_ADMIN_ROLE(
p_user => 'HR_ADMIN');
END;
/
5.10.2 ユーザーからのORDS_ADMINISTRATOR_ROLEのプロビジョニング解除
この項では、ORDS_ADMINISTRATOR_ROLE
をユーザーからプロビジョニング解除する方法について説明します。
ORDS管理者は、データベースのREVOKE
コマンドまたはORDS_ADMIN.UNPROVISION_ROLES
PL/SQLメソッドを使用して、ORDS_ADMINISTRATOR_ROLE
をユーザーからプロビジョニング解除できます。
例5-7 REVOKEコマンドの使用
REVOKE ORDS_ADMINSTRATOR_ROLE FROM HR_ADMIN;
例5-8 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.UNPROVISION_ROLES(
p_user => 'HR_ADMIN',
p_administrator_role => TRUE);
END;
/
5.11 ORDS実行権限の管理
ORDS_RUNTIME_ROLE
データベース・ロールを使用すると、ユーザーはランタイム・ユーザーとして機能できます。ランタイム・ユーザーはORDSサービス・インスタンスで必要なランタイム接続リソースを管理および構成できます。ORDS_PUBLIC_USER
は、そのようなデータベース・ユーザーの1つです。追加のランタイム・ユーザーがプロビジョニングされると、異なる宛先アドレスと接続プールを持つが同じOracleデータベース・コンテナでホストされる、個別のORDSサービス・インスタンスを構成できます。
ランタイム・ユーザーには他のユーザーへのプロキシに必要な権限が累積されるため、他の目的で再利用しないことをお薦めします。ランタイム・ユーザーには、ORDS_RUNTIME_ROLE
ロールに加えてCREATE SESSION
権限のみが必要です。
5.11.1 ユーザーへのORDS_RUNTIME_ROLEのプロビジョニング
この項では、ORDS_RUNTIME_ROLE
ロールをユーザーにプロビジョニングする方法について説明します。
ORDS管理者は、データベースのGRANT
コマンドまたはORDS_ADMIN.PROVISION_ADMIN_ROLE
PL/SQLメソッドを使用して、ORDS_RUNTIME_ROLE
ロールをユーザーにプロビジョニングできます。
例5-9 Grantコマンドの使用
GRANT ORDS_RUNTIME_ROLE TO ORDS_PUBLIC_USER_2;
例5-10 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.PROVISION_RUNTIME_ROLE(
p_user => 'ORDS_PUBLIC_USER_2');
END;
/
5.11.2 ユーザーからのORDS_RUNTIME_ROLEのプロビジョニング解除
この項では、ORDS_RUNTIME_ROLE
ロールをユーザーからプロビジョニングを解除する方法について説明します
管理者は、データベースのREVOKE
コマンドまたはORDS_ADMIN.UNPROVISION_ROLES
PL/SQLメソッドを使用して、ORDS_RUNTIME_ROLE
をユーザーからプロビジョニング解除できます。
例5-11 REVOKEコマンドの使用
REVOKE ORDS_RUNTIME_ROLE FROM ORDS_RUNTIME_USER_2;
例5-12 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.UNPROVISION_ROLES(
p_user => 'ORDS_RUNTIME_USER_2',
p_runtime_role => TRUE);
END;
/
5.12 非HTTPS環境でOAuth2の使用
RESTfulサービスは、非公開データへのアクセスを制御するOAuth2プロトコルで保護できます。データのスヌーピングを防ぐため、OAuth2では、OAuth2認証プロセスに関与するすべてのリクエストをHTTPSを使用して転送する必要があります。Oracle REST Data Servicesのデフォルトの動作では、OAuth2関連のすべてのリクエストはHTTPSを使用して受信されたことを検証されます。HTTPを介して受信するリクエストへのサービスは拒否され、403 ForbiddenのHTTPステータス・コードが返されます。
このデフォルトの動作は、HTTPSを使用できない環境では次のようにして無効にできます。
-
Oracle REST Data Servicesの構成が格納されているフォルダを探します。例:
/path/to/conf
- 次のコマンドを実行します。
ords --config /path/to/conf config set security.verifySSL false
-
実行中なら、Oracle REST Data Servicesを再起動します。
この設定の使用は、開発またはテスト環境でのみ適切であることに注意してください。ユーザーの資格証明がクリア・テキストで渡されることになるので、本番環境でこの設定を使用するのは適切ではありません。
ノート:
Oracle REST Data Servicesは、構成の変更を行った後に再起動する必要があります。アプリケーションを再起動する方法はアプリケーション・サーバーのマニュアルを参照してください。
5.13 ORDSメタデータ・キャッシュの構成
この項では、ORDSメタデータ・キャッシュの構成方法について説明します。
RESTサービスの数が増加するにつれて、対応するメタデータのデータベースを問い合せるオーバーヘッドが、サービス・パフォーマンスおよびスループット全体に悪影響を与える可能性があります。時間の経過とともに、ORDS_METADATA
ビューの問合せの完了に時間がかかるようになります。これらの問合せは、リクエストごとに実行されます。ORDSメタデータ・キャッシュは、ORDS_METADATA
ビューの問合せが各リクエストにとって高負荷になる程度までサービス数が増加したときに、RESTサービスの全体的なレスポンス時間を改善するのに役立ちます。ORDSメタデータ・キャッシュでは、権限およびモジュール・メタデータのコピーをメモリーに一時的に保持して、RESTサービス・リクエストの受信時に実行されるデータベース問合せの数を減らすことができます。メタデータに対する変更が後続のリクエストにすぐに適用されるように、キャッシュはデフォルトで有効になります。
表5-2 ORDSメタデータ・キャッシュの構成プロパティ
プロパティ | データ型 | デフォルト値 | 説明 |
---|---|---|---|
cache.metadata.enabled |
ブール値 | true |
メタデータ・キャッシュを有効または無効にする設定を指定します。 |
cache.metadata.timeout |
期間 | 1s |
メタデータ・レコードがキャッシュに残る期間を決定するための設定を指定します。期間が長いほど、適用された変更の表示に時間がかかります。 |