--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/59e014fb-1c72-4bea-9cb3-888f766aa8a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/880d3ac6-2973-4773-ac34-5e5b2b9bdc83%40googlegroups.com.
Does the method signInWithPopup have the same behavior (meaning, call it again to get into the onAuthStateChanged callback)? I'm getting strange behavior on one browser where I can't login and am falling into the error callback. It is tricky to troubleshoot. It works on other browsers and devices.
Is there an example bit of JS code that handles the initial login and then the next time the user comes back the same code does not need to do the pop-up and can retrieve the user information? I'm not finding a way to do this and not sure from the documentation how to write my code.
--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/f0fdc142-74d1-4e16-ad8a-8702e8276d65%40googlegroups.com.
For both of the above (native app and web client), I've exposed respective APIs that use the JWT (obtained by authenticating) as an API access token. So I validate the token on the server-side, and, if valid, respond appropriately. However, outside of an hour, the original token that was obtained "client-side" (including in the case of the native app) is no longer valid, as the expiry window has been exceeded. So in this case, I'd like to use the refresh token to obtain a new JWT on the client-side, valid for the next hour, and re-issue the request.
What I don't want to do is have the user re-authenticate (or otherwise bother the user). Keep in mind, as I've mentioned above, the user hasn't refreshed the page or closed the native app respectively. Is there a better or more robust way of doing this than to initialize a "setInterval()" for maybe slightly under one hour, at which point I'd use the "forceRefresh: true" option to get a new token?
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4313d3b5-1d39-4f33-bc9a-d1bccd85e240%40googlegroups.com.
Keep in mind that this happens automatically. You shouldn't need to refresh the tokens on your own.
Note that once the token is verified at your server, there's no reason to be concerned about it expiring. Your server should utilize the admin SDKs (perhaps with limited privileges by uid) and not try to authenticate as a client, and thus when the token expires, as long as you've already verified it's validity, there's nothing to do here.
One simple way to avoid this mess on the server is to have the clients write to the database and have the server listen there, instead of exposing RESTful APIs and such. See firebase-queue for a good strategy here. Since security rules enforce authentication, your server doesn't need to handle all of this verification; if the client can write to a given DB path, they are verified according to the rules you've set there.
onAuthStateChanged() will be called whenever authentication state changes. Thus, if the user is signed out or signed in at any point after the app starts, it will get invoked with the new user object (or null in the case of a sign out event). This can obviously happen after the app is initialized, thus the subscription model rather than a one-time callback.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4313d3b5-1d39-4f33-bc9a-d1bccd85e240%40googlegroups.com.
Returns the current token if it has not expired, otherwise this will refresh the token and return a new one.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0159fe53-d216-4412-a36e-0013d18113e2%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0159fe53-d216-4412-a36e-0013d18113e2%40googlegroups.com.