ラベル Config の投稿を表示しています。 すべての投稿を表示
ラベル Config の投稿を表示しています。 すべての投稿を表示

2022年8月30日火曜日

APEXアプリケーションの変更点を調べる

 APEXアプリケーションの変更(コンポーネントの作成、変更、削除)は、管理メニューのアクティビティのモニターを開いた画面にある、開発者アクティビティアプリケーション変更(詳細)から確認することができます。

デフォルトではいくつかの列が非表示になっています。すべて表示させると以下のレポートになります。一覧される履歴を制限するために、期間アプリケーションによる絞り込みを行うと良いでしょう。日付の降順で一覧すると見やすくなると思います。

このレポートに列として、APEX表名SCNおよびコンポーネント・キーが含まれています。

Autonomous Databaseの場合、APEXがインストールされているスキーマが保護されているため、APEX表に直接アクセスすることはできません。すべて標準ビューを介してのアクセスになるため、これから説明する作業はできません。

誰が何をいつ変更したか、といったことはAutonomous Databaseでも、上記のレポートより確認できます。いつ、についてはSCNより正確な時刻を割り出すことも可能です。

select scn_to_timestamp(<SCN>) at time zone 'Asia/Tokyo' from dual;

オンプレミス環境の場合、APEX表に直接問い合わせを発行できるため、実施された変更を確認できます。

アクション作成および削除であれば、コンポーネント(の種類)とコンポーネント名から概ね実行された作業は分かります。そのため、詳細まで調べる必要性はあまりないかと思います。

以下は、アクション変更のときの確認手順です。

例としてアプリケーションID110ページ番号3のページにあるファセットP3_MGRラベルを、マネージャーから上司に変更し保存します。


アプリケーションの変更のレポートを確認すると、変更履歴が見つかります。変更されたAPEX表名として、WWV_FLOWS_STEPSとWWV_FLOW_STEP_ITEMSがあります。


コマンドライン・ツールでデータベースに接続します。

APEXがインストールされているスキーマをカレント・スキーマに変更します。APEX 22.1の場合はAPEX_220100がAPEXがインストールされているスキーマになります。

SQL> alter session set current_schema = apex_220100;


Session altered.


SQL> 


現在のデータと変更前のデータを、別の表に保存します。APEX表名SCNコンポーネント・キーの値を使い、以下のCREATE TABLE文を実行します。

CREATE TABLE <変更後の表> AS SELECT * FROM <APEX表名> where ID = <コンポーネント・キー>;
CREATE TABLE <変更前の表> AS SELECT * FROM <APEX表名> as of scn <列SCNの値> where ID = <コンポーネント・キー>;

APEXのワークスペース・スキーマとして、APEXDEVが作成済みであるとします。

上記のDDLを実行して、表を作成します。変更後のアイテムのデータを表STEP_ITEMS_AC変更前STEP_ITEMS_BC変更後のページのデータを表STEPS_AC変更前STEPS_BCに保存しています。

SQL> create table apexdev.step_items_ac as select * from wwv_flow_step_items where id = 4025742564048869;


Table created.


SQL> create table apexdev.step_items_bc as select * from wwv_flow_step_items as of scn 3874676 where id = 4025742564048869;


Table created.


SQL> create table apexdev.steps_ac as select * from wwv_flow_steps where flow_id = 110 and id = 3;


Table created.


SQL> create table apexdev.steps_bc as select * from wwv_flow_steps as of scn 3874678 where flow_id = 110 and id = 3;


Table created.


SQL> 


APEX表は大抵列ID が主キーで、コンポーネント・キーで検索すると1行だけが返されます。ただし、表WWV_FLOW_STEPS(これはページのメタデータ)は例外で、アプリケーションIDであるFLOW_IDとページIDであるIDの複合主キーなので、FLOW_IDとIDを検索条件にします。

変更前の情報の検索には、フラッシュバック問い合わせ(AS OF SCN)を使っています。そのため、初期化パラメータのundo_retentionの期間内に検索を実行する必要があります。

APEXのアプリケーションを作って、変更後と変更前の表の違いを確認します。

