i have created an app in react and firebase for auth used react-redux-firebase to manage state of app . after login the system i can access user state and accordingly sign the user in. but my concern is the state doesn't expires or cleared if app not used for long time and remains until not logged out .i want to clear the state if not app not used after n days.
firebase token expires in 1 hour , so do i have to call firebase onauthstatechanged listener with every call for a token or keep a timer every 50-60 min to refresh the token?? i dont know which way to go with or is there any other better way ?? or any other better authentication flow for the app!
The Firebase SDK automatically refreshes the user's auth token every hour. You don't have to write any code for that. You only need on onAuthStateChanged listener for the entire app - it will always stay in sync with the user's sign-in state, and you also write no additional code for that.
Related
I have a fullstack (React & Spring Boot) app and use JWT token. When user login, I set the jwt token and user details in local storage. However, when I restart the React app, the localStorage values are not reset or clear. I also set token expiration to 1 minute for testing on Spring Boot app, but still the same problem.
So, how should I reset localStorage values on every initialization of React app?
Hey everyone Im trying to figuring out how I can disable and logout out a user correctly.
After researching I found out that in that way we disable the user .
const user = await admin.auth().updateUser(userUid, {
disabled: true,
});
But the question I have is, what is if the user is still logged in in the app? I tried out and nothing happened, the user can still use the app after disabling him. So what can we do about that? I was thinking about logging the user out with firebase function. My app is written in flutter backend is firebase.
Being signed-in to Firebase is based on an ID token. By default such a token is valid for an hour from the moment it was minted, and the token itself cannot be invalidated during that time.
The user will remain authenticated (for up to an hour) until their ID token needs to be refreshed. At that point they'll be logged out and won't be able to log in again.
If you want to block their access before that ID token refresh, you will need to do that through some other mechanism, for example by keeping a list of disabled UIDs and checking against that.
I recommend checking out the Firebase documentation on managing user sessions, specifically the section on detecting ID token revocation.
This topic has been covered before, so I recommend checking out:
Firebase Authentication State Change does not fire when user is disabled or deleted
Why firebase user still signed in after I deleted it from firebase dashboard
Deleted user has access to Firebase Firestore
And other questions on [firebase-authentication] disabled or deleted user still being signed in
Currently I'm working with -
Django REST Framework
Angular 5
RxJS +
OAuth2
The list of paths of all components except the LoginComponent I have AuthGuard where I check whether the data on the token and the user in the localstorage of the browser.
If data is available I will return True. But as soon as the token expires, I can't do anything with the user.
If I get a 401 code in the service, I can't even redirect the user to the login page since I can't use the router in service.
Basically I am wondering how, when and where to update the token in my web app?
Kindly give some knowledge on how to work with tokens. Also it would be helpful if any code example is provided.
You question is too broad, and opinion-based. But if you want a thrid party point of view, here are my two cents :
Storing the Token
Depending on your application, you have several ways of storing a Token.
LocalStorage
The first solution, the one you used, is storing it in the local storage. This way, the Token will remain on the device as long as you (or the user) doesn't delete it.
Session storage
The session storage will behave same as local storage, except that the token will be deleted once the user closes his session.
Service storage
Last option : storing it in a service : your token will remain as long as your user stays in the scope of Angular (meaning, doesn't reload or change tab).
How to chose ?
Depends on your application. If you make an application involving high risks after login, then you should consider using the session storage, so that the user gets "removed" as soon as he leaves the page. For a casual application, stay on the local storage. And if you REALLY want to lock your application up, use the service storage.
When to store the Token
Seems obvious, but you should store it when the user logs in.
Update the Token
You should not have to do that. The Token matches an user, or an user session. The only update you should do is a deletion, not a rewrite.
Where to update the Token
In a service dedicated to Token management. This is the best practice.
More information
You said you had an Auth Guard. This is a good practice. but yes, you can redirect the user from your service. Why wouldn't you ? That's the usual way of asking an user to connect ! Use the router in your service, really, there's no issue with that.
From my point of view, and what you described, except for the routing in a guard, you're doing it pretty well. The only advice I would give you is to handle an expiration date on your token, if your application is high risk profiled (and you have to use the session storage).
I have a Firebase app using the javascript web SDK. Our clients are using the custom authentication method. We have implemented a presence system using onDisconnect. We are seeing that onDisconnect fires once every hour, and in most cases the client didn't actually disconnect. This is a problem for us because we are tracking and presenting connect/disconnect events for our clients, and it makes it look like the clients are disconnecting when they aren't.
My guess is that there is some sort of authentication token refresh that is happening every hour, which causes onDisconnect to fire. However, I don't know how to dig in deeper to confirm that or find a different root cause. Can anyone help me figure this out?
It was suggested that this is a duplicate of this question, but that is about basic onDisconnect operation, and this is about a repeatable observation that onDisconnect fires every hour although the client has not disconnected.
I have no idea how this onDisconnect function is implemented. It would be helpful to explain how you determine the disconnection. Firebase Id tokens expire every hour and need to be refreshed (automatically refreshed after when calling any user method). If you are using real time database, they will try to refresh on expiration. You can add a listener in onAuthStateChanged when a token is issued and set a timer to automatically refresh the token (getToken(true)) before it expires, ensuring the disconnection does not trigger.
Also, the onDisconnect will fail during that disconnection because Firebase consider the token expired.
Since you're using Firebase Web SDK, you could obtain current token and check its expiration timestamp by calling:
firebase.auth().currentUser.getToken(false); // pass false to retrieve cached token
You could setup interval to periodically check the token expirationTime and try manually refreshing token just before it expires (for example 60 seconds before it expires) by calling:
firebase.auth().currentUser.getToken(true); // pass true to force token refresh
This should prevent onDisconnect event (.info/connected listener) from firing due to token expiration.
I believe the onDisconnect firing every hour is a bug in the Firebase JS SDK. Normally Firebase Auth will proactively refresh the token before it reaches expiration if consumers such as a database connection exist. If the refresh doesn't happen automatically, the connection gets closed at expiration, and the subsequent reconnect will request a new token, causing it to be refresh then.
I've confirmed that manually starting the proactive refresh logic avoids the hourly disconnect.
I've filed a bug against the SDK: https://github.com/firebase/firebase-js-sdk/issues/5498
Currently my application is making use of the authorization state change callbacks to indicate moving between the authorization and the main page sections in my app. (Note: I am not using AngularFire)
In Firebase 3 there is firebase.auth().currentUser however the currentUser is set to null if firebase hasn't finished pulling the data from the server. This value may be null at startup but be set 2 seconds later without the user doing anything with the application.
In my app, the users authorization state should be the determining factor of the first screen that they see, because this is asynchrnous in nature, they're seeing the Authorization page, then after the currentUser updates it's moving them to the home page, which displays a very tacky page switch.
Splash Screen -> Login -> Home
The amount of time on the Login page depends on the internet connection, however on mobile data it is extremely noticable.
Is there any way to force a check to see if the user is logged in that will return true or false? I can make an asynchronous method into a promise, the issue is that the onAuthStateChanged callback isn't called on startup if the user is logged out already.
No. Use .onAuthStateChanged to determine the users Auth state.
In terms of the login showing / blinking prior to currentUser that is an issue fixed by modifying your HTML/CSS. The default view should not display the login elements. Only display that after .onAuthStateChanged tells you the user is not logged in.