หน้านี้ได้รับการแปลโดย Cloud Translation API

ย้ายจาก HTTP เดิมเป็น HTTP v1

แอปที่ใช้ HTTP API เดิมของ FCM ควรพิจารณาย้ายไปยัง HTTP v1 API โดยใช้คำแนะนำในคู่มือนี้ HTTP v1 API มีข้อได้เปรียบเหล่านี้เหนือ API เดิม:

การรักษาความปลอดภัยที่ดีขึ้นผ่านโทเค็นการเข้าถึง HTTP v1 API ใช้โทเค็นการเข้าถึงที่มีอายุสั้นตามโมเดลความปลอดภัย OAuth2 ในกรณีที่โทเค็นการเข้าถึงกลายเป็นแบบสาธารณะ โทเค็นนั้นจะถูกนำไปใช้ในทางที่ประสงค์ร้ายได้ประมาณหนึ่งชั่วโมงเท่านั้นก่อนที่จะหมดอายุ โทเค็นการรีเฟรชไม่ได้ถูกส่งบ่อยเท่ากับคีย์ความปลอดภัยที่ใช้ใน API เดิม ดังนั้นจึงมีโอกาสน้อยที่จะถูกดักจับ
การปรับแต่งข้อความข้ามแพลตฟอร์มมีประสิทธิภาพมากขึ้น สำหรับเนื้อหาข้อความ HTTP v1 API มีคีย์ทั่วไปที่ไปยังอินสแตนซ์เป้าหมายทั้งหมด รวมถึงคีย์เฉพาะแพลตฟอร์มที่ให้คุณปรับแต่งข้อความข้ามแพลตฟอร์มได้ ซึ่งช่วยให้คุณสร้าง "การแทนที่" ที่ส่งเพย์โหลดที่แตกต่างกันเล็กน้อยไปยังแพลตฟอร์มไคลเอ็นต์ที่แตกต่างกันในข้อความเดียว
ขยายได้มากขึ้นและรองรับอนาคตสำหรับเวอร์ชันแพลตฟอร์มไคลเอนต์ใหม่ HTTP v1 API รองรับตัวเลือกการส่งข้อความที่มีอยู่บนแพลตฟอร์ม Apple, Android และเว็บอย่างสมบูรณ์ เนื่องจากแต่ละแพลตฟอร์มมีบล็อกที่กำหนดไว้ในเพย์โหลด JSON FCM จึงสามารถขยาย API เป็นเวอร์ชันใหม่และแพลตฟอร์มใหม่ได้ตามต้องการ

อัปเดตจุดสิ้นสุดของเซิร์ฟเวอร์

URL ปลายทางสำหรับ HTTP v1 API แตกต่างจากปลายทางเดิมในลักษณะต่อไปนี้:

เป็นเวอร์ชันที่มี /v1 ในเส้นทาง
เส้นทางประกอบด้วยรหัสโปรเจ็กต์ของโปรเจ็กต์ Firebase สำหรับแอปของคุณ ในรูปแบบ /projects/myproject-ID/ รหัสนี้มีอยู่ในแท็บ การตั้งค่าโปรเจ็กต์ทั่วไป ของคอนโซล Firebase
มันระบุอย่างชัดเจนระบุวิธี send เป็น :send

หากต้องการอัปเดตปลายทางของเซิร์ฟเวอร์สำหรับ HTTP v1 ให้เพิ่มองค์ประกอบเหล่านี้ไปยังปลายทางในส่วนหัวของคำขอส่งของคุณ

ก่อน

POST https://fcm.googleapis.com/fcm/send

หลังจาก

POST https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send

อัปเดตการอนุญาตคำขอส่ง

แทนที่สตริงคีย์เซิร์ฟเวอร์ที่ใช้ในคำขอเดิม คำขอส่ง HTTP v1 ต้องใช้โทเค็นการเข้าถึง OAuth 2.0 หากคุณใช้ Admin SDK เพื่อส่งข้อความ ไลบรารีจะจัดการโทเค็นให้คุณ หากคุณใช้โปรโตคอลดิบ ให้รับโทเค็นตามที่อธิบายไว้ในส่วนนี้ และเพิ่มไปยังส่วนหัวเป็น Authorization: Bearer <valid Oauth 2.0 token>

ก่อน

Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA

หลังจาก

Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA

ขึ้นอยู่กับรายละเอียดของสภาพแวดล้อมเซิร์ฟเวอร์ของคุณ ใช้กลยุทธ์เหล่านี้ร่วมกันเพื่ออนุญาตคำขอเซิร์ฟเวอร์ไปยังบริการ Firebase:

