I am trying to fix the question I post firestore rules request.auth.token.firebase.identities["phone"] not update on IOS
Currently fix by call firebaseUser.getIdToken(refresh: true); to make refresh update after phone verified and app started.
Would call firebaseUser.getIdToken(refresh: true); every app start be a problem? I think maybe if bunch of users keep fetching ID Token with server will causing server overload or something?
While I don't think it would be a problem, it's not really the best way to go about getting the most recent ID token. If you just want to know the most recently fetched ID token, you can use addIDTokenDidChangeListener() to receive any updates to the ID token whenever the Firebase SDK automatically refreshes it (every hour).
You typically only force a refresh token if you know the custom claims or other information in the ID token have changed on the server, and you need to reload those for use on the client. If this is not your situation, you probably don't need to force a reload.
Related
I'm trying to find a way to retrieve my company updates feed. The question is, is it possible without user login/ interaction?
When searching the docs I found https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/share-api to retrieve this information. But if I'm correct, you can't do this without first logging in (r_organization_social requires 3-legged).
Is there another endpoint that could do this with only a key/secret? Or is the only way for this to work, login and make a cronjob that automatically refreshes the token. With the downside that I need to login again if the cronjob fails.
Some other relevant info, when trying to generate an application token I get the following error "This application is not allowed to create application tokens". But I think this is normal because a 2-legged OAuth is not available for Marketing APIs.
to summarize:
I want company updates feed without user interaction
Maybe using the wrong endpoint
Maybe something wrong with the app creation
Maybe something wrong with generating Application key
Credential docs used: https://learn.microsoft.com/en-us/linkedin/shared/authentication/client-credentials-flow
I have some code I put in my react-native app a couple of years ago to support the forced migration of users from v2 -> v3 authentication. I am using the Web version of Firebase (6.6.0) in my app (NOT react-native-firebase).
I recently had a user try to log in with an old v2 token found in AsyncStorage (local storage). The app crashed with the following error:
TypeError · undefined is not a constructor (evaluating 'new t.default.Promise')
The crash occured on this line of the migration code supplied by Firebase. I'm guessing this migration code is no longer supported and I should just remove it from my app. But what should I do instead if a person tries to log in with a saved V2 auth token? Can she simply log out and log in again? Or does she have to change her password? Or does she have to create a new account, losing her old data?.
I don't have a way to replicate this situation since I have no way of logging in to v2 authentication. So I would appreciate a clarification from the Firebase team. Thanks.
TLDR; I've decided to remove the migration code from my app. When someone fires up the app and a legacy token is loaded from AsyncStorage, I simply delete the token and present the user with a login page.
I corresponded with Firebase auth support and include their answers below. First off, they suggested changing firebase.Promise in the code to Promise as firebase.Promise doesn't exist any more. This fixed the crash. Then, to test, I found an old simulator image that still had a legacy token in its AsyncStorage. Working with that, I found that the response to the XMLHttpRequest to the exchangeToken endpoint result in a null response (after approximately one minute). This tells me the endpoint is dead and there is no point in trying to query it, thus it makes sense to remove the migration code altogether from my app (even if the endpoint were working, a 2-year-old token surely would have expired.)
Then the question is what to do to enable users in this situation to upgrade gracefully. Firebase support suggested I should export the user (I have quite a few but I don't have a way to identify them definitively), then delete the user and import again. I couldn't believe all that hassle was necessary so I managed to find a couple of friends with old accounts. They had both forgotten their passwords, but after resetting, they were able to log in easily. So based on this limited testing, I think all that is necessary is to have them log in again. If that doesn't work they can contact our support and we'll go from there.
EMAILS FROM FIREBASE SUPPORT
I understand you, it must be a very frustrating situation, let’s try to find a solution together. I have checked your case and, as you have mentioned, the library is no longer actively maintained, so I’ll escalate your case to our engineering team in order to get any suggestions for your case, please wait a little until they can answer us.
The engineering team has answered and, unfortunately, they have said that old auth tokens have been unsupported for a long time, they suggested you forked the library and try to change firebase.Promise(), which does not exist anymore and then convert that to Promise(), but they can guess other errors will pop up and probably you will need to fix the code.
Thanks a lot for the clarification, I’m so sorry for my misunderstanding. If you want to delete the migration helper, as a workaround, you can export all the users (or only the users having the old token, if you have identified them), delete the users and import them again. This process will re-create the user and it will have the auth latest version because the user would be like a new user, with the same credentials and authentication methods. After that, the user on his side, needs to update the application, log out and log in again in order to update the token.
Please try to do the described workaround with a specific and identified user to limit the scope in case of fail and let me know how it goes.
Nice to hear from you again! Yes, the users will have the same UID and password, as you can see Auth export, the format contains those data and a lot of other more. Unfortunately, based on this, there is no way to know which of the accounts have an old auth token, so, in order to do a test and error approach, I suggest you try to do this with one user (identified old auth token user) to minimize unwanted results.
I have a server, and multiple clients (web & mobile). When my users log in, I want to start sending them notifications about the content they follow. When they log out, I want to stop sending them notifications.
I've found many Stack Overflow questions that are similar to mine, but none have been completely answered.
The closes to my question was this other question where the accepted answer is to call deleteInstanceId() when the user logs out, which seems like the most solid solution, but in the comments someone copy pasted from the (GCM) docs that "Developers should never unregister the client app as a mechanism for logout or for switching between users". I wasn't able to find the same notice in the new Firebase docs, but I assume that it's the same concept: the InstanceId is not supposed to be user related.
The only alternative I've found, is to send a "signOut" request to my server, with the instanceId, and my server needs to remove the associated instanceId from the user account.
But what if that API call doesn't go through? This seems to be quite a fragile solution.
So this is what I would do now:
Send the instanceId to my server when the user authenticates
Make sure that this same instanceId is not used by another user, since this could happen when the other user logged out on the same device, but the API call didn't go through
When sending notifications, send them directly to the registered instanceIds (initially I had planned on using topics, but in combination with handling my tokens, this seems even more fragile).
When the user logs out, send a signOut request to my API, and remove the instanceId from the user.
Your question seems to just be seeking validation for a design, which really isn't the purpose of Stack Overflow. The Firebase subreddit might be a better alternative for drumming up conversation around the problem.
But I will say that if it works for you, then run with it. Consider also sending the target users's UID in each message, and have your app compare that with the currently signed in user in order to determine if it reached its correct destination. Send a message back to the server if it's not in order to correct the problem.
Update: Due to code refactor, the need for testing that has gone away, and as Ron pointed out in the accepted answer, onAuthStateChange() will fire eventually, and the app can rely on that. I wasn't originally seeing that, which is what motivated my question.
Original Question: I've been using window.localStorage and searching for a key that starts with 'firebase:authUser' as a way to determine if my app can expect a firebase authentication event any time soon. Whether it succeeds or fails, firebase.auth().onAuthStateChanged() is triggered, and I can deal with the result there. The reason for wanting to know is that if I have some local credentials which are being processed, my app can display a 'Please wait...' type message. But if there are none, it can redirect immediately to the login page. Since firebase moved to indexedDB, this code no longer works, and I couldn't find any equivalent hack to look for locally persisted credentials (maybe it's not possible now?).
I'd also be happy to switch to SESSION persistence rather than LOCAL, but I'm not sure if this changes the scenario at all—I'd still need a way to test if there was anything happening to avoid the user being stuck at the 'Please wait...' message forever if there were no local credentials to validate.
Or am I doing this wrong? I know I could show the login page until firebase.auth().onAuthStateChanged() fires, but by then the user might have clicked, and the experience isn't that great either if they already signed in and then refresh the page, where they see the login page again until everything is loaded.
I couldn't find anything in the auth() API to tell if it was in the process of dealing with locally persisted credentials, and up until now, the window.localStorage hack has been working very well. What's the best way to manage the user experience now?
You could grey out inputs and disable submit button until .onAuthStateChanged resolves which happens very quickly, usually in under 1 second. Maybe put a linear progress indicator on the login form?
Relying on underlying implementation is never a good idea instead of provided public API. Firebase has the right to change that at any time. They could have even persisted the user with a different format and that would break your implementation.
That said, you can easily bypass this, by setting your own flag in localStorage when a user logs in and remove it when they sign out. This is better than relying on the hack you had. In this case, you have full control over that flag. You set it anytime a user is signed in after onAuthStateChanged is triggered and remove it on sign out. When a page is loaded you read that value directly to know whether to display the progress bar or not.
I'm serching for a solution for a backend and firebase same interesting, but I have some questions before starting to using it.
My question is related to this post (you don't need to read it) Firebase rate limiting in security rules?
The question was how to be sur the client can do the same request more than 1 time every 5 seconds. The anwser is fine. My question is:
If we assume the client app has no bug and it check if there is no more than 1 request every 5 seconds, the only way we can fail the "validate" is if someone is trying to hack (sending request without using the client app). Is there a way to send a callback to a admin user or to write something in the database to tell someone is trying to write faster than expected and the user is maybe a hacker?
Thanks
Security rule failures are not accessible through an API at the moment.
Look firebase is working on a new feature that will allow me to do that
https://firebase.google.com/docs/functions/
"With Cloud Functions database event handling, you can modify the Realtime Database in response to user behavior, keeping the system up to date and clean."