アプリケーションのページにクラシック・レポートのリージョンを2つ作成します。ひとつはソース表名変更後の表STEP_ITEMS_ACを指定します。もうひとつはソース表名変更前の表STEP_ITEMS_BCを指定します。リージョンの配置を横並びにするため、変更前のリージョンのレイアウト新規行の開始OFFにします。


クラシック・レポートの属性を開き、外観テンプレートとしてValue Attribute Pairs - Columnを選択します。列と値を縦方向に一覧表示します。


以上の設定を行い、アプリケーションを実行します。


Promptマネージャーから上司に変更されていることが確認できます。


変更後の列Last Updated ByとLast Updated Onより、変更した人と時刻を確認できます。


変更履歴には表WWV_FLOW_STEPSへの変更がレポートされています。しかし、表WWV_FLOW_STEP_ITEMSと同様の手順で変更内容を確認すると、メタデータには変更は見つかりませんでした。変更したのはファセットのラベルだけなので、これは想定通りです。列Last Updated ByとLast Updated Onのみが変更されています。


APEXアプリケーションの変更点を調べる方法の紹介は以上になります。

ちなみにアプリケーションの変更履歴はAPEX表WWV_FLOW_BUILDER_AUDIT_TRAILに保存されています。この表にはビューやシノニムは登録されていないため、ユーザーSYSやSYSTEMのみがアクセスできます。Autonomous Databaseの場合は管理者ユーザーのADMINであってもアクセスできません。必ずアクティビティのモニターを開いて確認する必要があります。

WWVで始まるAPEX表を直接問い合わせることは、サポート対象外です。そのため取得した情報の扱いは、参考程度にとどめておくべきです。APEXアプリケーションのメタデータを参照する場合は、APEX_で始まる標準ビューを使用します。

2022年8月29日月曜日

誤って削除したアプリケーションを回復する

 誤ってアプリケーションを削除してしまっても、削除したアプリケーションと同じIDのアプリケーションを作成した後に、過去のアプリケーションをエクスポート/インポートすると、削除したアプリケーションを回復することができます。

例えば、アプリケーションIDが102のアプリケーションパラメータ付きレポートを誤って削除してしまった状況を考えます。

アプリケーションが削除されると、アプリケーションを開くことができないためエクスポートの機能も呼び出せません。

ワークスペース・ユーティリティのエクスポートを開きます。

エクスポートする対象としてアプリケーションを選択します。

削除されたアプリケーションは選択リストに含まれないため、エクスポートできません。

そこで、アプリケーション作成ウィザードを起動し、アプリケーションID102(回復するアプリケーションのアプリケーションIDと同じ)のアプリケーションを作成します。アプリケーションの名前はなんでも構いませんが、回復するアプリケーションも含めて、他のアプリケーションとは異なる名前(英数字が望ましい)にします。今回の例ではdummyです。

アプリケーションが作成されたら、エクスポートを実行します。

現在から○○分前の指定として、削除されたアプリケーションが確実に存在していた時刻となる分を設定します。以下の例では20分としています。

エクスポートを実行します。

ファイルがエクスポートされます。続けて、エクスポートされたファイルをインポートします。


インポートを実行し、エクスポートされたファイルを選択します。


予めエクスポートされたファイルを確認しアプリケーション名に間違いがなければ、次のアプリケーションとしてインストールに、エクスポート・ファイルからアプリケーションID 102を再利用を選びます。確信が持てない場合は、新規アプリケーションIDを自動割当てを選んで、一旦別アプリケーションとしてインポートします。


アプリケーションを置き換える場合は、アプリケーションの置換を行う確認が求められます。表示されているメッセージに、置き換えられるアプリケーションの名前置き換えるアプリケーションの名前が表示されるので(置き換えるアプリケーションの名前はUnicodeそのままなのでわかりにくいですが)、それぞれ間違いが無いことを確認します。


インポートが完了すると、削除してしまったアプリケーションが回復していることが確認できます。


削除したデータが回復できるのはデータベースの初期化パラメータundo_retentionに依存します。設定値を確認し、その期間内にエクスポート作業を実施する必要があります。

残念なことにundo_retentionが有効な期間内にエクスポートができなかった場合は、直近の変更までを回復する方法はありません。その場合は、自動的にバックアップされているアプリケーションより、最近のアプリケーションを回復します。

