メインコンテンツまでスキップ

メディア認証管理

お知らせ

このドキュメントは機械翻訳で作成された下書きであり、現在レビュー中です。機械翻訳の特性上、一部の内容が不正確であったり、韓国語の原文と異なる場合があります。より正確な情報については、韓国語のドキュメントをご参照ください。

メディア認証管理 API v3 リファレンスへ移動
バージョン別機能範囲のご案内
  • v2 非対応: メディア認証機能は v2 では対応していません。
  • 共通認証: すべてのバージョンの API は、クエリストリングパラメータ(?access_token=)による共通認証方式を使用します。エラー判定基準に関する共通仕様については、API v3 マイグレーションガイドの 主要な変更事項 セクションを参照してください。

Kollus 暗号化適用​

  • 既存 (v1): POST /media_auth/media_token/get_kollus_encrypt
  • 既存 (v2): 未対応
  • 変更 (v3): POST /media/kollus-encrypt
変更事項
  • リクエスト構造の維持: リクエストボディに source_string（暗号化対象文字列）フィールドを必須で渡す仕様は v1 と同じです。
  • レスポンスデータフォーマットの変更: v1 では暗号化結果値の後ろに '|V1.0' という接尾辞が付与されて返却されていましたが（結果|V1.0）、v3 では接尾辞が除去された純粋な暗号化文字列データのみを encoded フィールドに格納して返却します。
リクエストボディおよびレスポンス構造の詳細

リクエストボディ​

フィールドデータ型必須可否説明
source_stringString必須暗号化対象の原本文字列

レスポンス構造の対照​

  • v1
{
  "error": 0,
  "message": "success",
  "result": "A1B2C3D4E5|V1.0"
}
  • v3
{
  "data": {
    "encoded": "A1B2C3D4E5"
  },
  "status": "ok"
}

ユーザーキー生成​

  • 既存 (v1): POST /media_auth/user_key/create
  • 既存 (v2): 未対応
  • 変更 (v3): POST /media/user-key
変更事項
  • 認証の一元化: サービスアカウント識別のために使用されていた content_provider_key フィールドが削除されました。v3 からは access_token でサービスアカウント権限を識別します。
  • 必須パラメータ: remote_addr および user_agent フィールドが v3 から必須パラメータに変更されました。
  • 有効時間のカスタマイズ: v1 では発行後の有効時間が 6 時間に固定されていましたが、v3 では user_key_timeout（sec）フィールドを通じて有効期限を直接指定できます。
リクエストボディおよびレスポンス構造の詳細

リクエストボディ​

フィールドデータ型v1 必須可否v3 必須可否説明
client_user_idString / Integer必須 (Integer)必須 (String)お客様のユーザーID
content_provider_keyString必須-サービスアカウントキー（access_token に置き換え）
remote_addrString任意必須接続クライアントの IP アドレス
user_agentString任意必須接続クライアントのブラウザ環境
user_key_timeoutInteger-任意キー有効時間（sec）

レスポンス構造の対照​

  • v1
{
  "error": 0,
  "message": "success",
  "result": "key"
}
  • v3
{
  "data": {
    "user_key": "string"
  },
  "status": "ok"
}

ユーザーキー再発行​

  • 既存 (v1): POST /media_auth/user_key/update（有効期限延長およびキー交換）
  • 既存 (v2): 未対応
  • 変更 (v3): PUT /media/user-key/{user_key}（再発行）
ビジネスロジックの変更

v3 は既存のユーザーキーを即座に無効化（Invalidate）し、新しいキーを再発行する方式で動作します。 そのため、user_key が同一のまま維持されると仮定したクライアントロジックがある場合は、v3 移行時に新しいキーに置き換わるよう修正する必要があります。

レスポンス構造の詳細

レスポンス構造の対照​

  • v1
{
  "error": 0,
  "message": "success",
  "result": "string"
}
  • v3
{
  "data": {
    "user_key": "string"
  },
  "status": "ok"
}

ユーザーキー削除​

  • 既存 (v1): POST /media_auth/user_key/delete（リクエストボディ送信）
  • 既存 (v2): 未対応
  • 変更 (v3): DELETE /media/user-key/{user_key}（パスパラメータ送信）
変更事項
  • メソッドおよび伝達方式の変更: HTTP メソッドが POST から DELETE に変更されました。削除対象である user_key はリクエストボディではなくパスパラメータで渡す必要があります。
  • 認証パラメータの削除: content_provider_key フィールドが削除されました（access_token に置き換え）。

ウォーターマーキング識別コード照会​

  • 既存 (v1/v2): 未対応
  • 変更 (v3): GET /media/watermarking-code
リクエストパラメータおよびレスポンス構造の詳細

リクエストクエリパラメータ​

パラメータデータ型必須可否説明
client_user_idString必須お客様のユーザーID

レスポンス構造仕様​

{
  "data": {
    "code": "string"
  }
}