I am having a react application with firebase as authentication. My authentication code is below
await firebase.auth().onAuthStateChanged((user) => {
if (user) {
props.setUser(user); //setting the user if login/register happens
history.push(`/admin/dashboard`);
console.log("user",user)
} else {
props.setUser(null); //blocks the user to get into the app if he/she is not logged in
history.push("/");
}
});
So, when user logs in..he will be navigated to /admin/dashboard. suppose when am in /admin/home and when i refresh the page, it goes again to admin/dashboard which shouldn't happen. so I tried
history.push(${props.location.pathname}); it works correctly after the refresh, it stays on the same page when the application is logged in. but when I restart the server again when I try to log in, it says no redirect url is specified. Got stuck on this for a long time.. Any help is welcome.Thanks
What your code does is check if the user is logged in and only let the user access the data if so.
You should do that in the fireabse rules (= serverside) as this is way more secure.
You didn't provide the kind of FirebaseDB you are using. So assuming you use the Realtime Database here are some according rules:
{
“rules”: {
“.read”: “auth != null”,
“.write”: “auth != null”
}
}
You should maybe check the rules before deploying your app, because now every authenticated user can change/add/delete data, but you get the point. This does exactly what you want so you won't even need to perform a check in your ReactJS App. Firebase will automatically deny unauthenticated users the access to the database.
Btw: You should try to implement security relevant things in the Firebase Rules. Ideally you want your rules to be written in a way that you don't need to perform any validation inside your ReactJS app. Firebase rules can get quite complex. I experienced that myself when writing a chat app with chatrooms and everything. But it is definitly worth the effort if your app is more secure after.
Related
I saw a question at this link because I have a similar situation and I wanted to comment but unfortunately I do not have enough rep to do so. I would like some clarification on it.
in Tor Arne Falk's question : He displayed a script that he used to manage logged in users and logged out users like so ⬇️
<script>
const auth = firebase.auth()
auth.onAuthStateChanged((user) => {
if (user) {
document.getElementById("body").style.display = "block";
} else {
window.location.replace("/login.html");
}
});
</script>
My question is do you put that script in every html after auth ( & except auth) to check if a user is logged in or not to display content in that page after logging in or redirect them to the auth page
further more Firebase is a type="module" so a common issue with modules is that we cant import firebase outside a module meaning we cant read data from the firebase.js (handling auth & database) to a different script, example: using Tor Arne Falk script (as is) on different html pages for the same cause I believe it will not work.
please share some ideas on if it possible to read data outside the module I would like an example to help me get started if not what should I do within my firebase.js file to ensure a user is logged in across every other page to prevent them from hitting the back button and seeing that that they are still logged in or link jumping (skipping my auth page and going to a page only logged in users are supposed to see without logging in) I hope I make sense!🤔
I recently moved from the deprecated gapi.auth2 to the new Google Identity Services, using the javascript client library, and noticed a big difference: if someone signs in, and then reloads the page, the session is lost, and has to sign in again, every time the page is loaded. This was not the case with the deprecated library.
The problem can be easily reproduced with the Calendar API example.
Is there any configuration option to keep the session persistent? Or do I need to store the access tokens somehow? I could not find anything relevant in the official docs.
UPDATE:
The migration guide states the following:
Previously, Google Sign-In helped you to manage user signed-in status using:
Callback handlers for Monitoring the user's session state.
Listeners for events and changes to signed-in status for a user's Google Account.
You are responsible for managing sign-in state and user sessions to your web app.
However there's absolutely no information on what needs to be done.
UPDATE 2
To be more specific, the actual issue is not making the session persistent. Managing the sign in state and user session is something I can solve.
The real problem is the access token used to call the Google APIs.
As mentioned in the comments, the access tokens are 1) short lived 2) are not stored anywhere, so even if not expired, they do not persist between page reloads.
Google provides the requestAccessToken method for this, however even if I specify prompt: '', it opens the sign-in popup. If I also specify the hint option with the signed in user's email address, than the popup opens, displays a loading animation briefly, and closes without user interaction. I could live with this, however this only works if triggered by a user interaction, otherwise the browser blocks the popup window, meaning that I cannot renew the token without user interaction, e.g. on page load. Any tips to solve this?
I faced all the same issues you described in your question.
In order to help:
Google 3P Authorization JavaScript Library: in this link we can check all the methods the new library has (it does not refresh token, etc..)
This doc says the library won't control the cookies to keep the state anymore.
Solution
Firstly I need to thanks #Sam O'Riil answer.
As Sam described: "you can somehow save access token and use it to speed-up things after page reload."
Given the the Google's exampe, we should call initTokenClient in order to configure the Google Auth and the requestAccessToken to popup the auth:
tokenClient = google.accounts.oauth2.initTokenClient({
client_id: 'YOUR_CLIENT_ID',
scope: 'https://www.googleapis.com/auth/calendar.readonly',
prompt: 'consent',
callback: tokenCallback
});
tokenClient.requestAccessToken({prompt: ''})
In your tokenCallback you can save the credentials you get somehow, e.g.:
const tokenCallback(credentials) => {
// save here the credentials using localStorage or cookies or whatever you want to.
}
Finally, when you restart/reload your application and you initialize the gapi.server again, you only need to get the credentials again and set token to gapi, like:
gapi.load('client', function() {
gapi.client.init({}).then(function() {
let credentials = // get your credentials from where you saved it
credentials = JSON.parse(credentials); // parse it if you got it as string
gapi.client.setToken(credentials);
... continue you app ...
}).catch(function(err) {
// do catch...
});
});
Doing it, your application will work after the reload. I know it could not be the best solution, but seeing what you have and the library offers, I think that's you can do.
p.s.: the token expires after 1 hour and there is no refresh token (using the implicit flow) so, you will have to ask the user to sign-in again.
I am building a login page in my React app using firebase (sign in with google redirect the user method)
and it is working but it takes almost two seconds for firebase to get the current user, which is not the best for UX.
here is the code
componentDidMount(){
console.log(Date.now());
const auth = getAuth();
this.authListener = onAuthStateChanged(auth, (user) => {
if (user) {
// User is signed in
console.log(Date.now());
this.props.dispatch(addUserAction(user.email))
}
else {
// User is signed out
this.props.dispatch(addUserAction(null))
}
});
}
what i get in my console is that the difference of time is 1768 milliseconds which is almost 2 seconds,
am i doing something wrong ?
the console is showing the difference of time as 2 seconds
When you restart the app/reload the page, Firebase automatically restores the user's authentication state based on the information it stored in local storage when the user first signed in. For this it does make a call to the server though, to check whether the credentials are still valid - and for example to ensure the account hasn't been disabled. It's likely that this call is what is taking time in your use-case.
A common trick is to make your own determination on whether the server-check is likely to succeed based on only client-side information. For this, store an extra value in local storage when the user signs in successfully, say isAuthenticated. Now when you reload the page/app, you an read this value from local storage, and then the user was previously authenticated, assume that they will be authenticated again.
The assumption may be wrong of course, so you'll have to handle that scenario too in your code.
Also see this talk Architecting Mobile Web Apps, where Michael Bleigh talks about the technique.
I have managed to setup a custom login system using Firebase. The user enters email/password and is redirected to the main page(which is private). I am having issue with onAuthStateChanged after logging in. When I check the auth state after logging into the main page, i get invalid user (null). The firebase dashboard shows I have logged in successfully but onAuthStateChanged is the opposite.
I am trying to check if a user is logged in to my html pages, if not I want to redirect them to the login page. I like how the authentication works in firebase but I need to protect my html pages not my divs (which is what the vast majority of firebase auth tutorials show).
If anyone has an easier way to password protect a web directory that looks nicer than HTaccess, please advise (I am not crazy about using wordpress for password protection, but its an option). Otherwise, I guess I will have to do this in PHP. Thanks in advance!
(function () {
firebase.auth().onAuthStateChanged(function(user) {
if (user) {
// User is signed in.
console.log(user);
console.log('A user is logged in.');
} else {
// No user is signed in.
console.log('Invalid user. Redirecting to root.');
window.location.replace('../index.html');
}
});
})();
If you navigate to a new page, Firebase will have to initialize again. As part of that it will try to restore the user's authentication state, but this requires a call to the server which takes time.
For that reason the onAuthStateChanged listener will initially fire with null as the current user (and auth.currentUser is set to null). Then once the user is signed in, the listener fires again with the user object for that user.
If you want to detect this initial state, you can either store some token value in the browser's local storage that you can check for yourself on the new page, or you could set a time-out for when you expect the user to be re-signed in and only then navigate away to the index.html page.
I am not really a web app developer and I would like to ask about best practices for gating website content.
I am preparing to deploy documentation created with mkdocs. It uses Netlify Identity because with that Github auth is available without any coding.
My current solution: I have added the Netlify Identity script in head and the login/logoff button via template addons in mkdocs, and then created a static document /login/ (that gets picked up automatically in mkdocs but does not get generated with template).
In the standard template there is a JS redirect to /login/ unless user is logged in:
if (window.netlifyIdentity) {
window.netlifyIdentity.on("init", user => {
if (!user) {
document.location.href = "/login/";
}
});
}
On the static page there is a redirect to / only just after user has logged in:
if (window.netlifyIdentity) {
window.netlifyIdentity.on("init", user => {
if (!user) {
window.netlifyIdentity.on("login", () => {
document.location.href = "/";
});
}
});
}
I hope this is a reasonable way to go about it. The docs do not store anything critical but I still wouldn't want that content exposed.
But I have noticed on slow connection the redirect takes a second or two so when a deep URL is accessed the content flashes on the screen before login.
What can be done to stop this and load the content only after the login check is performed?
This is not going to work as you desire and is not secure.
If I wanted to read your content without an account, I could simply disable JavaScript in my browser (a few mouse clicks) and your site would load, but the redirect would never run.
Regardless, with JavaScript enabled, the way it works is that the browser downloads the page, then downloads any resources (including scripts), and then finally runs any scripts. There is no way to change that. Of course, on a fast system, the user may not perceive a delay, as the delay is very short, but there is always a delay. That is how browsers work.
If you don't want your users to have access to the information until after they are logged in , then you must not send the information out until they are logged in. In other words, you need to configure your server to not send the page at all until it receives verification that the user has permission to receive that information. How you do that depends on which server you are using among other things, which would be the subject of a separate question.
I know this is a old post but you can use netlify functions combined with a netlify redirect file.
You would have to set a role of a user when signing up using the metadata, you could do this with a netlify function thats hooked into netlify identity, more here.
Create a function called identity-signup.js when a user signs up this function is automatically called.
exports.handler = async (event) => {
const { user } = JSON.parse(event.body)
// you could do something with the user here: eg console.log(user.email)
// or using stripe: const customer = await stripe.customers.create({ email: user.email });
return {
statusCode: 200,
body: JSON.stringify({
app_metadata: {
roles: ['free']
}
})
}
}
Once you have a role you can simply create a _redirects file like so:
/authedcontent/* 200! Role=free
/authedcontent/ / 404
Later down the line you can extend the netlify function to save the users detail in an external database or maybe setup a stripe subscription.
The only caveat is that this requires a paid netlify account.