แอปที่ใช้ 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)
}
ค#
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);
});
});
}
ในตัวอย่างนี้ ไลบรารีไคลเอ็นต์ 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.token
ชวา
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();
}
หลังจากโทเค็นการเข้าถึงของคุณหมดอายุ วิธีการรีเฟรชโทเค็นจะถูกเรียกใช้โดยอัตโนมัติเพื่อดึงโทเค็นการเข้าถึงที่อัปเดต
หากต้องการให้สิทธิ์เข้าถึง FCM ให้ขอขอบเขต https://www.googleapis.com/auth/firebase.messaging
ในการเพิ่มโทเค็นการเข้าถึงไปยังส่วนหัวคำขอ HTTP:
เพิ่มโทเค็นเป็นค่าของส่วนหัวการ Authorization
ในรูปแบบ Authorization: Bearer <access_token>
:
node.js
headers: {
'Authorization': 'Bearer ' + accessToken
}
หลาม
headers = {
'Authorization': 'Bearer ' + _get_access_token(),
'Content-Type': 'application/json; UTF-8',
}
ชวา
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;
อัปเดต 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