I'm creating a firebase application that uses user authentication, in addition to an express server for video calling with Twilio. Right now, I'm not quite sure how to test signing in multiple users to my application, as when I open different tabs to localhost:3000 both windows redirect to the same location whenever I change the route (using react-router-dom). Therefore, when I try to sign in on a different tab, all other tabs will redirect to the sign in page instead of remaining on the home dashboard.
Could this be a problem with how I'm handling users in Firebase, or how I'm testing with express?
Any help is appreciated.
Firebase Authentication doesn't really support signing in multiple users into a single app instance. That sign-in is shared globally among all tabs loaded with the same site. If you try to sign in a new user, the old one will be immediately and forcefully signed out. This is true on all client app platforms, including iOS and Android.
If you want to test two users signed into your site at the same time, try two different browsers, or use two different Chrome profiles, so that the per-user storage is different for each browser window.
Related
I want to develop a Web App which runs on Firebase where I log in (once) using the providing google sign in.
The App should use the google APIs to display a variety of informations (email, some special calendars etc).
The idea is to have this Web App run on my tablet 24/7 and never touch it but according to this the authentication token will expire after 24 hours which means I need to login every 24 hours.
What is the best way to have a "persistent" login which only expires when the device (or browser) is shut down?
You're looking at documentation for IoT core. Unless you're using IoT core, that documentation won't apply to you
In regular web apps that use the Firebase JavaScript/Web SDK, the ID tokens is automatically refreshed every hour, and credentials are persisted by the SDK and restored when the app restarts.
In practice this means that the user can sign in once, and stay signed in until you either sign them out explicitly, or until a compelling event forces them to reauthenticate (something like their password being changed, or you disabling their account). Unless something like that happens, you can always get the currently signed in user by using an auth state listener.
I have a web application where my users can log in through either user/ pass or Google, using Firestore to manage users/ auth.
I also have a Chrome extension that needs to leverage the same authentication session if possible - i.e stays logged in, token can easily be revoked if needed, and no need to type username/ password into the Chrome extension.
It is easy to do this by grabbing the user logged into Chrome (Not my app explicitly, but in most cases this is the same thing). This works fine using OAuth2.
Reading the docs, username/ password authentication seems to suggest you use Firebase Admin in a server environment to generate and return a token. This then creates more complexity around managing tokens, logouts, and revocation from what I can see.
I am wondering if it is possible to simply share the logged in state between Chrome and the Chrome extension via pushing the Firebase session/auth data in IndexedDb from the browser to the Chrome Extension in a content script? Would this effectively give the plugin the same 'session' as the main browser? Is there any risk in doing this?
Thanks
I want to use Google Pay in a Firebase web app. The user signs in to a Google account in the app. I have tested the example code from Google Developers for this. It seems to work fine.
Except when I sign out from the Firebase app. Then the Google Pay code still seems to work. Obviously now using the account I have signed in to Google Chrome with.
So I do not know for sure which user Google Pay sees. I can test a bit, but I need to be sure. How is this supposed to work? Where is it documented?
It doesn't matter how the web application is hosted (Firebase or otherwise), Google Pay will launch in the context of the currently logged in Google user.
One way to verify is to visit https://pay.google.com/. It will show you payment details of the currently logged in user.
EDIT: Responding with clarifications (apologies for the length)
I want to use Google Pay in a Firebase web app.
Assume that I in this case is you the developer.
Except when I sign out from the Firebase app.
Assume that I in this case is you the user, signing out of the web application and not the Firebase console.
The user signs in to a Google account in the app.
The web app uses a Google identity to authenticate the user - correct?
It seems to work fine.
Except when I sign out from the Firebase app. Then the Google Pay code still seems to work.
Is the scenario that you are describing the following?
User is not logged into Google
User signs into web app with Google identity and is presented to Google login screen
User clicks on Google Pay button from within the app - everything works as expected
User signs out of the web app
User returns to the web app after signing out of the web app?
User clicks on Google Pay button from within the web app as an anonymous user (from the web application's perspective) - which brings up the Google user's payment details and this is not what you expected
If so, then:
Step 2: two things happen
Google sets a cookie to maintain keep track of the user's identity
Google returns an auth token to your app, your app will generally use this to maintain session state using the auth token
Step 3: using the cookie that was set in step 2, Google present relevant payment methods
Step 4: signing out of the web application should clean up the user's web application session state, but it wouldn't sign the user out of Google
Step 6: because the Google cookie is still present, Google Pay continues to present the user's payment details
From my perspective, this is working as intended.
The web application's session is separate from the Google session, think of it as the web application using Google to bootstrap its own session. Once bootstrapped, they are disconnected from one another.
The user could sign out of Google after bootstrapping and that shouldn't affect the web application. If the user logs into Google as different user, they will receive a different Google Pay profile, and they should be able to fulfill payment with the second Google identity's details despite signing into the web application as the first Google identity.
You should be able to verify this behavior by visiting https://pay.google.com/ after signing out of the web app, then again after signing out of Google, and then signing in again with a different identity.
In one of my use cases for my react web application, my user will open the application after following a link generated by a chat bot.
In this case, the specific chat application is LINE, and all links parsed by the chat window are opened by default, in LINE's own web browser.
When the user attempts to login, the login process is halted, in what I believe is the intended behavior, as google has said it has depreciated web-app logins from app webviews in 2016.
Is there any way I can detect one of these in-app browsers and prompt the user to re open the web app in their preferred browser?
If not, does anyone know of a workaround I can use? Would having a secondary, server side authentication route be the best bet?
First off--thanks for having a look.
MY QUESTION
In a .NET web app, is using Windows Authentication for a extra-net on a WAN consisting of various users, companies, user-agents, etc a bad idea?
BACKGROUND
I am lead dev on a fast track (very fast) web application for an extra-net that will allow the client's vendors, suppliers, partners, etc to log on and push and pull certain assets such as image files, videos, flash files, etc.
PLATFORM/TECHNOLOGY
Asp.Net 4.0, C#, MVC3
PROBLEM (Maybe)
The client's IT department has requested that the app use Windows Authentication to authenticate users. One of the reasons for this (they say) is that the assets that will be pushed/pulled by users reside on a third-party server (Signiant) which already uses credentials form their active directory to authenticate users.
MY VIEW
Windows Authentication is going to cause a bunch of headaches. Viewed as a stack, this app will sit on top of the third-party server. So if we use Forms authentication, we can just populate a data table with windows credentials for each user and pass those to Signiant's servers with our requests (you have to do this anyway). If possible, we can even make an LDAP call for the creds on the fly and then pass those to Signiant's servers.
It just seems to me that simple functionality such as "lost password" would be come extremely difficult if we are doing the Windows Auth thing. But, full disclosure, I have never built an Asp.Net app using Windows Authentication so what do I know??
Thanks!
Matt
UPDATE 8/12/11
I still don't have an answer as to whether you should do this, but the client is adamant that it must be this way. The app is supposed to be turned over in a month so I will come back and let any followers of this topic know my findings.
ASP.NET has built in support for doing AD Authentication using Forms Authentication, including password recovery.
See: http://msdn.microsoft.com/en-us/library/ff650308.aspx