ワークスペース・ユーティリティバックアップの管理を開きます。


リストア対象のアプリケーションを開きます。


アクションからリストアを実行します。


次のアプリケーションとしてインストールRestore Application ID 102を選択ます。

アプリケーションのリストアを実行します。


直近ではありませんが、これで最近のバックアップより削除されたアプリケーションを回復することができます。

2022年8月23日火曜日

アプリケーションのインストール時にパラメータを設定する

 前回の記事でStripeで支払いを行うアプリケーションを作成しました。その際、公開可能キーやAPEXが稼働しているホスト名、メール・アドレスを直接記述しています。

var stripe = Stripe('pk_公開可能キーの貼り付け');
var apex_path = 'https://ホスト名/ords/r/ワークスペース名/';
var successUrl = apex_path + '/stripe-payment/success?session=' + apex.env.APP_SESSION;
var cancelUrl =  apex_path + '/stripe-payment/error?session=' + apex.env.APP_SESSION;
var customerEmail = '電子メール・アドレス';

これらの値はAPEXアプリケーションのインストール先で変更する必要があります。

アプリケーション置換文字列サポートするオブジェクトの設定を行なった上でアプリケーションをエクスポートすると、そのアプリケーションをインポートする際に置換文字列に値を設定できます。

以下より、設定の手順を紹介します。

アプリケーション置換文字列を設定すると、前出のJavaScriptのコードは以下のように書き換えることができます。

var stripe = Stripe('&G_STRIPE_KEY.');
var apex_path = '&G_APEX_PATH.';
var successUrl = apex_path + '/stripe-payment/success?session=' + apex.env.APP_SESSION;
var cancelUrl =  apex_path + '/stripe-payment/error?session=' + apex.env.APP_SESSION;
var customerEmail = '&G_CUSTOMER_EMAIL.';

置換文字列として、G_STRIPE_KEYG_APEX_PATHG_CUSTOMER_EMAILを設定しています。

アプリケーション定義置換を開いて、置換文字列置換値を設定します。


JavaScriptでは置換文字列、例えば&G_STRIPE_KEY.、PL/SQLやSQLではバインド変数 :G_STRIPE_KEYといった形式で参照することができます。

置換文字列を設定した後にサポートするオブジェクトアプリケーション置換文字列の設定を行います。

サポートするオブジェクトを開きます。


インストールアプリケーション置換文字列を開きます。


アプリケーションのインポート時に、値の入力を要求する置換文字列プロンプトチェックを入れます。また、プロンプト・テキストを設定します。


現在の値は、インストール時に元の値として表示されます。センシティブな値の場合、エクスポートする前に変更しておくか、エクスポート・ファイルを直接編集して、元の値を変更しておく必要があります。

あとは通常のエクスポートを行い、アプリケーションをファイルに出力します。

そのファイルをインポートすると、インストールの手順の中で以下の画面が表示され、置換文字列の値の入力を求められます。


このような設定を行うことで、アプリケーションのインポート時に置換文字列の値を設定することができます。

2022年6月15日水曜日

OktaのグループをAPEXに認識させる方法とシングル・サインアウトの設定

 Oktaを使ったSAMLのシングル・サインオンの設定ができたので、さらに追加の構成を確認してみました。


OktaのグループをAPEXのダイナミック・グループとする


Okta側でユーザーが所属しているグループを、APEXアプリケーションのサインイン時にダイナミック・グループとして登録します。結果として、Okta側での所属グループでAPEXアプケーションの認可を制御することができます。

Oktaの設定画面を開き、DirectoryGroupsよりグループを作成します。Everyoneは最初から作成されているので、今回はAdministratorというグループを追加で作成しています。

Add Groupをクリックし、グループAdministratorを作成します。その後、作成されたグループAdministratorを開きます。


Assign Peopleをクリックし、People(つまりサインインするユーザー)をグループに含めます。

グループに含めるユーザーをNot Membersから+をクリックして、Membersへ移動します。


ユーザーをグループに含めたら、Saveをクリックします。


サインインの際に、Okta(IdP)からSP(APEX)に送信されるレスポンスに、グループの情報を含めます。ApplicationSAML Settingsに含まれるGROUP ATTRIBUTE STATEMENTSに設定を追加します。

