ビジネスルールとアクセス制御ルール (ACL) の関係Issue ビジネスルールは、フォーム、リスト、または Web サービスのいずれからアクセスするかに関係なく、レコードに一貫して適用されるデータベーストリガーです。これが、ビジネスルールとクライアントスクリプトの主な違いであり、フォームの編集時にクライアント側でのみ適用されます。 ビジネスルールは、次の一般的なタイプを含むさまざまなアクションを実行できます。 ユーザーが更新しているフォームのフィールド値を変更します。フィールド値は、そのフィールドで使用可能な特定の値、他のフィールドからコピーされた値、およびユーザーのロールによって決定される相対値に設定できます。ユーザーに情報メッセージを表示します。親タスクの変更に基づいて子タスクの値を変更します。ユーザーがフォーム上の特定のフィールドにアクセスしたり、フィールドを変更したりできないようにします。現在のデータベーストランザクションを中止します。たとえば、特定の条件が満たされている場合に、ユーザーがデータベースにレコードを保存できないようにします。管理者は、スクリプトを作成せずにフィールド値の設定、情報メッセージの作成、トランザクションの中止を行うことができます。 ビジネスルールは、ACL を優先するまで、および までは ACL を優先しません。 次のテストシナリオは、ビジネスルールが ACL を優先する状況、または使用する関数に基づいてビジネスルールが ACL を優先しない状況を示しています。 _table_security_tester という名前のテーブルを作成します。 新しいテーブル u_table_security_tester を設定します。 [コントロール] セクションで、[アクセス制御の作成] をオンにします。新しいユーザーロール u_table_security_tester_user を追加します。 2 つの sys_dictionary レコードを作成します。 u_active、設定は true/false、read_onlyu_change、設定文字列、最大長 40 次の値を使用して、u_table_security_tester.u_active/write という名前の ACL を作成します。 管理者上書き：オフにする詳細：オンscript："answer = false;") 次の設定でビジネスルールを作成します。 名前：アクティブを反転テーブル：u_table_security_testerWhen：before、Order：100、inset：true、update：trueフィルター条件：「変更」「変更」 Script : (function executeRule(current, previous /*null when async*/) { var active = !!parseInt(current.getValue("u_active")); current.setValue("u_active", !active); })(current, previous); 次の詳細を使用して UI アクションを作成します。 名前：アクティブフラグの設定 (GRS)テーブル：u_table_security_tester順序：100アクティブ：True挿入を表示：True更新を表示：Trueフォームボタン：TrueScript : var gr = new GlideRecordSecure("u_table_security_tester"); gr.get(current.getUniqueValue()); gr.setValue("u_change", gs.generateGUID()); gr.update(); 次の詳細を使用して UI アクションを作成します。 名前：アクティブフラグの設定 (GR)テーブル：u_table_security_tester順序：100アクティブ：True挿入を表示：True更新を表示：Trueフォームボタン：TrueScript : var gr = new GlideRecord("u_table_security_tester"); gr.get(current.getUniqueValue()); gr.setValue("u_change", gs.generateGUID()); gr.update(); /u_table_security_tester_list.do に移動します。 [変更] フィールドに値 test を指定してレコードを作成します。 確立されたロジックでは、[変更] フィールドの値が変更されてレコードが保存されるたびに、アクティブステータスが逆になります。true は false になり、false は true になります。 どちらの UI アクションでも、一意の新しい GUID が生成されます。 テスト 1：GlideRecord -「アクティブフラグの設定 (GR) UI アクション」 作成したレコードを開きます。[アクティブフラグの設定 (Set Active Flag)] (GR) ボタンをクリックして、クリックするたびに [アクティブ] フィールドの値を True から False に、False から True に変更する必要があることを示します。 ビジネスルール「Flip Active」は、ACL によって [アクティブ] フィールドへの書き込みが禁止されている場合でも、レコードを更新します。 テスト 2: GlideRecordSecure -「アクティブフラグ (GRS) UI アクションを設定」の場合 作成したレコードを開きます。[Set Active Flag (GRS)] ボタンをクリックします。クリックするたびに、[Active] フィールドの値は変更されません。 理由：ビジネスルール「Flip Active」は (gs.log ステートメントで確認できるように) バックグラウンドで実行されますが、GlideRecordSecure が ACL を優先するため、値は更新されません。これは、ビジネスルールが ACL を優先することを意味するのではなく、ビジネスルールに関して使用される関数がトリックを実行することを意味します。GlideRecordSecure は GlideRecord から継承されたクラスであり、GlideRecord と同じ機能を実行し、ACL も適用します。GlideRecord と GlideRecordSecure の違いの詳細については、製品ドキュメントのトピック「GlideRecordSecure の使用」を参照してください。 テスト 3：REST API REST API /$restapi.do にアクセスします。 名前空間：nowAPI テーブル：テーブル APIAPI バージョン：最新[レコードの変更 (PUT)] を選択します。tableName：u_table_security_testersys_id：作成されたレコードの sys_id。要求本文 --> ドロップダウンから [変更] フィールドを選択し、毎回新しい値を入力して [送信] をクリックします応答のステータスコードは常に「200 OK」ですが、レコードのフィールド「アクティブ」は実際には更新されません。 理由：ビジネスルール「Flip Active」がバックグラウンドで実行されます。gs.log ステートメントで確認すると、値が更新されていることがわかりますが、アクセス制御によってアクセスが防止され、sys_dictionary レコードがデータベースのレコードに対して読み取り専用に設定されているため、値は更新されません。ビジネスルールはまだ実行中であり、ACL を優先しませんが、REST API を使用してこのアクションを実行しているユーザーには、ACL の制限とフィールドが読み取り専用であるため、適切なアクセス権がありません。 デフォルトでは、REST API は基本認証または OAuth を使用して Web リソースへのアクセス制御を適用します。 テーブルで定義された ACL は、データへのアクセスが制限されます。 認証に使用されるユーザー ID は、インタラクティブユーザーと同じ方法でアクセス制御されます。各要求には、適切な認証情報が必要です。各要求に、使用する資格情報を含む認証ヘッダーが含まれていることを確認します。受信相互認証はサポートされていません。 認証と承認なしでテーブルへのアクセスを許可するには、テーブル名を sys_public.list に追加します。テーブルで定義された ACL は引き続き適用され、テーブルで ACL を非アクティブ化する責任はユーザーにあります。 詳細については、製品ドキュメントの次のトピックを参照してください。 REST API セキュリティ REST API テーブルアクセス テーブル API ビジネスルールは、フォーム、リスト、または Web サービスからアクセスできるかどうかには関係なく、一貫してレコードに適用されます。値が更新されているという結果はシステムログで確認できますが、REST API を介してアクションを実行するユーザーはアクセス制限によりそれを実行するためのアクセス権がないため、更新は行われません。 受信 SOAP Web Service Security の場合、各 WSDL または SOAP メッセージ要求のインスタンスに関連付けられたユーザーに基本認証を適用するために、管理者はプロパティglide.basicauth.requiredを true に設定できます。有効にした場合、各 WSDL および SOAP 要求には、基本認証プロトコルで指定されている認証ヘッダーが含まれている必要があります。Web サービス要求は非インタラクティブであるため、ServiceNow では要求中に常に認証ヘッダーが必要です。 詳細については、製品ドキュメントのトピック SOAP Web サービスを参照してください。