DEV Community: Joseph Martin

Authentication

Joseph Martin — Fri, 24 Feb 2023 02:06:28 +0000

While learning about user authentication in web development, I had some difficulty grasping all of the concepts, so I did a little research and I am writing about what I learned. Authentication, in the sense of web development, is the process of making sure our user is who they say they are before they are allowed to access the content.

So, if I'm building a website with users, and I want my users information to be secure, there' a few things I have to know. First, HTTP is a stateless protocol. It does not store the user data for me. Cookies allow additional information to be sent along with the request to the server. Cookies are usually used to save session info. Without them, a user would have to log in and be authenticated for every request. The session is a special cookie that Rails encrypts and signs. Rails manages all of the session data in a single cookie, serializing all of the key-value pairs into a single string. Whenever a key is set Rails updates the value of the session cookie to this big string. When cookies are set like this Rails signs them to prevent users from tampering with them. The Rails server has a key, configured in config/credentials.yml.enc. Rails has a method that returns a signature. The signature is an encrypted string. Given the same message and key, it will produce the same string. Also, without the key, it is practically impossible to know what would be returned for a given message. Meaning, signatures can't be forged. When a cookie is received, Rails will verify that the signatures match. Once the username and password have been authenticated, you receive a cookie. With it, you do not need to provide your username and password for every request. When a user logs in a cookie is set on the user's browser. That cookie writes their user id into the session's hash.

The password should never be stored in the database as plain text. Instead, it should be stored as a hashed version, an encrypted string. There are many kinds of hashes, but they need to be complex enough to not be easily decrypted. Another common issue with hashes is that similar passwords can generate hashes with similar values. Sometimes these values "collide" with each other. One library that makes hashes is BCrypt. BCrypt is designed so that similar strings come out to be very different values, it is a cryptographic hash and is designed to be slow. it is intentionally computationally expensive. A salt is a random string prepended to the password before hashing it. It's stored in plain text next to the password, so it's not a secret. Rails makes this easier for us. There is a macro called has_secure_password. It is placed in the user model, and it gives access to methods used to authenticate the user. The macro grants access to two instance methods on the user model. These two methods enable password and password_confirmation to easily be added to a signup form. has_secure_password has a hook that checks if the password and password confirmation match unless the password confirmation is nil. If they match or the value is nil then the user is saved and the hashed version of the password is stored in the password_digest. It stores two values, the salt and the return value of BCrypt. User.authenticate is another method has_secure_password allows me to use. It takes the password the user inputs, puts it through the same encryption process, then checks that it matches the password_digest in the database.

useContext in React

Joseph Martin — Mon, 20 Feb 2023 23:22:43 +0000

I have just finished working on another project, and one of the project requirements was to persist the user's state in the front
end with useContext. So, I had to relearn how to use useContext. I wanted to share some of the things I learned.

Typically our state is stored in a component where all the components that need access to it can easily get access to it. In this project, since most of my components needed access to the user, I made a userContext. To start, you need a file to store your context in. I created a context folder in my src folder, and a user.js file in the context folder. Then, create the context and the context provider.
Create the context

const UserContext = React.createContext();

Create a provider component

function UserProvider({ children }) {
  return <UserContext.Provider value={{ user, setUser }}>{children}</UserContext.Provider>;
}

The value is the context that I am passing, and it will be available to the children of the provider. Now that it's created it needs to be passed in to the application. To do this, I import the UserProviderinto the app and wrap the components in UserProvider. I also no longer need to pass the user and setUser props into the component.

...
import { UserProvider } from "../context/user";

function App() {
  return(
    <UserProvider>
      <AComponent />
    </UserProvider>
  )
}
...

Now, I need to add the context to the component I'm going to use it in.

import React, { useContext } from "react";
import { UserContext } from "../context/user";

function AComponent() {
  const { user, setUser } = useContext(UserContext);

  {now you have access to your context values here}

  return (
    {and here too}
  )
}

And, that is how you use context to store state globally. One thing that gave me a lot of trouble was, when I was initializing my user state I initialized it with an empty array rather than null. While I probaly could have rewritten the code to make the first way work, it was giving me a lot of trouble, and changing it to null really helped me out.
Not like this,

const [user, setUser] = useState([])

but like this.

const [user, set user] = useState(null)

Calorie Tracker

Joseph Martin — Thu, 17 Nov 2022 23:32:23 +0000

For my phase 3 project I decided to make a calorie tracker. I had a lot of fun working on this project. In this project I have two models, Day and Food. There are many foods belonging to one day. For the backend, one thing I enjoyed working on was setting up the routes to view the various endpoints for my databases. For viewing the full database I kept my endpoint simple: /days.

get "/days" do
  days = Day.all
  days.to_json(include: :foods)
end

What this code block is doing is grabbing all instances of the Day class and converting it to JSON. Then, it is nesting each food instance with it's associated Day.

For my POST routes, I have an endpoint to create a new day and another one to create a new food through the day by id.

