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.
Related
I am not sure what code I need to share but it appears so that every-time I login, my firebase-functions session is maintained across that very tab, meaning if in my browser, I have logged in through one tab and open a new tab, i need to login again.
How can I make my firebase function session consistent i.e if open in one tab, I don't need to open across another tab.
This is thread which seemed relevant but it's been some time since OP posted it.
https://groups.google.com/forum/#!topic/firebase-talk/zkrJsCh0_sw
If I'm interpreting your question correctly, you
have a Firebase app that allows users to log in, and
you want a logged-in user to be able to open a new tab, and automatically be logged in there as well
You can do so by adding the following line to your front-end code, at a place where the Firebase SDK is initialized and available:
firebase.auth().setPersistence(firebase.auth.Auth.Persistence.LOCAL);
Instead of LOCAL at the end, the other two options are SESSION and NONE, each of which gets progressively more restrictive with how it allows users to remain logged in.
Note that LOCAL is the default, so you may wish to check whether this setting has already been changed elsewhere in your code.
Note also that the capital letters are correct.
You can read more about the options and see a more detailed example of how to implement this code at the official Firebase docs on persistence
If that's not what you're asking about, you may wish to consider clarifying your question to indicate how my assumption 1. or 2. are incorrect. Cheers!
Since I have noticed that once a user signs in with email and password, on reopening the application the session will not have expired and there is no need for a new authentication, I wish to avoid this.
I want to automatically .signOut() a user when .onDisconnect is triggered. How can I achieve this? I have tried with the following code, but unsuccessfully:
firebase.auth().onDisconnect().signOut();
When you say "onDisconnect", I'm assuming that you mean Realtime Database onDisconnect triggers.
The first thing to know about onDisconnect is that it triggers when the socket connection between Realtime Database and the client app is closed. This could happen for any number of reasons, and it can happen at any time, even if the app seemingly has a good internet connection. So, be careful about what you're trying to do here.
Also, onDisconnect triggers can only affect data in the database directly, and nothing else. So, this limits what you can effectively accomplish. You can't perform any action in the client app in response on an onDisconnect.
Between these two facts, what you're trying to do isn't really possible, and, I don't think it's desirable. You could end up logging out the user just because their train went underground momentarily, or if they simply switched out of the application for some time. This would be massively inconvenient to the user.
If you want to automatically log out the user, I strongly suggesting finding some other way to do this, such as writing some code to remember how long it's been since the user used your app, and forcing the logout on the on the client app based on your preferred logic.
The onDisconnect() is related to the database connection, and has little to do with your authenticated user. As in: onDisconnect() may fire when your user is signed in, simply because the connection to the database drops temporarily.
But more importantly: onDisconnect handlers run server-side, once the server detects that the client has disappeared. When this is because if a dirty disconnect (e.g. the app crashes), there is no way for the client to detect this anymore.
The most likely approach you'll want is to simply sign the user out when they close the app.
Alternative you might want to attach a listener to .info/connected in your client. This is a client-side listener that fires when the client detects that it is connected or disconnected.
How to restrict the page by accessing only one user at a time. Using asp.net can i use global.asax, is there any other way to restrict, if one user accessing the page, another user not able to access that page. we have to give message that one user is accessing the page. is it possible. can you help me or give some reference.
Although there are probably many better ways of dealing with this sort of problem, I'm going to assume that you do actually need this.
What I would do:
Make your application so that when the page is loaded(when it isn't "locked"), it logs to a database that the page was loaded and "lock" it. In the actual page, I'd have some kind of AJAX to constantly poll the web server every 5-15 seconds to tell your application the user is still on the page. And then make it so that the page becomes unlocked after 5-15 seconds from the time saved to the database by the last AJAX call.
Again, I really suspect that there is a better way around an issue like this, but this is a direct answer to your question
Based on this:
yeah sure, jupaol, it is depend on accounts, in my web application, one report has to approve only one user, but the approve authority having two users. if both of them accessing the same page and approve at a time, it will big mess. here i an not using database.
The problem is related with concurrency, there are several ways to face an issue like this, for example the easiest one is to use optimistic concurrency. Even when you are not using a database for this, you can emulate it.
You should be storing the result of the approvers somewhere, in order to mark the report as approved, with this in mind you should be able to do something like this:
Before render the page get the latest report status
If the report has not been approved, render normally
If the report was approved seconds before, render it in read-only mode reporting who approved it (or similar approach)
Add a validation to your ChangeStatus method, in this method do the following:
Get the latest status of the current report
If the report is still not validated, then block the thread (you could use a Mutex or similar) and mark the report as validate it
If the report was already validate it, raise a domain exception and handle it in your page correctly (perhaps render the page in read-only mode explaining that the report was already validate it)
If you want a more responsive application, (RIA), you might want to consider the following approaches:
Perhaps this would be the worst approach but it's still an option, you could keep a log tracking when a user request your page, then in subsequent requests check if the log is still valid, if it is not, then redirect to another page indicating the page is in use, otherwise allow access to the page. I believe this is an error-prone approach because you would be relying on this simple validation in order to prevent an inconsistency in your system, besides you would have the polling problem described in the following approach
Using AJAX to poll data from a service checking if the report has been approved. Perhaps this is the easiest way to accomplish this but it is not recommended it, because you would be polling your server constantly, and eventually you would have scalability problems
You could use Comet to get notified to the browser (client) whenever a server event has occurred, in this case when your report has been approved. The problem with this approach is that you have to keep an opened connection with the server in order to get notified.
The last approach and the most recommended these days is to use Web Sockets, this is the technology used in StackOverflow to get notifications in real time.
How do I disable offline caching for firefox in ASP.NET or in IIS? I found this post:
Disabling browser caching for all browsers from ASP.NET
This doesn't address the issue completely. It just disables caching from the back button (when not in off-line mode).
Here is a simple scenario:
If user A logs on to his bank. User A is doing transactions and he even goes to update some personal data. Finally user A is done and logs off from his bank website. User A leaves the browser on, because he has another tab open downloading a file that is a few gigs. User B would like to go on to his email to send out some emails, so user A doesn't close the browser. He knows the security risks, because he has read what must be done once you log off of the site, but he doesn't want to stop the download. For user A, to have to redownload is too much time for him and well he is just your typical user and doesn't think user B (being a good friend of his) will do anything malicious. So then user B uses the browser. The first thing user B does is "work offline". User B now has all data from user A. The page has an off-line cache for user B to see. User B is now able to open the history to view those cached pages, or just simply click back if the page was left open (either way works). User B now has all the pages that user A has browsed to. So any sensitive data is now his.
Does anyone know if this is possible to control at the server level. I know in firefox you go to about:config, but that is not an option for the server to tweak. Even so this can be told to the user, but not every user is going to be able to do this (being too complicated for some users) or some users will just ignore the warnings out of laziness or just not reading what the page says. I know there will be that one person that will say, "oh well that's their own fault and they deserve that". I honestly think ignorance in this sense is not the user's fault. Consider an older person in their 80s who is not technology-centric (like my father who I constantly give him the do's and don't's about online, but he still doesn't really understand the risks completely).
So I reiterate again, is it possible to disable this kind of off-line caching at the server level? I also found this post:
http://forums.asp.net/post/1386380.aspx
Would this help at all? Any help please. Please be constructive and not start a debate. I think I have been very clear, and I have done a lot of research on this with no luck. Please note that only the off-line caching on firefox is what is giving the problem, on every other browser (or on firefox onlinle) the caching has been disabled as expected.
Update:
I actually already have what the last link suggests (http://forums.asp.net/post/1386380.aspx) and it still doesn't prevent the problem.
Disabling cache from server side is kind of impossible because server can only request the browser to not store in cache. Rest is up to the browser to follow it or not.
The best option is not to send the data to browser , so it is never cached, instead fetch it on demand using json/Xml or any thing you are comfortable with.
The only trick that worked for me was to remove all sensitive information from loading via regular page methods, and load it via ajax/jquery on window.ready event. Once I implemented callback and ajax the back button and 'work offline' problem got solved but rolling out that with ajax callback was really a big task.
The reason I'm asking is because, right now we already have it setup to prompt users to share things if they're connected. But the biggest problem we have is that without the user being connected, it tries to make a popup window — which is blocked in most browsers. (vs. the iframe inline)
So, I'm trying to see what the benefit or difference in us implementing the new changes if we're already doing "timeline-like" sharing. I don't get it? Do we have to recode everything?
Last, off topic, but I'm confused about the way the referral API works actually, because the same code doesn't seem to invoke the API at all. Just display the user's name
You need to get the users "publish_actions" permission to add things to timeline. So in that sense, yes, they do need to be connected. But the advantage of that is that once you get "publish_actions" permission, the user never needs to be prompted... you just automatically share the actions they've taken by making api calls.