Because the Snapshot class utilizes the web client library, it relies on their authentication mechanism. The web client libraries integrate with the Firestore database security rules. You can create, review, and modify the rules at the Firebase console. For example:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read;
allow write: if exists(/databases/$(database)/documents/admins/$(request.auth.token.email));
}
}
}
In this example, the rules are set up so that anyone can read the data, but only certain users can make changes. The users are defined using an "admins" collection within the database. The "admins" collection contains the e-mail of users who are authorized to write to the database.
You can use the OAuth2 class to authorize users as we did before when using the Firestore class. The only difference is when using the web client libraries, you do not use the accessToken property as before. Instead, you must create a credential object based on the idToken provided by the OAuth2 class and use that credential to sign with the Firebase client libraries.
import { Snapshot, OAuth2 } from '@grapecity/wijmo.cloud';
// update state when user changes
auth.userChanged.addHandler(s => {
let user = s.user;
oAuthBtn.textContent = user ? 'Sign Out' : 'Sign In';
// update Firestore access tokens
//fs.accessToken = user ? s.accessToken : null;
// Sign in with credential from the Google user.
// https://firebase.google.com/docs/auth/web/google-signin
if (user) {
let credential = firebase.auth.GoogleAuthProvider.credential(s.idToken);
firebase.auth().signInWithCredential(credential);
} else {
firebase.auth().signOut();
}
});
The log in/out experience is the same as before, but you do get some extra flexibility by being able to use and customize the Firestore security rules.
Once the user has been authenticated, they will be able to edit the data in the Snapshot (if his email is in the "admins" collection).