post '/days' do
  day = Day.create(
    date: params[:date],
    foods: params[:foods],
  )
  day.to_json(include: :foods)
end

This is creating a Day instance and gives it a date that the user enters in the frontend, and an empty foods array for the value of foods.

post '/day/:id/foods' do
  day = Day.find(params[:id])
  food = day.foods.create!(
    name: params[:name],
    calories: params[:calories],
    fat: params[:fat],
    fiber: params[:fiber],
    day_id: params[:day_id],
  )
  {}.to_json(include: :foods)
end

This is finding a day instance in the class Day. Then, it is creating a food instance in that day.

I have a PATCH route for both models. They are very similar so I will only talk about the route to patch foods.

patch '/foods/:id' do
  food = Food.find(params[:id])
  food.update(
    name: params[:name],
    calories: params[:calories],
    fat: params[:fat],
    fiber: params[:fiber],
    day_id: params[:day_id],
  )
  food.to_json
end

This is finding an instance of a food by id. And then, it is updating the instance with information provided by the frontend.

Similar to my PATCH routes, my DELETE routes are exactly the same just with differnt values.

delete '/days/:id' do
  day = Day.find(params[:id])
  day.destroy
  day.to_json
end

This finds a day instance by id. Then it destroys it. In the Day model there is a dependent: :destroy so that when a day is deleted all of the foods associated with that day are deleted as well. I've been told the last line of the code block is unnecessary, but every time I delete it my delete button stops working in the front end.

I also wrote some routes that I am not using in this project, but I have seen similar functionality in APIs that I have used. So, I wanted to create some extra endpoints. I have a route to get all days without their associated foods; I have a route to get all foods without their day, and I have a route to get one day by id and another one to get one food by id.

get "/days" do
  days = Day.all
  days.to_json
end

This returns all days

get "/foods" do
  foods = Food.all
  foods.to_json
end

This returns all foods.

get "/days/:id" do
  day = Day.find(params[:id])
  day.to_json
end

This returns one day by id. The id is provided from the front end.

get "/foods/:id" do
  food = Food.find(params[:id])
  food.to_json
end

This returns one food by id. The id is provided from the front end.

I also created a route to get the last seven days with their nested foods.

get "/days_last_seven" do
  week = Day.last(7)
  week.to_json(include: :foods)
end

I really enjoyed this project and thinking about all of the different routes I may want to access to interact with the front end application.

My Cook Book

Joseph Martin — Tue, 08 Feb 2022 23:15:45 +0000

For my phase 2 project with Flatiron school I decided to make a cook book to store some of my favorite recipes, and some new ones that I would like to try. This web application was written with React, and this is my first React project. I had a lot of fun working on this project. The major features of this project are the list of recipes that can be filtered in to category's,

and a form to add new recipes to the database.

On the list of recipes you can click on one to see the full recipe.

One piece of code that was both challenging, and a lot of fun to work on was the filter. First I had to create a dropdown to select a category.

<div id="category-filter">
  <label htmlFor="category">Filter By: </label>
  <select name="category">
    <option value="all">Choose a Category...</option>
    <option value="appetizers">Appetizers</option>
    <option value="beverages">Beverages</option>
    <option value="breakfast">Breakfast</option>
    <option value="desserts">Desserts</option>
    <option value="main dishes">Main Dishes</option>
    <option value="salads">Salads</option>
    <option value="side dishes">Side Dishes</option>
    <option value="soups and stews">Soups and Stews</option>
  </select>
</div>

After That I had to control the form in state so I could access the value later.

// the recipes prop is a list of recipes from an api
function RecipePage({ recipes }) {

  {/* here I set the initial state */}
  const [filterBy, setFilterBy] = useState("all")

  <div>
    <label htmlFor="category">Filter By: </label>

    {/* now I can set the value and onChange */}
    <select
      name="category"
      value={filterBy}
      onChange={e => setFilterBy(e.target.value)}
    >
      {/* ...
      options
      ... */}
    </select>
    {/* pass recipes and filterBy in to RecipeList */}
    <RecipeList recipes={recipes} filterBy={filterBy} />
  </div>
}

Now that I have the value of the dropdown stored in state as filterby, I can pass that value in to RecipeList. In RecipeList we receive two props, recipes, the list of recipes, and filterBy, the selected category on the dropdown. For recipes, I don't want to alter it (I'll need the original list later) so I create a new variable in state, filteredRecipes. Next, I filter through the list of recipes and find all of the recipes that match the currently selected category. Then, I save those recipes to filteredRecipes so I can re-render the list with just the selected recipes.

