#### Goals - Learn how to protect your Firestore using `firestore.rules` - Learn how to log in users anonymously - Learn how to add password authentication to an application - Learn about React Context providers and `useContext` ## Background In this practical we are going to create a simple message board application. All users will be able to read the board, but only authenticated users will be able to post new content. ## Prerequisites 1. Create the git repository for your practical by [accepting the assignment from GitHub Classroom](https://classroom.github.com/a/PD8XlhJq). This will create a new repository for you with the Next/React infrastructure in place. 1. Clone the repository to you computer with `git clone` (get the name of the repository from GitHub). 1. Open up the `package.json` file and add your name as the author of the package and the URL of your git repository. 1. Install the module dependencies by typing `npm install` in the terminal 1. Once you have everything installed, create a new Firestore project using the "Create a Firebase project with Firestore" steps from [Practical 5](./practical05-firestore). 1. Create a web app in the Firebase console and add the configuration data to `firebase-utils.mjs` ## Setting up Authentication Firebase's Authentication tool is a general purpose authentication manager. _Authentication_ is a way for users to prove that they are who they say they are and to give your application a way to uniquely identify them. This is separate from _Authorization_, which is controlling which resources users can interact with. That said, adding Firebase's Authentication tool to our project will mean that our requests to Firestore will include information about the user that we can use for authorization. To add authentication to your project, return to the Project Overview page of your new project in the Firebase console. Click the Authentication card to add authentication to your project. ### Selecting providers You will be asked to add one or more "providers" to your application. You will see that you have a lot of options. There are some native providers that are built into Firebase, as well as a collection of OAuth providers that you should be fairly familiar with at this point. OAuth is designed to allow applications to request tokens on behalf of resource owners (users) so they can access those resources. Imagine you had written an application that made use of users' Google data (like their calendar, for example). Users shouldn't trust your app with their account passwords, but if they want to allow the application to have access to their data, they could log into Google through your application and allow your application to access their Google data, and then Google would give your application a token that could be used to request the account data. While originally designed to grant applications access to user's data, it quickly gained traction as a way to perform authentication where we ask the user to log into the service, but we don't use the token as anything more than proof that user is a valid Apple/Google/GitHub/whatever user. There are a number of advantages to using one of the third party providers. For users, it means that they don't have to remember so many passwords. As an application developer we can have more confidence that we are dealing with a real user. As an example, since all members of the Middlebury community have an associated Google account, we could use the Google provider and limit users to those with a `middlebury.edu` account to create a site that was only open to Middlebury using the same Middlebury password as everything else. As for the providers? They get to further enmesh their users, and (bonus) know something about their activity when they aren't on the provider's site. This can, of course, be seen as a _disadvantage_ for users. I've decided not to use services in the past because the only access was through 'Login with Facebook'... Picking the right provider will take a little thought for the project. For the practical, we are going to enable two of the native providers: Anonymous and Email/Password. For each of them, you will need to click through and then click the toggle to enable them. For the Email provider, we will not enable the passwordless sign-in. The Email/Password provider is pretty straightforward, but what is "anonymous" authentication. Anonymous authentication allows us to uniquely identify the user without their having to take any action to sign in. This can be useful for something like implementing a basket on an e-commerce site. The user can add things to their basket while they shop without having an account. This is particularly useful when developing mobile applications (there is nothing that is more of a turn off to me than a phone app that requires me to set up an account or sign in when I first open the app). There are also tools to allow you to transition data from an anonymous user to a logged in one. Anonymous users also gives us (some) assurance that users are accessing our data through our application. ### Finish setup in your local directory Return back to your code for the final steps. As we did in the earlier practical, run `firebase init`. This time, for the features you should choose Firestore _and_ the Emulators. Use the project you just created, accept all of the defaults, and when it asks which emulators you want to enable, choose to enable both Firestore and Authentication. ## Getting to know the Messages App Fire up the emulators and then start the development server. You will see a very basic message board. You can enter things into the text box, click the post button and they will be posted to the board (and saved in the database). There is a Log In screen, but it doesn't do anything. If you go through the code, you will see there are two pages: `Home`, which contains the board, and `Login` which handles the login facilities. `Home` has a `useEffect` that sets up a watcher to automatically populate the board when new messages are posted (if you open the page in multiple windows you can see this in action). If you look in the `NewMessage` component, which displays the text entry and handles posting the messages, you will see this code: ```javascript const data = { body: message, timestamp: Timestamp.now(), email: user.email } ``` which provides you with the structure of the data that we are storing. We are going to make a collection of changes throughout this code, so it would be good to read through the rest of it to get familiar with the structure. ## Adding authorization with Security Rules We are going to start by requiring users to be using our application in order to view the messages. One of the things that we ignored earlier were the [Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started). These rules are how we will use our _authentication_ to grant _authorization_. When you created your application, you probably chose "Test mode" for the database as I suggested in Practical 5 (if not, you won't have seen any of the messages in the last step). That left you with rules that look like this (though the date is probably different): ```javascript rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if request.time < timestamp.date(2022, 11, 28); } } } ``` You will find these in `firestore.rules`. (You can also edit and test these using the Firestore console pane, but we will do this locally). We are not going to spend much time going through the syntax of these rules (I recommend you read the documentation on [structure](https://firebase.google.com/docs/firestore/security/rules-structure) and [writing conditions](https://firebase.google.com/docs/firestore/security/rules-conditions)). These particular rules say that _everyone_ can read and write all documents in the database until November 28, 2022, at which point _no one_ will be able to access the data. We are going to change this to say that the user must have some form of authorization in order to access the application data. The key to this is that the Authorization tool is going to add an [`auth` property](https://firebase.google.com/docs/reference/rules/rules.firestore.Request#auth) to the request object that is sent to Firestore, and we can access that in the rules. For the time being, we will only check that the authorization is present. We will do that by changing the condition to ```javascript if request.auth != null ``` Make that change now. You will no longer be able to add messages, and if you reload the page, you will no longer be able to see the ones that you created earlier. ## Log the user in Anonymously To provide the user with a login, we will automatically log the user in anonymously (this is not always something you need or want -- don't just blindly do this step for the project). To sign the user in, you just need to call `signInAnonymously`. This takes one argument, the `auth` object, which we can get from `getAuth()` Go to `_app.js`. Add the import for the functions ```javascript import { getAuth, signInAnonymously } from "firebase/auth"; ``` We only want to call this once, so create a `useEffect` with an empty watch list. Add this code to the `useEffect`. ```javascript const auth = getAuth(); signInAnonymously(auth); ``` Just like that, you should be able to post and read messages again. ## Restrict posts to registered users Of course, if we are going to create a message board responsibly, we should not let people anonymously post. That is a recipe for a disaster (I'm looking at you Yik Yak and 4Chan). We can make our rules more restrictive. Start by removing the `write` from the list of allowed actions in your rules file. Now no one can post. Add a second rule that says: ```javascript allow write: if request.auth.token.email != null; ``` This says that the write to the database is only allowed if the authorization contains an email address. You can test your rules by running `npm test rules` (this isn't a special command -- I just wrote a test for you called `rules.test.js`). Not all of the tests will pass yet -- there is one more change we will make shortly. _The output will be a little spammy. We are using a tool for these test that allows us to create different environments to mimic users being logging in or not. There is something buggy in there which means I have to set the host and port of the emulators twice, which causes big warning messages when you run the tests._ This is only scratching the surface with respect to what you can do with the Security Rules. I urge you to think carefully about who needs to be able to do what with your data, and then study the documentation to figure out how to achieve your goal. The usual approach is to apply the [Principle of Least Privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege), which basically means you should only give _just enough_ access to your components/application/users to accomplish what they need to do and no more. ## Allow the user to register or log in Now that things are locked down, we need a way for legitimate users to get logged in so they can post. Turn your attention to `login.js`. I have handled all of the form work for you. The `email`, `password`, and a flag indicating if this is a new user registering or a returning user (`newUser`) are all stored in state variables. Your job now will be to implement the `handleLogin` function, which is called when the user clicks the appropriate button. The truth is, this is a fairly straightforward process. There are two functions we need: `createUserWithEmailAndPassword` and `signInWithEmailAndPassword`. Both take three arguments: an authorization object, an email address, and a password. It isn't rocket science to figure out what the two do. Add an import statement for the functions we need: ```javascript import { getAuth, signInWithEmailAndPassword, createUserWithEmailAndPassword } from "firebase/auth"; ``` Start by getting the `auth` object with `getAuth` inside of `handleLogin`. Then write a conditional statement. If this is a new user, call `createUserWithEmailAndPassword`, otherwise call `signInWithEmailAndPassword`. These are both asynchronous, so add an `await` in front of them. After each call, add `router.push("/")` to return to the message board. Test this out. Create a new user. Once you do, you should be able to post messages again. ## Catching errors There are a number of reasons why the two above functions may fail (e.g., entering the wrong password). We are going to create a better user experience by catching some of these and handling them. We have not talked about error handling in JavaScript, but it uses a [`try`/`catch`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#try...catch_statement) structure, much like many other languages. Surround each of the two functions you added earlier with try catch blocks like this: ```javascript try{ await createUserWithEmailAndPassword(auth, email, password); router.push("/") } catch(error){ console.log(error.message); } ``` If you are not familiar with with the try-catch pattern, the idea is that if anything within the `try` block throws an error, control flow will jump immediately down into the `catch` block where we can examine the error and handle it without the user seeing one of the big messy error messages (this is why we include the `router.push("/")` in the `try` block -- it will be skipped if the user fails to log in). In the code block above, we are printing the error message to the the console. This is fine for developers, but not for users. To show a message to the users, you will see there is another state variable called `errorMessage`. If you call `setErrorMessage`, a message in red will pop up above the text input fields. We could just pass the error message directly to `setErrorMessage`, but there are two reasons why we don't want to do that. The primary reason is that showing end users internal error messages is at best ugly and at worst more confusing (I'm sure you have all seen applications that got this wrong and reported something like "Aborting: Error 42"). The other reason is that the error messages we get back from the Authentication tool are a little _too_ helpful. They will report back when the email address entered is an unknown user separately from when the password is incorrect for a known user. There are different philosophies about this, but I generally fall in the camp that you don't let on to an end user whether or not some other user exists or not. _Of course, since Firebase is public facing, they can always go around our application (they could just add a break point to our code since it is running on their machine and see for themselves, or try registering new users), but there is no need to make it easy on them._ So, we are going to look at the content of the message, figure out what the error actually is, and then turn it into an end user readable message. The general form will look like this: ```javascript if (error.message.includes("invalid-email")){ setErrorMessage(`${email} is not recognized as a valid email address`) } ``` For the new user, here are the error message fragments we will look for and the new error messages: - `invalid-email`: `\`${email} is not recognized as a valid email address\`` - `weak-password`: `"Password should be at least 6 characters"` - `email-already-in-use`: `\``${email} is already in use\`` For returning users: - `invalid-email`: `\`${email} is not recognized as a valid email address\`` - everything else: `"Email address or password is incorrect"` ADd these to your code and then try some of these out to make sure your error handling is working. ## Using the logged in user At this point the application is almost fully functional. Anonymous users can lurk and watch the message board, users can register or log in and post messages when they have done so. But there are some niceties that we can add in. The first thing we will do is hide the `NewMessage` component when the user isn't logged in. ### Checking the user status There are a couple of different ways that we can get information about the current authentication status. However, the [recommendation](https://firebase.google.com/docs/auth/web/manage-users) is that we set an observer on the auth object. This will allow us to run a handler when the authentication status changes. As with watching for changes in the Firestore collections, this is a one time initialization. We are going to do this in the `useEffect` that we already added in `_app.js`. If you followed the documentation link, you would see the example: ```javascript const auth = getAuth(); onAuthStateChanged(auth, (user) => { if (user) { // User is signed in, see docs for a list of available properties // https://firebase.google.com/docs/reference/js/firebase.User const uid = user.uid; // ... } else { // User is signed out // ... } ``` You can see that this takes in the `auth` object and a function that gets the current `user` (if there is one). Go ahead and add this to the `useEffect` (you don't need to duplicate the `getAuth` call since we already have one). `onAuthStateChanged` actually returns a function we can use to unsubscribe from the watcher, so go ahead and return that in the `useEffect` so the `useEffect` can clean up when appropriate. What are we going to do with this information? Well, the same thing we have done with everything else -- save it in a state variable. Create a new state variable called `user` (you may want to rename the `user` variable in the example above). When there is a user logged in, call the setter on your state variable to save the user data. When there is not a user (they must have logged out), call the setter with no argument to clear the user. I would also like you to call `signInAnonymously` here so that the user is still valid (if not registered). ### Communicating the user to the rest of the application We could now follow our previous pattern and add the `user` to the `props`. However, I would like you to see a different approach. A value like the `user` is one that we might use in a variety of different components throughout the application. We could easily end up having to include the `user` prop everywhere. There is an alternative approach that allows us to make a value available to disparate components without having to forward it along through the props of all of the intervening components that don't care about it: the [React Context](https://reactjs.org/docs/context.html). The big idea here is that we can make the value available at a high level of the rendering tree in a "provider" and then components lower down the tree can register as "consumers" to receive the value. Create a new folder in `src` called `contexts`. In the folder, create a new file called `UserContext.js` In the file, add this code: ```javascript import { createContext, useContext } from "react"; const UserContext = createContext(); export const useUser = ()=>(useContext(UserContext)); export default UserContext; ``` This does two things. First, it creates a new Context called `UserContext`. Second, it creates a new hook that will allow consumers to access any value associated with this context (`useUser`). Add an import for the context to `_app.js` ```javascript import UserContext from "../contexts/UserContext.js"; ``` To _provide_ the context to the rendering tree, we are going to wrap the top level component inside of a `UserContext.Provider` component and set its value. This is what that looks like: ```javascript return ``` Any component can now use `useUser` to access the value we provided with the Provider (`user` in this case). ### Hide `NewMessages` Okay, we are now ready to hide the `NewUser` component. Go to `index.js`. Import `useUser` and use it to get the current user. Use `user` to conditionally render the `NewMessage` component. ```javascript {user && user.email && } ``` Note that we check for both `user` and `user.email` to account for the moment when not even the anonymous user is logged in, which would cause an error when we tried to access `user.email`. ### Add the email to outgoing messages The next thing we should address is that the messages are all being sent from a bogus email address. Go into `New Message`. Use `useUser` to get the user (replacing the old code that created the user with the bogus email address). You should now have the correct email address when you log in. Now we can also add one final piece to our rules. Change the write rule to this: ```javascript allow write: if request.auth.token.email != null && request.auth.token.email == request.resource.data.email; ``` This says that the database only accepts writes from logged in users AND that the user's email must be present in the post. That last piece is what will remove all anonymity because now users can spoof their address when they post messages. ### Clean up `LoginStatus` Another tweak we will make is to `LoginStatus`. On most sites, when a user is logged in, the option to log in is replaced with the option to log out (and maybe some display of who the current user is). As you can probably guess, we are going to make changes based on who the current user is, so get the user with `useUser`. If there is a user and the user has an email, return this instead of the previous behavior (you should leave the previous behavior for when there isn't a registered user). ```javascript

{user.email}

logout()}>Log out

``` You should notice that this calls a function we don't have yet (`logout`). Add a `logout` function. It should get the `auth` object and then call `auth.signOut()`. ### Fetching messages after log out You will find that when you sign out, you can no longer see any messages. However, I had you sign the user back in anonymously after log out, so you should still be able to see the messages. The problem is that when we were briefly completely logged out, it killed our Firestore observer. We would like to restart it again once we have logged the user back in. To do this, go to `index.js`. Add `user` to the watch list for the `useEffect`. Surround the code inside of the `useEffect` in a conditional that only starts the observer when we have a valid user. Now when you log out, the messages will stay. ## Finishing Up Commit the changes and push them to GitHub. Then submit your repository to [Gradescope](https://www.gradescope.com/courses/439665/assignments/2417649).

CS 312 - Practical Seven