Applicationsを開いて、作成済みのSP(前回の記事ではapexとして作成)を開きます。GeneralタブのSAML SettingsEditをクリックします。


General Settingsは変更せず、Nextをクリックします。

次に開く画面のGroup Attribute Statements (optional)にて、NamegroupsName formatBasicFilter正規表現と一致を選択して.*を指定します。

設定を行った後にPreview the SAML Assertionsをクリックし、設定した結果を確認します。


Assertionの内容が表示されます。NameIDとして表示されているユーザーが所属しているグループが、Attributeとして含まれていることを確認します。


Okta側で必要な変更は以上になります。Nextをクリックしてこの画面の変更を確定し、最後にSaveを実行して変更を保存します。

続いて、Oktaが送信してくるレスポンスからグループを取り出し、ダイナミック・グループを設定する処理をAPEX側に設定します。

ダイナミック・グループを設定するコードは以下になります。


APEXアプリケーションのSAMLサインインの認証スキームを開き、ソースPL/SQLコードに上記のコードを記載します。

ログイン・プロセス認証後のプロシージャ名に、ソースに記述したプロシージャassign_dynamic_groupsを設定します。


アプリケーション定義セキュリティを開き、認可ロールまたはグループ・スキームのソースカスタム・コードに変更します。


以上で、APEXアプリケーション側の設定も完了です。

ダイナミック・グループが正しく設定されているか確認するために、SAML認証の確認のために作成したアプリケーションsamltestに、対話モード・レポートのリージョンを作成します。

識別タイトルダイナミック・グループとします。ソース表名にAPEXの標準ビューAPEX_WORKSPACE_SESSION_GROUPSを指定します。


対話モード・レポートを追加したので、アプリケーションを実行します。Oktaでサインインしたのち、アプリケーションのホーム・ページが表示されます。

Group NameとしてAdministratorおよびEveryoneがリストされていれば、正しく設定できています。



シングル・サインアウトを設定する



アプリケーションからサインアウトを実行します。


Oktaではサインアウトがエラーになり、以下の画面が表示されます。


このエラーを回避するために、Okta側でシングル・サインアウトの設定を行います。

アプリケーションのSAML Settingsを編集します。Advanced Settingsを開き、Enable Single LogoutAllow application to initiate Single Logoutチェックを入れます。Single Logout URLSP Issuer共に、APEX側のSAMLコールバックURLを設定します。apex_authentication.saml_callbackで終わるURLで、このアプリケーションのSingle sign on URLおよびAudience URI(SP Entity ID)として設定しているURLと同一のURLです。

Signature Certificateとして、APEX側の内部およびワークスペース・アプリケーション用のSAML: APEX属性証明書として設定した証明書を設定します。以前の記事通りの手順であれば、cert-test.pemとして生成した証明書になります。


以上でOkta側のシングル・サインアウトの設定は完了です。Nextをクリックして作業を進め、最終的にSaveを実行して変更した設定を保存します。

Okta側で生成されたSingle Logout URLを確認します。アプリケーションのSign Onタブを開いて、SAML SetupView SAML setup instructionsを開きます。


②のIdentity Provider Single Logout URLをコピーし、APEX側に設定します。


APEXの認証制御SAMLの設定画面を開き、一番下にあるサインアウトURLに上記のURLを設定します。


以上でシングル・サインアウトの設定は完了です。

APEXアプリケーションからサインアウトを実行すると、Oktaのログイン画面に戻ります。


Oracle APEXのSAML認証でOktaをIdPに使用するにあたって、利用可能な追加設定の説明は以上になります。

Oracle APEXのアプリケーション作成の参考になれば幸いです。

2022年6月14日火曜日

SAML認証で使用したデバッグ手順

 SAML認証のデバッグで使用した、いくつかの手順を紹介します。


公開鍵証明書の確認



SAMLの認証スキームの編集画面より、証明を登録したときに証明書が無効ですと表示されれることがあります。



証明書の貼り付け方に問題があるのか(コピペミスなど)、または証明書自体に問題があるのか、このメッセージだけでは特定が難しいです。openssl x509 -textを実行することで、証明書の内容が確認できている場合は、さらに難しいです。