function RecipeList({ recipes, filterBy }) {
  // set new state variable
  const [filteredRecipes, setFilteredRecipes] = useState([])

  //This is a side effect that runs everytime filterBy changes
  useEffect(() => {
    if (filterBy === "all") {
      setFilteredRecipes(recipes)
    } else {

      // first, I create a new array
      let newFilteredRecipes = []

      // next I filter through the list
      recipes.filter(recipe => {

        // if the category's match, 
        if (recipe.category === filterBy) {

          // add the recipe to the array
          newFilteredRecipes.push(recipe)
        }
      })
      // set the new filtered list to filteredRecipes
      setFilteredRecipes(newFilteredRecipes)
    }
  }, [filterBy])

  // now the JSX has filtered recipes to work with
  return (
    <div>
      {filteredRecipes.length !== 0 &&
        filteredRecipes.map(recipe => (
          <RecipeListing key={recipe.id} recipe={recipe} />
        ))
      }
    </div>
  )
}

In conclusion, I created a dropdown, and I controlled the dropdown in state. Then, I compared each recipes category to the value in state. Lastly, I stored the new list of filtered recipes in it's own state variable as to not alter the original list and to re-render the filtered list.

Doctor Who Database

Joseph Martin — Wed, 22 Dec 2021 02:10:53 +0000

My phase 1 project is a visual database of Doctor Who episodes. To view my website click here. Information about episodes can be retrieved by season, Doctor, director, or writer This could be considered a companion app to the Doctor Who Series. While working on this project I had to come up with some creative solutions to a couple challenges I was facing.

The first challenge was to prevent having to scroll to see information. For example, when you first click on a category; season, Doctor, director, or writer(in the example above we are looking at seasons); it fetches the endpoint for that category, and renders all items for that category(all of the seasons for this example) to the page. Since there's over 39 seasons the list can be long. When you click on a season you see all the episodes for that season. Now, lets say you want to see the episodes for the very last season. You click on that season, and nothing happens... That's because you have to scroll all the way back up to the top to see that information. So, I wanted to make the information display on screen no matter where I was on the page. I fixed this in CSS by setting position: fixed; on the container that holds the list of episodes. Now, this made the information stay fixed in place on the screen, but it was overlapping with the list of seasons. To fix this I moved the container. The final CSS looked like:

#episodes-container {
    position: fixed;
    top: 260px;
    left: 25%;
}

The top: 260px; made the container display 10 pixels beneath my 250 pixel header, and the left: 25%; made the container display 25% of the way across from the left side of the window.

The second challenge was more difficult to solve. The structure of the API did not easily allow episode details to be displayed. Each category has it's own endpoint within the API that I used, catalogopolis. While the endpoint had a way to see what episodes pertained to each item in the category, it did not show the episode details. To see the episode details you had to find it within the episodes endpoint. The two endpoints did not share any data except the episode name. So, I had to come up with a way to take the episode name, fetch the episodes endpoint, and find where the episode names matched. I'm going to break the code down for you. First I saved my endpoint to a variable: const allEpisodesURL = 'https://api.catalogopolis.xyz/v1/episodes' from there I ran a fetch on the endpoint:

function fetchAllEpisodes(episodeName) {
    fetch(allEpisodesURL)
    .then(r => r.json())
    .then(episodes => findEpisode(episodes, episodeName))
}

in fetchAllEpisodes I passed in the episodeName so it would be available to pass on to findEpisode. In findEpisode,

function findEpisode(episodes, episodeName) {
    for (let episode of episodes) {
        if(episode.title === episodeName) {
            renderEpisodeDetails(episode)
            break;
        } else {
            renderNoEpisodeDetails(episodeName)
        }
    }
}

I am iterating through the array of episodes. I am looking at each episode and checking if the episodeName strictly equals the episode.title. If we find the matching episode we pass it to renderEpisodeDetails. If we don't find the matching episode we pass it to renderNoEpisodeDetails. In render episode details,

function renderEpisodeDetails(episode) {
    episodeDetailsContainer.innerText = ''
    let title = create('p')
    let airDate = create('p')
    let runtime = create('p')
    let viewers = create('p')
    let rating = create('p')
    title.innerText = episode.title
    airDate.innerText = `Aired: ${episode.originalAirDate.slice(5)}-${episode.originalAirDate.slice(0, 4)}`
    runtime.innerText = `Runtime: ${episode.runtime}`
    viewers.innerText = `Viewers: ${episode.ukViewersMM} million `
    rating.innerText = `Rating: ${episode.appreciationIndex} / 100`
    episodeDetailsContainer.append(title, airDate, runtime, viewers, rating)
}

I create a p tag for each detail, fill in the innerText of each detail with data returned from the API, and append it all to the container that holds the episode details. A quick side note, create is a helper function I added to the top of my file,

const create = el => document.createElement(el)

And now, if we back up a little, if no episode details were found in findEpisode we pass the episodeName to renderNoEpisodeDetails,

function renderNoEpisodeDetails(episodeName) {
    episodeDetailsContainer.innerText = `${episodeName} is not in the database`
}

in renderNoEpisodeDetails I am setting the innerText of the episodeDetailsContainer to say, episodeName is not in the database.

Finding solutions to these two challenges made the project easier to navigate and provided additional information.