ข้อมูลรับรองเริ่มต้นของแอปพลิเคชัน Google (ADC)
ไฟล์ JSON ของบัญชีบริการ
โทเค็นการเข้าถึง OAuth 2.0 อายุสั้นที่ได้รับจากบัญชีบริการ

หากแอปพลิเคชันของคุณทำงานบน Compute Engine, Google Kubernetes Engine, App Engine หรือ Cloud Functions (รวมถึง Cloud Functions สำหรับ Firebase) ให้ใช้ Application Default Credentials (ADC) ADC ใช้บัญชีบริการเริ่มต้นที่มีอยู่ของคุณเพื่อรับข้อมูลรับรองเพื่ออนุญาตคำขอ และ ADC เปิดใช้งานการทดสอบภายในที่ยืดหยุ่นผ่านตัวแปรสภาพแวดล้อม GOOGLE_APPLICATION_CREDENTIALS เพื่อให้ขั้นตอนการให้สิทธิ์เป็นไปโดยอัตโนมัติอย่างเต็มที่ ให้ใช้ ADC ร่วมกับไลบรารีเซิร์ฟเวอร์ Admin SDK

หากแอปพลิเคชันของคุณทำงานบนสภาพแวดล้อมเซิร์ฟเวอร์ที่ไม่ใช่ของ Google คุณจะต้องดาวน์โหลดไฟล์ JSON ของบัญชีบริการจากโปรเจ็กต์ Firebase ตราบใดที่คุณมีสิทธิ์เข้าถึงระบบไฟล์ที่มีไฟล์คีย์ส่วนตัว คุณสามารถใช้ตัวแปรสภาพแวดล้อม GOOGLE_APPLICATION_CREDENTIALS เพื่ออนุญาตคำขอด้วยข้อมูลประจำตัวที่ได้รับด้วยตนเองเหล่านี้ หากคุณไม่สามารถเข้าถึงไฟล์ดังกล่าวได้ คุณต้องอ้างอิงไฟล์บัญชีบริการในโค้ดของคุณ ซึ่งควรทำด้วยความระมัดระวังเป็นอย่างยิ่ง เนื่องจากความเสี่ยงในการเปิดเผยข้อมูลประจำตัวของคุณ

ให้ข้อมูลรับรองโดยใช้ ADC

Google Application Default Credentials (ADC) ตรวจสอบข้อมูลรับรองของคุณตามลำดับต่อไปนี้:

ADC ตรวจสอบว่าตัวแปรสภาพแวดล้อม GOOGLE_APPLICATION_CREDENTIALS ถูกตั้งค่าหรือไม่ หากมีการตั้งค่าตัวแปร ADC จะใช้ไฟล์บัญชีบริการที่ตัวแปรชี้ไป
หากไม่ได้ตั้งค่าตัวแปรสภาพแวดล้อม ADC จะใช้บัญชีบริการเริ่มต้นที่ Compute Engine, Google Kubernetes Engine, App Engine และ Cloud Functions มีให้สำหรับแอปพลิเคชันที่ทำงานบนบริการเหล่านั้น
หาก ADC ไม่สามารถใช้ข้อมูลประจำตัวด้านบนอย่างใดอย่างหนึ่ง ระบบจะส่งข้อผิดพลาด

ตัวอย่างโค้ด Admin SDK ต่อไปนี้แสดงให้เห็นถึงกลยุทธ์นี้ ตัวอย่างไม่ได้ระบุข้อมูลประจำตัวของแอปพลิเคชันอย่างชัดเจน อย่างไรก็ตาม ADC สามารถค้นหาข้อมูลรับรองโดยปริยายตราบเท่าที่มีการตั้งค่าตัวแปรสภาพแวดล้อม หรือตราบใดที่แอปพลิเคชันทำงานบน Compute Engine, Google Kubernetes Engine, App Engine หรือ Cloud Functions

โหนด js

admin.initializeApp({
  credential: admin.credential.applicationDefault(),
});

ชวา

FirebaseOptions options = FirebaseOptions.builder()
    .setCredentials(GoogleCredentials.getApplicationDefault())
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com/")
    .build();

FirebaseApp.initializeApp(options);

หลาม

default_app = firebase_admin.initialize_app()

ไป

app, err := firebase.NewApp(context.Background(), nil)
if err != nil {
	log.Fatalf("error initializing app: %v\n", err)
}init.go

ค#

FirebaseApp.Create(new AppOptions()
{
    Credential = GoogleCredential.GetApplicationDefault(),
});

ให้ข้อมูลประจำตัวด้วยตนเอง

