I learn Firestore and have beginner question.
If I have a web site that connect to Google Firestore Cloud datastore and the website is pulling documents from the Cloud datastore like name: value json struktur.
Is then the website a "user" or I mean do the website need to sign in even it has apikey?
I read Get started with Cloud Firestore Security Rules and can only see settings that need a signed in user!
I want a website to pull this name: value from Cloud datastore that all I want?
Here is the rules:
service cloud.firestore {
match /databases/{database}/documents {
match /<some_path>/ {
allow read, write: if request.auth != null;;
}
}
}
looks like I must make some Auth for a user not a website?
Please advice!
The answer is that one must be signed in to be able to secure Firestore databas and if a website dont want to force users to sign in the website can sign in(under the hood)
anonymous and if the user decide to sign in later the anonymous account then with the help of linkWithCredential transformeds to the users own account like Google or Facebook sign in.
You can use Firebase Authentication to create and use temporary
anonymous accounts to authenticate with Firebase. These temporary
anonymous accounts can be used to allow users who haven't yet signed
up to your app to work with data protected by security rules. If an
anonymous user decides to sign up to your app, you can link their
sign-in credentials to the anonymous account so that they can continue
to work with their protected data in future sessions.
Authenticate with Firebase Anonymously Using JavaScript
With your security rules, a user that accesses Cloud Firestore directly from the client-side code using one of the Firebase SDKs, will have to be signed in to Firebase Authentication. This applies no matter whether the client is a native mobile app, or a web site.
If you have server-side code that accesses the same Firestore database using either one of its Admin SDKs or its REST API passing administrative credentials, that code actually bypasses these security rules - so is not bound by its requirement to be signed into Firebase Authentication.
So if you render the web site server-side and read from the database in that same server-side code, there is no need for the client-side user/code to be signed in to Firebase Authentication. But if the client-side code is directly accessing Firestore using one of its SDKs or its RET API, the user will need to be signed into Firebase Authentication.
Related
I want only people whom I register or with specified email should be able to use google sign in, rest are not allow to sign in.
example:- I run a institution and I have separate id for my fellow students and I want them to only be able to sign in using that id and otherwise they should not be allowed to use any other Id(email to be more precise).
in my flutter application using firebase-> google_sign_in.
hope I am clear!
bro add some g mails in your firestore those people you want they can access my app if this emails exist in your db then they can google signin otherwise show toast your account is not regirsted by admin
try{
FirbaseFirestore.instance.collection("alloweduser).doc().where("emial",isequalto:123#gmail.com).then(){
Goolglesinin()
{
google signcode
}
}.catch(e)
{
showToast("ask admin to app permission")
}
You are talking about authentication vs. authorization.
Authentication: Since google is your authentication provider... anyone with a valid google account is authenticated.
Authorization: Who has access to what parts of the application?
You need to implement an authorization system / flow to determine if an authenticated user has access to the app. By default... all users will have NO ACCESS.
How you implement authorization - depends on your backend and how you store user data. If you are using firebase, something like this will help: https://firebase.google.com/docs/firestore/solutions/role-based-access
For example is there a way to issue a JWT or something from my server to let them have access to a particular document, without requiring them to go through Firebase authentication? I'd like them to be able to read directly from Firestore but not require an account to do so, while not opening up the document to everyone.
Firestore does not offer any forms of authorization that aren't related to Firebase Authentication. Or, in other words, Firebase Auth accounts are the only supported mechanism to distinguish which individuals can read and write documents.
It sounds like you should probably create your own backend endpoint that accepts a token, check it for validity, and determines if the bearer of that token should be able to read the contents of the requested document. The backend would have to perform the query directly, and it will be able to bypass security rules.
Iam working on a flutter mobile application where i use Google SignIn for Auth, is there a way to authorize users with existing account only?
Prevent users from creating new accounts? I've looked for the same thing without finding a way to do this with any Firebase project setting.
The solution, I believe, is consider the difference between authentication and authorization. Firebase's Authentication service is aptly named. It does authentication
- validates that a user is actually who they claim to be. It does not do authorization - control what actions authenticated users are allowed to perform or what data they can access within an application. App developers have to be responsible for managing user authorization.
One way to do this is to maintain a collection of "authorized users" in Firestore, for example. When a user authenticates, your app would perform a lookup to see if the current user is actually authorized or not. Security rules can be written for Firestore and Firebase Cloud Storage to also validate that the current user is in the "authorized users" collection before allowing access to data. But this requires extra data queries to obtain this authorization info.
The authorization method I prefer is to use Custom Claims which can be assigned using the Firebase Admin library. A custom claim can be added to an existing user account that can act as a flag indicating what type of authorization they're granted. Front-end code can check the authentication token they've been issued for the custom claim to determine the authorization they've been granted. Server-side code and security rules can also check for those required custom claims within submitted requests.
Realistically, any application you build where different users might have different levels of access will require you to deal with authorization. I believe that assigning carefully thought-out custom claims is the best solution.
Am a bit confused about the One tap sign in that was announced by google earlier this year. Our application already users Credential Management API in Chrome, which essentially provides the user with login options based on the credentials that user has saved for our site on previous visit (passwords that are saved in chrome). When I read the documentation for One tap sign in, it promises to do the same thing, but using Google's client api id. Our application has its own ID provider with our own database of user name and passwords, from the documentation it looks like One Tap sign in does not support custom ID providers. Can anyone shed more light on this, why would I use one against the other?
Thanks
Karthik
I see two major differences:
One Tap is passwordless - it uses a token based login that never exposes the user's password. Chrome Credential Management API stores and retrieves actual passwords in Chrome's password store.
One Tap is purely web based - Chrome Credential Management API relies on Chrome's specific implementation. One Tap is a purely web based workflow so it will work across browsers.
One Tap is a much better long term login solution in my opinion. The Credential Management API is experimental and currently only supported in Chrome.
https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API#Browser_compatibility
I lead product development at Google for the one-tap/auto sign-in library, we designed it such that the library includes the Credential Management API and extends to provide assistance in account creation, secure passwordless, and cross-browsers support.
In particular, if you make a request for existing credentials with code like this:
googleyolo.retrieve({
supportedAuthMethods: [
"https://accounts.google.com",
"googleyolo://id-and-password"
],
supportedIdTokenProviders: [
{ uri: "https://accounts.google.com", clientId: "CLIENT_ID" }
]
});
then any saved username/passwords from the Credential Management API will be returned (in browsers supporting the API) along with token data for Google Accounts. The one-tap/auto sign-in JavaScript library wraps the Credential Management API for credential retrieval.
Furthermore, the library provides a googleyolo.hint method to show an email selector for one-tap selection of a verified email address to assist in new account creation, or to link to an existing account, and then be auto signed-in next time with token instead of password, across all browsers, so long as the same Google Account is active.
I'd suggest using the one-tap/auto sign-in library and consuming tokens as well as passwords in order to get assisted sign-up, keep existing users signed-in automatically, and provide functionality even if the browser does not support the Credential Management API.
As for the question about using your own database of username / password, the hope with this library is you could implement the ability to create accounts and auto sign-in to these and existing accounts with an OpenID Connect ID tokens representing the user's identity. With the one-tap / auto sign-in UX, these are not only much more usable, but far more secure then passwords and mitigate creation of weak/re-used passwords. Please consider this or, even better, a hosted auth solution like Firebase Auth or Auth0 and include the one-tap UX in the frontend UI.
Can Google Sign-In be used on an iPhone app in conjunction with Touch ID? If so, how? I cannot find any examples of this being done or talked about online.
Apps can incorporate TouchID as a means to locally authenticate a user.
Basically, the TouchID system can be queried and will let you access items in a keychain or do a simple one-off authentication.
If you stored Google account credentials in a local keychain, you could use TouchID to unlock the local keychain item, and then pass that item to a Google service for Google's authentication.
The keychain item in question (a password) would have to be enter manually at least once by the user (and at that point, it is probably more straightforward to just request an reusable authentication token from Google).
TouchID is entirely a local system, no fingerprint data is ever exposed to third party developers or pushed to a network, so Google couldn't store a fingerprint in their servers and allow direct authentication against their services using TouchID.
Here's the framework reference for Local Authentication:
https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/index.html
The Local Authentication framework is best suited for either confirming a logged in user in an app where the user may be logged in between many sessions (such as for a purchase in a shopping app) or local authentication for local documents (such as for password protected note taking apps).