HTTP ve XMPP için desteği sonlandırılan eski FCM API'lerini kullanan uygulamalar, en kısa sürede HTTP v1 API'ye geçmelidir. Bu API'lerle mesaj gönderme (yukarı akış mesajları dahil) özelliği 20 Haziran 2023'te kullanımdan kaldırıldı ve kapatma işlemi 22 Temmuz 2024'te başlayacak.
Etkilenen özellikler hakkında daha fazla bilgi edinin.
HTTP v1 API, sürekli destek ve yeni özelliklerin yanı sıra eski API'lere kıyasla aşağıdaki avantajlara sahiptir:
Erişim jetonları aracılığıyla daha iyi güvenlik HTTP v1 API, OAuth2 güvenlik modeline göre kısa süreli erişim jetonları kullanır. Bir erişim jetonunun herkese açık hâle gelmesi durumunda, süresi dolmadan önce yalnızca bir saat kadar kötüye kullanılabilir. Yenileme jetonları, eski API'de kullanılan güvenlik anahtarları kadar sık iletilmediğinden yakalanma olasılıkları çok daha düşüktür.
Platformlar arasında mesajları daha verimli bir şekilde özelleştirme HTTP v1 API'sinde, mesaj gövdesi için tüm hedeflenen örneklere giden ortak anahtarların yanı sıra mesajı platformlar arasında özelleştirmenize olanak tanıyan platforma özel anahtarlar bulunur. Bu sayede, tek bir iletide farklı istemci platformlarına biraz farklı yük gönderen "üst yazmalar" oluşturabilirsiniz.
Yeni istemci platformu sürümleri için daha fazla genişletilebilir ve geleceğe hazır HTTP v1 API, Apple platformları, Android ve Web'de kullanılabilen mesajlaşma seçeneklerini tam olarak destekler. Her platformun JSON yükünde kendi tanımlanmış bloğu olduğundan FCM, API'yi gerektiğinde yeni sürümlere ve yeni platformlara genişletebilir.
Sunucu uç noktasını güncelleme
HTTP v1 API'sinin uç noktası URL'si, eski uç noktadan şu açılardan farklıdır:
- Yolda
/v1
ile sürümlendirilir. - Yol, uygulamanız için Firebase projesinin proje kimliğini
/projects/myproject-ID/
biçiminde içerir. Bu kimliği Firebase konsolunun Genel proje ayarları sekmesinde bulabilirsiniz. send
yöntemini:send
olarak açıkça belirtir.
HTTP v1 için sunucu uç noktasını güncellemek istiyorsanız bu öğeleri gönderme isteklerinizin başlığındaki uç noktaya ekleyin.
Önceki HTTP istekleri
POST https://fcm.googleapis.com/fcm/send
Önceki XMPP istekleri
Eski XMPP mesajları, aşağıdaki uç noktaya bağlanan bir bağlantı üzerinden gönderilir:
fcm-xmpp.googleapis.com:5235
Sonra
POST https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send
Gönderme isteklerinin yetkilendirmesini güncelleme
Eski isteklerde kullanılan sunucu anahtarı dizesi yerine HTTP v1 gönderme isteklerinde OAuth 2.0 erişim jetonu gerekir. Mesaj göndermek için Yönetici SDK'sını kullanıyorsanız kitaplık jetonu sizin için yönetir. Ham protokol kullanıyorsanız jetonu bu bölümde açıklandığı gibi edinin ve Authorization: Bearer <valid Oauth 2.0 token>
olarak üstbilgiye ekleyin.
Önce
Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA
Sonra
Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA
Sunucu ortamınızın ayrıntılarına bağlı olarak, Firebase hizmetlerine yönelik sunucu isteklerine yetki vermek için aşağıdaki stratejilerin bir kombinasyonunu kullanın:
- Google Uygulama Varsayılan Kimlik Bilgileri (ADC)
- Hizmet hesabı JSON dosyası
- Hizmet hesabından türetilen kısa ömürlü bir OAuth 2.0 erişim jetonu
Uygulamanız Compute Engine, Google Kubernetes Engine, App Engine veya Cloud Functions (Cloud Functions for Firebase dahil) üzerinde çalışıyorsa Uygulama Varsayılan Kimlik Bilgileri'ni (ADC) kullanın. ADC, istekleri yetkilendirmek için kimlik bilgilerini almak üzere mevcut varsayılan hizmet hesabınızı kullanır ve GOOGLE_APPLICATION_CREDENTIALS ortam değişkeni aracılığıyla esnek yerel test yapmanızı sağlar. Yetkilendirme akışının en üst düzeyde otomasyonu için ADC'yi Yönetici SDK'sı sunucu kitaplıklarıyla birlikte kullanın.
Uygulamanız Google dışı bir sunucu ortamında çalışıyorsa Firebase projenizden bir hizmet hesabı JSON dosyası indirmeniz gerekir. Özel anahtar dosyasını içeren bir dosya sistemine erişiminiz olduğu sürece, manuel olarak elde edilen bu kimlik bilgileriyle istekleri yetkilendirmek için GOOGLE_APPLICATION_CREDENTIALS ortam değişkenini kullanabilirsiniz. Bu tür dosya erişiminiz yoksa kodunuzda hizmet hesabı dosyasına referans vermeniz gerekir. Bu işlem, kimlik bilgilerinizin açığa çıkma riski nedeniyle son derece dikkatli bir şekilde yapılmalıdır.
ADC'yi kullanarak kimlik bilgileri sağlama
Google Uygulama Varsayılan Kimlik Bilgileri (ADC), kimlik bilgilerinizi aşağıdaki sırayla kontrol eder:
ADC, GOOGLE_APPLICATION_CREDENTIALS ortam değişkeninin ayarlanıp ayarlanmadığını kontrol eder. Değişken ayarlanmışsa ADC, değişkenin işaret ettiği hizmet hesabı dosyasını kullanır.
Ortam değişkeni ayarlanmamışsa ADC, Compute Engine, Google Kubernetes Engine, App Engine ve Cloud Functions'ın bu hizmetlerde çalışan uygulamalar için sağladığı varsayılan hizmet hesabını kullanır.
ADC yukarıdaki kimlik bilgilerinden hiçbirini kullanamazsa sistem bir hata verir.
Aşağıdaki Admin SDK kod örneği bu stratejiyi göstermektedir. Örnekte, uygulama kimlik bilgileri açıkça belirtilmiyor. Ancak ADC, ortam değişkeni ayarlandığı veya uygulama Compute Engine, Google Kubernetes Engine, App Engine ya da Cloud Functions'da çalıştığı sürece kimlik bilgilerini dolaylı olarak bulabilir.
Node.js
admin.initializeApp({
credential: admin.credential.applicationDefault(),
});
Java
FirebaseOptions options = FirebaseOptions.builder()
.setCredentials(GoogleCredentials.getApplicationDefault())
.setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com/")
.build();
FirebaseApp.initializeApp(options);
Python
default_app = firebase_admin.initialize_app()
Go
app, err := firebase.NewApp(context.Background(), nil)
if err != nil {
log.Fatalf("error initializing app: %v\n", err)
}
C#
FirebaseApp.Create(new AppOptions()
{
Credential = GoogleCredential.GetApplicationDefault(),
});
Kimlik bilgilerini manuel olarak sağlama
Firebase projeleri, Google hizmet hesaplarını destekler. Bu hesapları, uygulama sunucunuzdan veya güvenilir ortamınızdan Firebase sunucu API'lerini çağırmak için kullanabilirsiniz. Yerel olarak kod geliştiriyorsanız veya uygulamanızı şirket içinde dağıtıyorsanız sunucu isteklerine yetki vermek için bu hizmet hesabı aracılığıyla edinilen kimlik bilgilerini kullanabilirsiniz.
Bir hizmet hesabının kimliğini doğrulamak ve Firebase hizmetlerine erişmesi için yetkilendirmek üzere JSON biçiminde bir özel anahtar dosyası oluşturmanız gerekir.
Hizmet hesabınız için özel anahtar dosyası oluşturmak üzere:
Firebase konsolunda Ayarlar > Hizmet Hesapları'nı açın.
Yeni Gizli Anahtar Oluştur'u tıklayın, ardından Anahtar Oluştur'u tıklayarak onaylayın.
Anahtarı içeren JSON dosyasını güvenli bir şekilde saklayın.
Bir hizmet hesabı üzerinden yetki verirken uygulamanıza kimlik bilgilerini sağlama konusunda iki seçeneğiniz vardır. GOOGLE_APPLICATION_CREDENTIALS ortam değişkenini ayarlayabilir veya hizmet hesabı anahtarının yolunu kodda açıkça iletebilirsiniz. İlk seçenek daha güvenlidir ve kesinlikle önerilir.
Ortam değişkenini ayarlamak için:
GOOGLE_APPLICATION_CREDENTIALS ortam değişkenini, hizmet hesabı anahtarınızı içeren JSON dosyasının dosya yoluna ayarlayın. Bu değişken yalnızca mevcut kabuk oturumunuz için geçerlidir. Bu nedenle, yeni bir oturum açarsanız değişkeni tekrar ayarlayın.
Linux veya macOS
export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"
Windows
PowerShell ile:
$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"
Yukarıdaki adımları tamamladıktan sonra Uygulama Varsayılan Kimlik Bilgileri (ADC), kimlik bilgilerinizi dolaylı olarak belirleyebilir. Böylece, Google dışı ortamlarda test ederken veya çalıştırırken hizmet hesabı kimlik bilgilerini kullanabilirsiniz.
Erişim jetonları oluşturmak için kimlik bilgilerini kullanma
Kısa süreli bir OAuth 2.0 erişim jetonu almak için Firebase kimlik bilgilerinizi tercih ettiğiniz dildeki Google Auth Library ile birlikte kullanın:
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);
});
});
}
Bu örnekte Google API istemci kitaplığı, isteğin kimliğini JSON web jetonu veya JWT ile doğrular. Daha fazla bilgi için JSON web jetonları başlıklı makaleyi inceleyin.
Python
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
Java
private static String getAccessToken() throws IOException {
GoogleCredentials googleCredentials = GoogleCredentials
.fromStream(new FileInputStream("service-account.json"))
.createScoped(Arrays.asList(SCOPES));
googleCredentials.refresh();
return googleCredentials.getAccessToken().getTokenValue();
}
Erişim jetonunuzun süresi dolduktan sonra, güncellenmiş bir erişim jetonu almak için jeton yenileme yöntemi otomatik olarak çağrılır.
FCM'e erişim yetkisi vermek için https://www.googleapis.com/auth/firebase.messaging
kapsamını isteyin.
Erişim jetonunu bir HTTP istek başlığına eklemek için:
Jetonu, Authorization
başlığının değeri olarak Authorization: Bearer <access_token>
biçiminde ekleyin:
node.js
headers: {
'Authorization': 'Bearer ' + accessToken
}
Python
headers = {
'Authorization': 'Bearer ' + _get_access_token(),
'Content-Type': 'application/json; UTF-8',
}
Java
URL url = new URL(BASE_URL + FCM_SEND_ENDPOINT);
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setRequestProperty("Authorization", "Bearer " + getServiceAccountAccessToken());
httpURLConnection.setRequestProperty("Content-Type", "application/json; UTF-8");
return httpURLConnection;
Gönderme isteklerinin yükünü güncelleme
FCM HTTP v1, JSON mesaj yayının yapılandırmasında önemli bir değişiklik sunar. Bu değişiklikler öncelikle, iletilerin farklı istemci platformlarında alındığında doğru şekilde işlenmesini sağlar. Ayrıca, platform başına ileti alanlarını özelleştirmek veya "üst yazmak" için size ek esneklik sunar.
Bu bölümdeki örnekleri incelemenin yanı sıra HTTP v1 ile ilgili bilgi edinmek için Bir mesajı platformlar arasında özelleştirme başlıklı makaleyi inceleyin ve API referansını inceleyin.
Örnek: basit bildirim mesajı
Eski ve HTTP v1 yüklerinde temel farklılıkları gösteren, yalnızca title
, body
ve data
alanlarını içeren çok basit bir bildirim yükünün karşılaştırması aşağıda verilmiştir.
Önce
{
"to": "/topics/news",
"notification": {
"title": "Breaking News",
"body": "New news story available."
},
"data": {
"story_id": "story_12345"
}
}
Sonra
{
"message": {
"topic": "news",
"notification": {
"title": "Breaking News",
"body": "New news story available."
},
"data": {
"story_id": "story_12345"
}
}
}
Örnek: iç içe yerleştirilmiş JSON verileri
Eski mesajlaşma API'sinden farklı olarak HTTP v1 API, data
alanında iç içe yerleştirilmiş JSON değerlerini desteklemez.
JSON'dan dizeye dönüştürme işlemi gereklidir.
Önce
{
...
"data": {
"keysandvalues": {"key1": "value1", "key2": 123}
}
}
Sonra
{
"message": {
...
"data": {
"keysandvalues": "{\"key1\": \"value1\", \"key2\": 123}"
}
}
}
Örnek: Birden fazla platformu hedefleme
Eski API, çok platformlu hedeflemeyi etkinleştirmek için arka uçta geçersiz kılma işlemleri gerçekleştiriyordu. Buna karşılık HTTP v1, platformlar arasındaki farkları geliştirici için açık ve görünür hale getiren platforma özgü anahtar blokları sağlar. Bu sayede, aşağıdaki örnekte gösterildiği gibi her zaman tek bir istekle birden fazla platformu hedefleyebilirsiniz.
Önce
// 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"
}
}
Sonra
{
"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"
}
}
}
}
}
Örnek: Platform geçersiz kılmalarıyla özelleştirme
HTTP v1 API, mesajların platformlar arası hedeflemesini basitleştirmenin yanı sıra mesajları platforma göre özelleştirme esnekliği de sunar.
Önce
// 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"
}
}
Sonra
{
"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"
}
}
}
}
}
Örnek: Belirli cihazları hedefleme
HTTP v1 API ile belirli cihazları hedeflemek için to
anahtarı yerine token
anahtarında cihazın mevcut kayıt jetonunu sağlayın.
Önce
{ "notification": {
"body": "This is an FCM notification message!",
"title": "FCM Message"
},
"to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..."
}
Sonra
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"body":"This is an FCM notification message!",
"title":"FCM Message"
}
}
}
FCM HTTP v1 API hakkında daha fazla örnek ve bilgi için aşağıdakilere bakın:
HTTP v1 API ile uygulama sunucusu gönderme isteklerini oluşturma hakkında yol gösterici bilgiler. Belirli bir şekilde belirtilmediği sürece tüm "REST" snippet'leri v1 API'yi kullanır.