I am working on an application and I encountered such a problem: after uninstalling and installing a new application, when authorizing a new user, the token of the previous user is stored, which was authorized on the device before uninstallation. The token for VoIP push remains the same and when I call the previous user, a voip call comes to both users due to the same token. I was looking for this moment in the manual APNS, but could not find anything.
Is it possible that the platform does not perform any necessary actions before requesting a token?
iphone: 5se
Related
I am building a server side app to periodically access information from users’ Google devices and notify them when certain criteria are met.
I have a few test users signed up, and they have gone through the Google oauth2 login. The app has received their auth code, requested offline access, and stored their refresh tokens in a separate DB location. The app then polls their smart devices periodically using the refresh token to obtain access as needed.
My problem is that the test users’ refresh tokens are expiring after a few days of use. I couldn’t find any documentation from Google about refresh token longevity. Is a few days normal for a refresh token to expire?
If so, my server side app will require user intervention way too often to be useful.
https://developers.google.com/identity/protocols/oauth2#expiration
The sandbox tokens are good for a week but if your application is released officially then you can use the regular refresh tokens.
I saw the description
You may verify the refresh token up to once a day to confirm that the user’s Apple ID on that device is still in good standing with Apple’s servers.
in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user .
I have two question about the description:
Why should we verify the refresh token instead of access token to confirm the user's Apple ID is still in good standing with Apple's server?
The doc said refresh token can only verify once a day. But i can verify refresh token multiple times in practice. Is there some conflict between documentation and implementation?
Update on 10/17/2019：
For apps running on other systems, use the periodic successful verification of the refresh token to determine the lifetime of the user session.
I also saw the description above in in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user . I think periodic is also conflict with once a day.
Right now, I store the access_token and set custom expires time for follow verify request. And get notification from iOS client(getCridentialState) to delete access_token.
I'm planning to migrate the APNs to the Authentication tokens system from the old (certificate based), but I don't want to invalidate the existing valid tokens. Does anybody have any experience with this? Will the existing token still works after migration?
TIA
Token is device specific and if you create an Auth token (which is new way of using push notifications as they have no expiry date), It would have no effect on device token. I guess the proper question here would have been whether the notifications using the old APNS certificates would still be working or not(considering it has been set up on the server as well) even in that case the answer would be Yes. As long as you do not revoke the certificates it would still be working
The token is generated on the device that will receive the notification and is based on your bundle ID and the device. It is not dependent on the credentials that your server uses to connect to the APNS service (The iOS device has no information on this).
As a result you can change the way you connect and authenticate without any impact to existing tokens. It is no different to using a new certificate when the old one expired with the old system.
There are two types of notification messages public and private. Public messages can be seen by anybody who is using this application. Private messages are meant to be seen by only one user. These private messages may contain some confidential information.
While implementing this scenario on iOS. The FCM token for the device is per application instance ( i.e. on app re-install user may get the new fcm token).
Let's say user A logs out. Now, As the server has his device associated with an fcm token server may send some private information.
Few suggestions are to break the association of token with user session by having logout API. But then what about offline logout? Why isn't there any association of user session with FCM token? How can we handle it in offline log-out with no private push message delivery?
Questions reviewed already :
How to refresh FCM Token on user Logout?
Is there a difference between the firebase.auth().getToken() and the FCM registration token returned via Android setup: FirebaseInstanceId.getInstance().getToken()? I am currently using https://www.npmjs.com/package/firebase which uses the first method above to setup auth as well as generate a token. Using that token when trying to send a notification returns: error:InvalidRegistration...
The Auth and FCM tokens are different and unrelated.
The Firebase Authentication ID token identifies the user. A Firebase Authentication access token (auto-generated based on the ID token) grants the user temporary access to the Firebase back-end.
Firebase FirebaseInstanceId token (that is used by Firebase Cloud Messaging) identifies the installation of the app on a specific device.
For example: if you sign in to an app on two different devices, you will get the same authentication UID (although the access token will be different, each time you sign in on a device).
If you have the same app on two devices, the FCM token will be different. But if the app has sign-in functionality, the FCM token will be the same no matter who (or even if) a user is signed in or not. Furthermore: if a different user signs in to the same installed app, the FCM token will remain unchanged.