openssl x509 -in 公開鍵証明書ファイル -text -noout

マニュアルには記載されていませんが、Oracle APEXで扱う公開鍵証明書を検証するファンクションがあります。WWV_FLOW_PUBLIC_KEY_UTIL.IS_CERTIFICATEです。公開鍵証明書を文字列として受け取り、証明書として正しければTRUE、そうでなければFALSEを返します。

このファンクションを使った検証スクリプトの雛形です。


opensslではパースできるのに、上記でFALSEとなる(Certificate is NOT valid.が印刷される)場合は、Oracle APEXが提供しているファンクションを使って、証明書がパースできるかどうか確認します。WWV_FLOW_PUBLIC_KEY_UTIL.PARSE_CERTIFICATEを使います。

このファンクションを使った検証スクリプトの雛形です。


スクリプトの実行にあたっては、事前にAPEXのスキーマをCURRENT_SCHEMAに設定します。

APEX 22.1の場合は、APEX_220100がAPEXがインストールされているスキーマになります。

alter session set current_schema = APEX_220100;

残念ながらAutonomous Databaseでは、APEXのスキーマは保護されています。そのため、内部で使用するパッケージに含まれるプロシージャやファンクションを呼び出すことはできません。オンプレの環境を用意する必要があります。

正常に実行されると、以下のように表示されます。

SQL> alter session set current_schema = apex_220100;


Session altered.


SQL> @verify-cert

Certificate is valid.


PL/SQL procedure successfully completed.


SQL> @parse-cert

cert_sig_algorithm = c_sha256_rsa

key_algorithm = RSA

key_length = 2048


PL/SQL procedure successfully completed.


SQL> 



HARファイルの確認



ORDSへ送信されるOriginヘッダーの内容は、HARをエクスポートして確認しています。

ChromeまたはEdgeを例に取ります。ブラウザの開発者ツールを実行し、ネットワークを開きます。

最初に、それまでの記録をクリアします。


レコード・ボタンをクリックして、ネットワーク・ログの記録を開始します。記録中は、ボタンが赤くなります。


ネットワーク・ログを記録するURLにアクセスします。


記録したデータを、ファイルにダウンロードします。


レコード・ボタンをクリックし、レコーディングを停止します。


ダウンロードしたファイルの内容を確認します。

HTTPヘッダーなどの情報を確認することができます。



ブラウザごとに操作に違いがあります。使用しているブラウザでのHARの取得方法を確認しましょう。


d0、d1、d2スクリプトの使用



SAMLコールバックのデバッグ・メッセージを取得するには、インスタンス全体でデバッグを有効にする必要があります。

このためにAPEXのダウンロード・メディアのapex/utilities/debug以下に配置されているd0.sqlを使用します。

APEXのデータベースに、sysまたはsystemで接続し、CURRENT_SCHEMAをAPEXのスキーマに設定します。続いてd0.sqlを実行します。デバッグ・レベルが9、つまり完全トレースになります。APEX全体への影響が大きいため、本番環境での実施には特別な注意が必要です。

SQL> alter session set current_schema = apex_220100;


Session altered.


SQL> @d0

Changed debug level from "" to "9"

SQL> 


SAMLのサインインを実施します。


再度d0.sqlを実行し、デバッグ・メッセージの取得を停止します。

SQL> alter session set current_schema = apex_220100;


Session altered.


SQL> @d0

Changed debug level from "" to "9"

SQL> @d0

Changed debug level from "9" to ""

SQL> 


d1.sqlを実行し、直近のAPEXへのアクセスを一覧します。

PAGE_VIEW_ID  STARTED  SECS   LVL  COUNT PATH_INFO       APP:PAGE SESSION_ID   WORKSPACE USER

------------- -------- ------ --- ------ ---------------------------- ---------- --------------------------------- -------------------- --------------------------------


@d2 8003      06:00:00 0.03       16 DBMS_SCHEDULER/ORACLE_APEX_M 0   Unknown

AIL_QUEUE


@d2 8004      06:00:00 0.01       5 DBMS_SCHEDULER/ORACLE_APEX_W 0   Unknown