โครงการ Firebase รองรับ บัญชีบริการ ของ Google ซึ่งคุณสามารถใช้เรียก API ของเซิร์ฟเวอร์ Firebase จากเซิร์ฟเวอร์แอปหรือสภาพแวดล้อมที่เชื่อถือได้ หากคุณกำลังพัฒนาโค้ดภายในเครื่องหรือปรับใช้แอปพลิเคชันภายในองค์กร คุณสามารถใช้ข้อมูลประจำตัวที่ได้รับผ่านบัญชีบริการนี้เพื่ออนุญาตคำขอของเซิร์ฟเวอร์

หากต้องการตรวจสอบสิทธิ์บัญชีบริการและอนุญาตให้เข้าถึงบริการ Firebase คุณต้องสร้างไฟล์คีย์ส่วนตัวในรูปแบบ JSON

วิธีสร้างไฟล์คีย์ส่วนตัวสำหรับบัญชีบริการของคุณ:

ในคอนโซล Firebase ให้เปิด การตั้งค่า > บัญชีบริการ
คลิก สร้างคีย์ส่วนตัวใหม่ จากนั้นยืนยันด้วยการคลิก สร้างคีย์
จัดเก็บไฟล์ JSON ที่มีคีย์อย่างปลอดภัย

เมื่อให้สิทธิ์ผ่านบัญชีบริการ คุณมีสองทางเลือกในการให้ข้อมูลประจำตัวแก่แอปพลิเคชันของคุณ คุณสามารถตั้งค่าตัวแปรสภาพแวดล้อม GOOGLE_APPLICATION_CREDENTIALS หรือคุณสามารถระบุเส้นทางไปยังรหัสบัญชีบริการอย่างชัดเจน ตัวเลือกแรกมีความปลอดภัยมากกว่าและขอแนะนำเป็นอย่างยิ่ง

ในการตั้งค่าตัวแปรสภาพแวดล้อม:

ตั้งค่าตัวแปรสภาพแวดล้อม GOOGLE_APPLICATION_CREDENTIALS เป็นเส้นทางไฟล์ของไฟล์ JSON ที่มีรหัสบัญชีบริการของคุณ ตัวแปรนี้ใช้กับเซสชันเชลล์ปัจจุบันของคุณเท่านั้น ดังนั้น หากคุณเปิดเซสชันใหม่ ให้ตั้งค่าตัวแปรอีกครั้ง

ลินุกซ์หรือ macOS

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

หน้าต่าง

ด้วย PowerShell:

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

หลังจากทำตามขั้นตอนด้านบนเสร็จแล้ว Application Default Credentials (ADC) จะสามารถกำหนดข้อมูลประจำตัวของคุณโดยปริยายได้ ทำให้คุณสามารถใช้ข้อมูลประจำตัวของบัญชีบริการเมื่อทดสอบหรือทำงานในสภาพแวดล้อมที่ไม่ใช่ของ Google

ใช้ข้อมูลรับรองเพื่อสร้างโทเค็นการเข้าถึง

ใช้ข้อมูลรับรอง Firebase ของคุณร่วมกับ Google Auth Library สำหรับภาษาที่คุณต้องการเพื่อดึงโทเค็นการเข้าถึง OAuth 2.0 ที่มีอายุสั้น:

