I was going through updated official APNS documentation and it clearly says,
All developers should migrate their remote notification provider servers to the more capable and more efficient HTTP/2-based API described in APNs Provider API.
But the new APNs Provider API doesn't seem to have old APNS Feedback Service. They have changed endpoint URLs which doesn't have feedback service endpoint. Also looks the error codes are upgraded now, which includes below error code,
Unregistered -
The device token is inactive for the specified topic.
So aren't we suppose to call the APNS Feedback service anymore?
My major problem is I'm using javapns api version 2.2 for iOS push notifications for which I'm not able to find any update which will help me to cope up with this new changes.
I think the new doc is clear :
There's an HTTP status code for the case that was previously reported by the Feedback Service :
410 - The device token is no longer active for the topic.
In addition, there's a JSON data key named timestamp in the response body :
timestamp
If the value in the :status header is 410, the value of this key is the last time at which APNs confirmed that the device token was no longer valid for the topic.
Stop pushing notifications until the device registers a token with a later timestamp with your provider.
Therefore, the HTTP response in the new API covers the functionality that was previously covered by the Feedback Service. Since the Feedback Service is not mentioned in the new doc, we can safely assume that it's not part of the new API.
If you are using an old library such as javapns, which still uses the old API, I'm assuming that it still uses the Feedback Service too. The old API is likely to still be supported by Apple for a while.
Related
I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?
My question is, what security consequences would this bring? Thank you.
To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.
The convention is to send the ID token to your backend with every request. It's not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn't cost any money.
Typically what you're supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you're supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token - simply use whatever the callback most recently provided.
Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they'll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.
I am using Mesibo SDKs on my Android app for chat and so far all my requirements are fulfilled. All of my Mesibo APIs and token information are stored on server side only. The android app fetches user token from the backend server.
Recently, my app started working unexpectedly such as chat messages not sent/received, user account not created and add group not working at Mesibo side. The backend APIs are all working fine. Upon calling one of the Mesibo API from PostMan, I got this response.
Request:
{'token':$appToken,
'op':'groupadd',
'name':$roomName,
'flag':0,
'expiry':$expiry,
'expiryext'"$expiry,
'active':1
}
Response:
{"op":"groupadd","result":false,"error":"TOKENBREACH"}
This error is new to me and I do not know how to resolve this. Any help would be highly appreciated.
TOKENBREACH indicates that backend API and app token are used from multiple IP addresses which jeopardizes your app security. You are likely to be using an app token from the client-side and hence breach has been flagged.
Read here https://mesibo.com/documentation/api/backend-api/
On this page they explain Web Push with Service Workers stating
Chrome currently uses Firebase Cloud Messaging (FCM) as its push service. FCM recently adopted the Web Push protocol. and then explaining Firebase and so on...
Since the Service Worker gives me a unique endpoint and a pubkey, it seems to me that technically it should be possible to use that endpoint directly, without anything additionally - except if Google deliberally forces a registration.
I mean, just send a POST request to that endpoint, sending just the notification data encrypted/authenticated using the pubkey without any "VAPID".
Do I absolutely need a Firebase account or is it possible to access the endpoint directly (without additional registration) if I just want to send a notification to a single device?
It's 2021 and all major browsers implement a push service and support VAPID now. You use a web push library (Javascript, Python, C#,..) of choice.
There is no need to register anywhere.
The technical mechanism in short is this:
You generate two VAPID keys once using the push library. One key is private and one is public.
The public key is used in the javascript as "application server key" when subscribing to the push service of the browser.
If the subscription is successful you receive a subscription object from the browser containing an endpoint and two additional keys.
The endpoint is an address depending on the web browser / manufacturer and the service it is currently using. The endpoints look like (Oct 2021) e.g.
Google Chrome h_tt_ps://fcm.googleapis.com/fcm/send/cz9gl....., Microsoft Edge h_tt_ps://wns2-par02p.notify.windows.com/w/?toke....., Mozilla Firefox h_tt_ps://updates.push.services.mozilla.com/wpush/v2/gAAAAABhaUA....
If your server program has this information (endpoint and keys from subscription object) it can send a push message to the endpoint with the push library. The corresponding service in the web, hosted by the manufacturer sends this to the browser's service on the device.
There is the PushAPI which shall get used.
But it doesn't is supported by every Browser at the moment.
You can find nice examples in the Service Worker Cookbook of Mozilla
1 Are FCM token and Instance Id one and the same?
In my next questions, I suppose there aren't.
2. Is it possible to register an app instance ID twice to the same topic?
FCM token and Instance Id expire and are refresh.
3. Do we need to subscribe to a topic again after a token refresh?
I suppose we do.
4. Should we listen to a FCM token refresh or to an Instance Id refresh?
I am confused because the Firebase iOS API to register to a topic is:
[[FIRMessaging messaging] subscribeToTopic:#"news"]
It is not explicit which token is involved. My guess is that the internal logic uses the Instance Id because the server API endpoint is https://iid.googleapis.com/iid/v1/IID_TOKEN/rel/topics/TOPIC_NAME
However the Firebase documentation only mentions FCM token refresh and how to monitor them.
The InstanceID and the Token are different. See an explanation of the InstanceID in my answer here, and a general explanation for the token in my answer here.
Usually tho, the token (when printed) contains the InstanceID as well. It may be a format Google chose to make sure that the token is unique, or to connect it to a specific device. I can't say for sure.
There is no way that you can duplicate a subscription. Whenever a token is refreshed, the corresponding subscriptions are kept by the new token.
No. See #2.
It uses the token. The InstanceID is just the ID for the app instance. The token is what FCM needs to send the message.
I'm migrating to the FCM v1 API (https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages) from the legacy API (https://firebase.google.com/docs/cloud-messaging/http-server-ref) to send push notifications.
I want to know if is there some way to retrieve the canonical_id related to the token (registration_id) just like in the legacy API.
I have found nothing about it in the docs, only that the result is a Message object, and if an error occurs it returns a FcmError Object.
If I can't retrieve the canonical_id I think I would end up receiving errors of invalid / not registered token after some time (or am I wrong?), and would have to invalidate them in my database, if the user doesn't use the app during a reasonable amount of time.
AFAICT, canonical_ids haven't been used since the legacy api. See my answer here.
Registration tokens don't get invalidated on a regular basis, just on a few scenarios, where onTokenRefresh() is actually called and thus must be handled on the client side (resend the new token towards your server).