I'm reading through FCM token management best practices in the documentation (https://firebase.google.com/docs/cloud-messaging/manage-tokens) and have the following questions.
On initial startup of your app, the FCM SDK generates a registration
token for the client app instance... your app should retrieve this
token at initial startup and save it to your app server alongside a
timestamp.
Is the recommendation here to handle the token on app launch or just the first time the app is launched on install? Because I can't imagine given how many server interactions there are in the typical life of a client process that we wouldn't just update the token every time the app is launched and call it a day instead of creating additional tasks to keep these tokens fresh.
We recommend that you periodically retrieve and update all registration tokens on your server.
Is the recommendation here to null stale tokens?
We recommend that you periodically retrieve and update all registration tokens on your server. This requires you to add server logic to update the token’s timestamp at regular intervals, regardless of whether or not the token has changed.
I don't understand what this means. Is the recommendation here to task the server with updating a token's timestamp? What does this accomplish? And is the server capable of generating a token for a client?
According to the docs, as I understand, you have to :
On client side :
Store the token on your server on first launch (your server will consider that your token is valid for 2 months)
Update your token on server if it changes
On server side:
When a new token is registered store the token in your database and set his validity for 2 months (if the token already exist in your database then just reset his validity for 2 months again)
When a notification send fails, then remove the invalid token from tour database
Periodically (monthly suggested), validate all tokens and reset their validity date if valid (delete if not).
The token is generated only when you first launch the app after install, and in some reset events. So your token will stay mostly the same, it won't change in every app launch. The timestamp is what the server will check. Maybe this will help:
First Launch
Token generated, send to the server with timestamp
Regular Launch
Token retrieved(same token), send again to the server periodically (2 Months?)
Now, this is where it gets hazy. As far as I understand, the server should signal the app in some way to get the token again (even if it is unchanged) to refresh the token in the server database and then refresh the timestamp.
Related
I'm trying to verify Firebase App Check tokens on my custom backend. Everything is fine so far, but there's one thing I'm not sure about: My backend is hosted on a private network therefore I need to know if grabbing key sets from https://firebaseappcheck.googleapis.com/v1/jwks is the only necessary outgoing HTTP request involved in the verification process.
The answer is "Yes" according to https://github.com/firebase/firebase-admin-node/issues/2014#issuecomment-1353472578
Obtaining the Firebase App Check public JSON Web Key Set is the only outgoing request for the app check verify token API. The SDK might make other http calls during the initialization based on your environment (obtaining the service account or credentials etc.) or if you use other APIs in combination with the App check token verification.
The rest of the JWT verification happens all offline. We also cache the public keys (JWKS) for up to 6 hours, so if your environment doesn't lose its state then the outgoing request to fetch the keys should not happen (if the keys are cached) every time you call the API.
I have a web application that deployed on Firebase Hosting and uses Firebase Authentication.
I also have a backend server, deployed on Google App Engine, that serve this app.
How can I get the Firebase-UID cookie in the backend server to validate the user?
I don't want to enforce the app to add the cookie content as a parameter for each request.
When I used the Google Identity Toolkit (merged into the Firebase Authentication since) it took a pretty long time to get an authentication token check done, so I didn't want to do it for each and every backend request.
So what I did was to perform it (typically) once per user session and, upon successful verification, create a unique memcache entry for the user and place its key in the user session info. So for subsequent requests for the same session I'd only check if the session info contains the memcache key and, if so, check if the corresponding memcache entry exists - a memcache key lookup is a lot faster than a token verification. The only thing needed to complete the picture is deletion of the memcache entry whenever the user logs out. If you want you can also enforce a token recheck after a certain amount of time - simply by setting the memcache entry's expiration time.
Note: the memcache entry can disappear anytime, which would require another token verification even if the user didn't log out - so multiple times per session. But in my case it was a rare enough occurrence.
I'm trying server side to invalidate a registration token forcing the client app to request a new token.
Reading the docs:
The InstanceID is long lived, but may expire for the following reasons:
Device factory reset.
User uninstalls the app.
User performs “Clear Data” in the app.
Device unused for an extended period (device and region determines the timespan).
Instance ID service detects abuse or errors and resets the InstanceID.
Server-side code if your client app requires that functionality.
https://developers.google.com/instance-id/reference/
Whats the server side code that allows me to invalidate or force the expiration of the token ?
Thanks.
For example, using the google API:
https://iid.googleapis.com/iid/info/token?details=true
When doing a 'get' over that endpoint I get information of the token. When was created, in what platform is running, and what are the topics registered for that token.
I would like through the API make that token invalid.
Is this possible ?
I want to register my app for GCM services just after the user installs my app(i.e. before launch). Is this possible? Or else is there a hack available.
If you want follow the standard GCM client app registration process, your app has to launch in order register, because the app server and the client app must complete a client/server "handshake."
From the GCM documentation, it states that the client obtains a unique registration token and passes it to the app server, which stores the token and sends an acknowledgement back to the client app. The registration token exchanged in the handshake process is the same client app instance identifier used subsequently to send messages to the client.
so, if your app is not launched, you can not pass the registration token to the app server. For android, you need to use the Instance ID API to complete the process.
Sample code:
InstanceID instanceID = InstanceID.getInstance(this);
String token = instanceID.getToken(getString(R.string.gcm_defaultSenderId),
GoogleCloudMessaging.INSTANCE_ID_SCOPE, null);
(notice the R.string.gcm_defaultSenderID is a project number you acquire from the API console. )
There was a hack in this post, if you want to start a service after an app is installed. But it might not be a good practice for you to complete the registration process, because you hard code the Sender ID, Application ID and Sender Auth Token listed in this page.
Like the Facebook application, you only enter your credentials when you open the application for the first time. After that, you're automatically signed in every time you open the app. How does one accomplish this?
There's a commom line in all auto-login implementations
Upon an initial login, a token is received and stored on the client side
Upon subsequent visits, if token is available on the client side, the server resolves the identity and logs in automatically
Now concrete implementation variations can be numerous. The token can be a session ID (encripted or not), OAuth token, custom token, username and password should be avoided. Storing token can be on within a browser cookie, browser local storage, can have a server counter-part. Security is the major concern. Generally about the topic you can read more here https://softwareengineering.stackexchange.com/questions/200511/how-to-securely-implement-auto-login
You have an interesting explanation of how does Stackoverflow do it https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work.