node.js

 function getAccessToken() {
  return new Promise(function(resolve, reject) {
    const key = require('../placeholders/service-account.json');
    const jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}index.js

ในตัวอย่างนี้ ไลบรารีไคลเอ็นต์ Google API จะตรวจสอบสิทธิ์คำขอด้วยโทเค็นเว็บ JSON หรือ JWT สำหรับข้อมูลเพิ่มเติม โปรดดูที่ โทเค็นเว็บ JSON

หลาม

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = service_account.Credentials.from_service_account_file(
    'service-account.json', scopes=SCOPES)
  request = google.auth.transport.requests.Request()
  credentials.refresh(request)
  return credentials.tokenmessaging.py

ชวา

private static String getAccessToken() throws IOException {
  GoogleCredentials googleCredentials = GoogleCredentials
          .fromStream(new FileInputStream("service-account.json"))
          .createScoped(Arrays.asList(SCOPES));
  googleCredentials.refreshAccessToken();
  return googleCredentials.getAccessToken().getTokenValue();
}Messaging.java

หลังจากโทเค็นการเข้าถึงของคุณหมดอายุ วิธีการรีเฟรชโทเค็นจะถูกเรียกใช้โดยอัตโนมัติเพื่อดึงโทเค็นการเข้าถึงที่อัปเดต

หากต้องการให้สิทธิ์เข้าถึง FCM ให้ขอขอบเขต https://www.googleapis.com/auth/firebase.messaging

ในการเพิ่มโทเค็นการเข้าถึงไปยังส่วนหัวคำขอ HTTP:

เพิ่มโทเค็นเป็นค่าของส่วนหัวการ Authorization ในรูปแบบ Authorization: Bearer <access_token> :

node.js

headers: {
  'Authorization': 'Bearer ' + accessToken
}index.js

หลาม

headers = {
  'Authorization': 'Bearer ' + _get_access_token(),
  'Content-Type': 'application/json; UTF-8',
}messaging.py

ชวา

URL url = new URL(BASE_URL + FCM_SEND_ENDPOINT);
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setRequestProperty("Authorization", "Bearer " + getAccessToken());
httpURLConnection.setRequestProperty("Content-Type", "application/json; UTF-8");
return httpURLConnection;Messaging.java

อัปเดต payload ของคำขอส่ง

FCM HTTP v1 นำเสนอการเปลี่ยนแปลงที่สำคัญในโครงสร้างของเพย์โหลดข้อความ JSON ในเบื้องต้น การเปลี่ยนแปลงเหล่านี้ช่วยให้แน่ใจว่าข้อความได้รับการจัดการอย่างถูกต้องเมื่อได้รับบนแพลตฟอร์มไคลเอ็นต์ที่แตกต่างกัน นอกจากนี้ การเปลี่ยนแปลงยังให้ความยืดหยุ่นเป็นพิเศษในการปรับแต่งหรือ "ลบล้าง" ช่องข้อความต่อแพลตฟอร์ม

นอกเหนือจากการตรวจสอบตัวอย่างในส่วนนี้แล้ว โปรดดู การปรับแต่งข้อความข้ามแพลตฟอร์ม และตรวจสอบ การอ้างอิง API เพื่อทำความคุ้นเคยกับ HTTP v1

ตัวอย่าง: ข้อความแจ้งเตือนธรรมดา

ต่อไปนี้เป็นการเปรียบเทียบเพย์โหลดการแจ้งเตือนที่เรียบง่ายมาก ซึ่งมีเฉพาะฟิลด์ title body และ data เท่านั้น ซึ่งแสดงให้เห็นถึงความแตกต่างพื้นฐานในเพย์โหลดแบบเดิมและ HTTP v1

ก่อน

{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available."
  },
  "data": {
    "story_id": "story_12345"
  }
}

หลังจาก

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    }
  }
}

ตัวอย่าง: การกำหนดเป้าหมายหลายแพลตฟอร์ม

ในการเปิดใช้งานการกำหนดเป้าหมายหลายแพลตฟอร์ม API เดิมจะดำเนินการแทนที่ในส่วนหลัง ในทางตรงกันข้าม HTTP v1 ให้บล็อกคีย์เฉพาะแพลตฟอร์มที่สร้างความแตกต่างระหว่างแพลตฟอร์มที่ชัดเจนและมองเห็นได้สำหรับนักพัฒนา วิธีนี้ทำให้คุณสามารถกำหนดเป้าหมายหลายแพลตฟอร์มได้เสมอด้วยคำขอเดียว ดังที่แสดงในตัวอย่างต่อไปนี้

ก่อน

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// Apple
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

หลังจาก

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

ตัวอย่าง: การปรับแต่งด้วยการแทนที่แพลตฟอร์ม

นอกเหนือจากการลดความซับซ้อนของการกำหนดเป้าหมายข้อความข้ามแพลตฟอร์มแล้ว HTTP v1 API ยังมีความยืดหยุ่นในการปรับแต่งข้อความต่อแพลตฟอร์ม

ก่อน

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "Check out the Top Story.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// Apple
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

หลังจาก

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY",
        "body": "Check out the Top Story"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

ตัวอย่าง: การกำหนดเป้าหมายอุปกรณ์เฉพาะ

หากต้องการกำหนดเป้าหมายอุปกรณ์เฉพาะด้วย HTTP v1 API ให้ระบุโทเค็นการลงทะเบียนปัจจุบันของอุปกรณ์ใน token นแทน to ถึง

ก่อน

  { "notification": {
      "body": "This is an FCM notification message!",
      "time": "FCM Message"
    },
    "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..."
  }

หลังจาก

{
   "message":{
      "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
      "notification":{
        "body":"This is an FCM notification message!",
        "title":"FCM Message"
      }
   }
}

สำหรับตัวอย่างและข้อมูลเพิ่มเติมเกี่ยวกับ FCM HTTP v1 API โปรดดู บล็อก Firebase