S_NOTIFICATIONS


@d2 8005      06:00:02 0.01       9 DBMS_SCHEDULER/ORACLE_APEX_P 0   Unknown

URGE_SESSIONS


@d2 8006      06:00:10 0.20 WRN    220 show       4500:1000  0-16849648434733   INTERNAL nobody


PAGE_VIEW_ID  STARTED  SECS   LVL  COUNT PATH_INFO       APP:PAGE SESSION_ID   WORKSPACE USER

------------- -------- ------ --- ------ ---------------------------- ---------- --------------------------------- -------------------- --------------------------------

@d2 8007      06:00:11 0.72     1610 show       4550:1 0-16849648434733   INTERNAL nobody

@d2 8618      06:00:24 0.18 WRN    315 show       102:1 0-9657959965886   APEXDEV nobody

@d2 8619      06:00:43 0.36 WRN    508 ajax plugin       102:1 0-9657959965886   APEXDEV nobody


30 rows selected.


SQL> 


アプリケーションIDやページIDなどを参照して、確認すべきページ・ビューIDを特定します。SAMLコールバックのPATH_INFOajax pluginになります。

上記の例では@d2 8619より、SAMLコールバックのデバッグ・メッセージを確認することができます。

SQL> @d2 8619


デバッグ・メッセージが手元のファイルにダウンロードされ、エディタが開きます。


詳細なデバッグ・メッセージを参照できます。通常は、このデータをファイルに保存してオラクルのサポートに提出することになるでしょう。


画面へのエラー詳細表示


ORDSのプロパティdebug.printDebugToScreentrueにすると、ブラウザの画面にエラーの詳細が表示されます。マニュアルのこちらに説明があります。

debug.printDebugToScreenがfalse(デフォルト)のときに、ORDSでエラーが発生した画面です。


ORDS 22.1にて、上記のプロパティをtrueにする方法です。ordsコマンドのパスおよび構成ファイルが含まれるディレクトリは、インストール毎に異なります。

/usr/local/bin/ords --config /etc/ords/config config set debug.printDebugToScreen true

[oracle@apex ~]$ /usr/local/bin/ords --config /etc/ords/config config set debug.printDebugToScreen true


ORDS: Release 22.1 Production on Tue Jun 14 04:39:29 2022


Copyright (c) 2010, 2022, Oracle.


Configuration:

  /etc/ords/config/


The global setting named: debug.printDebugToScreen was set to: true

[oracle@apex ~]$ 


変更を有効にするには、ORDS(またはTomcat)を再起動する必要があります。

ORDS 21.4.3以前では、以下のコマンドを実行します。

java -jar ords.war set-property debug.printDebugToScreen true

[oracle@ords ords]$ java -jar ords.war set-property debug.printDebugToScreen true

2022-06-14T04:45:10.789Z INFO        Modified: /opt/oracle/ords/conf/ords/defaults.xml, setting: debug.printDebugToScreen = true

[oracle@ords ords]$


ORDS 221.1および21.4.3の双方で、上記のコマンドによって、設定ファイルに以下の行が書き込まれます。設定ファイルの名前はORDS 22.1ではsettings.xml、ORDS 21.xではdefaults.xmlになります。

<entry key="debug.printDebugToScreen">true</entry>

以上の変更より、エラーの詳細が画面に表示されます。


エラー発生時の詳細が画面に表示されるため、この状況での本番運用は望ましくありません。デバッグが終了したら、以下のコマンドにより設定を削除します。

/usr/local/bin/ords --config /etc/ords/config config delete debug.printDebugToScreen

[oracle@apex ~]$ /usr/local/bin/ords --config /etc/ords/config config delete debug.printDebugToScreen


ORDS: Release 22.1 Production on Tue Jun 14 05:00:18 2022


Copyright (c) 2010, 2022, Oracle.


Configuration:

  /etc/ords/config/


The global setting named: debug.printDebugToScreen was removed from the configuration

[oracle@apex ~]$ 


ORDS 21.xではエディタでdefaultsxmlを開いて、該当の設定を削除します。

変更の反映には、ORDSの再起動が必要です。

SAML認証で使用した、デバッグ手順の紹介は以上になります。