Androidの難読化ルール

難読化ルールを使用すると、エージェントがNew Relicに送信する前に機密データをマスクできます。各ルールは、正規表現パターンと置換文字列のペアです。エージェントは、すべての送信イベントのすべての文字列属性値に順番にルールを適用します — QoE eventsやクラッシュから回復したイベントを含みます。

使い方

正規表現パターンと置換文字列をそれぞれ持つ、ObfuscationRuleオブジェクトのリストを定義します。
設定ビルダーの.withObfuscationRules()にリストを渡します。
各HTTP送信の直前に、ObfuscationEngineはバッチ内のすべてのイベントのすべての文字列属性を反復処理し、ルールを順番に適用します。
文字列値のみが処理されます — 整数、long、ブール値、nullは変更されずにそのまま渡されます。
元のイベントオブジェクトが変更されることはないため、失敗したバッチは二重に難読化されることなくクリーンに再試行できます。

構成

import com.newrelic.videoagent.core.ObfuscationRule;
import java.util.Arrays;
import java.util.List;

// Define rules — each rule is a regex pattern and a replacement string.
// Rules are applied in order on every string attribute of every outgoing event.
List<ObfuscationRule> obfuscationRules = Arrays.asList(
    // Mask account IDs:  "account-83729"  →  "ACCOUNT_ID"
    new ObfuscationRule("account-\\d+", "ACCOUNT_ID"),

    // Mask auth tokens:  "token=abc123xyz"  →  "token=REDACTED"
    new ObfuscationRule("token=[^&\"]+", "token=REDACTED"),

    // Mask user path segments:  "/users/john_doe"  →  "/users/USER_ID"
    new ObfuscationRule("/users/[^\"/]+", "/users/USER_ID")
);

NRVideoConfiguration config = new NRVideoConfiguration.Builder("application-token")
        .autoDetectPlatform(getApplicationContext())
        .withHarvestCycle(5 * 60)
        .withObfuscationRules(obfuscationRules)
        .build();

NRVideo.newBuilder(getApplicationContext()).withConfiguration(config).build();

`ObfuscationRule`

new ObfuscationRule(String pattern, String replacement)

パラメータ	タイプ	説明
`pattern`	`String`	Javaの正規表現パターン文字列。事前コンパイルされます — 無効なパターンの場合、構築時に`IllegalArgumentException`がスローされます。
`replacement`	`String`	各一致を置換する文字列。一致を削除するには`""`を使用します。`$`と`\`は後方参照ではなく、通常の文字として扱われます。

`obfuscationRules`

HTTP送信の直前に、すべての送信イベントのすべての文字列属性に適用されるObfuscationRuleオブジェクトのリスト。ルールは宣言された順序で実行されます — 1つのルールの出力が次のルールに渡されます。デフォルト: 空のリスト（難読化なし）。

一般的なパターン

マスクする対象	パターン	置き換え
数値のアカウントID	`account-\\d+`	`ACCOUNT_ID`
認証/ベアラートークン	`token=[^&\"]+`	`token=REDACTED`
ユーザーパスセグメント	`/users/[^\"/]+`	`/users/USER_ID`
メールアドレス	`[a-zA-Z0-9._%+\\-]+@[a-zA-Z0-9.\\-]+\\.[a-zA-Z]{2,}`	`EMAIL_REDACTED`
UUID	`[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}`	`UUID_REDACTED`

ルールの順序

ルールは左から右へ適用されます。ルールNの出力は、ルールN+1の入力になります。あるルールの置換が後のルールのパターンと一致する可能性がある場合、順序が重要になります。

// Rule 1 turns "/john" into "/USER", then Rule 2 sees "/USER_profile" and masks it.
new ObfuscationRule("john", "USER"),
new ObfuscationRule("USER_profile", "PROFILE")
// Result: "/john_profile" → "/USER_profile" → "/PROFILE"

エッジケース

状況	動作
ルールが設定されていない	No-op — オーバーヘッドはゼロで、元のリストがそのまま返されます。
パターンが一致しない	値は変更されずにそのまま渡されます。
空の置換 `""`	一致したコンテンツは削除されます。
`$` または置換の`\`	プレーン文字として扱われます（正規表現の後方参照ではありません）。
Integer/Long/Boolean値	スキップされました — `String`値のみが処理されます。
`null` value	スキップされました — NullPointerExceptionはありません。
無効な正規表現パターン	`IllegalArgumentException` `new ObfuscationRule(...)`の構築時にスローされます — ハーベスト時にサイレントに失敗するのではなく、起動時にフェイルファストします。
`null` 置換	`IllegalArgumentException` 構築時にスローされます。
HTTP送信の失敗 → デッドレター再試行	元の（難読化されていない）イベントが再試行されます；再試行パスでは難読化が正しく再適用されます。

この機械翻訳は、参考として提供されています。

使い方 .css-21sua1{background:none;border:none;width:0;padding:0;}

構成

ObfuscationRule

obfuscationRules

一般的なパターン

ルールの順序

エッジケース

使い方

`ObfuscationRule`

`obfuscationRules`