A Little Tear


![☃️🏠🏔️](http://res.cloudinary.com/cpadilla/image/upload/v1734104812/chrisdpadilla/blog/art/mxdtfdolcroaw4b0qqz7.jpg)

❄️


Snow Trek Home


![Brr!](http://res.cloudinary.com/cpadilla/image/upload/v1702152532/chrisdpadilla/albums/kaaujeftajggbj1syz29.jpg)

Music somewhere between ambient classical and winter lofi!

Purchase on [🤘 Bandcamp](https://letsgochris.bandcamp.com/album/ice) and Listen on [🙉 Spotify](https://open.spotify.com/album/18LcJLrmBcc5uHT7KbttgX) or any of your favorite streaming services!


New Album — Ice 🧊


Taking an opinionated approach, Next Auth intentionally limits the functionality available for using credentials such as email/password for logging in. The main limit is that this forces a JWT strategy instead of using a database session strategy.

Understandably so! The number of data leaks making headlines, exposing passwords, has been a major security issue across platforms and services.

*However*, the limitation takes some navigating when you are migrating from a separate backend with an existing DB and need to support older users that created accounts with the email/password method.

Here's how I've been navigating it:

## Setup Credentials Provider

Following [the official docs](https://next-auth.js.org/providers/credentials) will get you most of the way there. Here's the setup for my authOptions in `app/api/auth/[...nextAuth]/route.js`:


```JavaScript
import CredentialsProvider from "next-auth/providers/credentials";
...
providers: [
  CredentialsProvider({
	name: 'Credentials',
	credentials: {
		username: {label: 'Username', type: 'text', placeholder: 'your-email'},
		password: {label: 'Password', type: 'password', placeholder: 'your-password'},
	},
	async authorize(credentials, req) {
		...
	},
}),
```

## Write Authorization Flow

From here, we need to setup our authorization logic. We'll:

1. Look up the user in the DB
2. Verify the password
3. Handle Matches
4. Handle Mismatch

```
async authorize(credentials, req) {
	try {
		// Add logic here to look up the user from the credentials supplied
		const foundUser = await db.collection('users').findOne({'unique.path': credentials.email});

		if(!foundUser) {
			// If you return null then an error will be displayed advising the user to check their details.
			return null;
			// You can also Reject this callback with an Error thus the user will be sent to the error page with the error message as a query parameter
		}

		if(!foundUser.unique.path) {
			console.error('No password stored on user account.');
			return null;
		}

		const match = checkPassword(foundUser, credentials.password);

		if(match) {
			// Important to exclude password from return result
			delete foundUser.services;

			return foundUser;
		}
	} catch (e) {
		console.error(e);
	}
	return null;

},
```
## PII

The comments explain away most of what's going on. I'll explicitly note that here I'm using a try/catch block to handle everything. When an error occurs, the default behavior is for the error to be sent to the client and displayed. Even an incorrect password error could cause a Personally Identifiable Information (PII) error. By catching the error, we could log it with our own service and simple return null for a more generic error of "Failed login."

## Custom DB Lookup

I'll leave explicit details out from here on how a password is verified for my use case. But, a general way you may approach this when migration:

1. Verify with the previous framework/library the encryption method
2. If possible, transfer over the code/libraries used
3. Wrap it in a `checkPassword()` function.

## Sending Passwords over the Wire?

A concern that came up for me: We hash passwords to the database, but is there an encryption step needed for sending it over the wire?

Short answer: No. [HTTPS covers it](https://security.stackexchange.com/questions/133453/is-encryption-of-passwords-needed-for-an-https-website) for the most part. 

Additionally, Next auth already takes many security steps out of the box. [On their site](https://next-auth.js.org/getting-started/introduction), they list the following:

> - Designed to be secure by default and encourage best practices for safeguarding user data
> - Uses Cross-Site Request Forgery Tokens on POST routes (sign in, sign out)
> - Default cookie policy aims for the most restrictive policy appropriate for each cookie
> - When JSON Web Tokens are enabled, they are encrypted by default (JWE) with A256GCM
> - Auto-generates symmetric signing and encryption keys for developer convenience

CSRF is the main concern here, and they have us covered!

## Integrating With Other Providers

Next Auth also allows for using OAuth sign in as well as tokens emailed to the clients. However, it's not a straight shot. Next requires a JWT strategy, while emailing tokens requires a database strategy.

There's some glue that needs adding from here. A post for another day!

Credentials Authentication in Next.js


Heroku has discontinued their free hosting tier for web applications. A major disappointment for many a side-projector! Several of my first web apps were still being hosted on Heroku, so it was time to re-evaluate.

There are a few other options. Render and Digital Ocean have low cost options. As you can tell by the title of the article, though, I felt it was time to explore hosting on AWS.

# Elastic Beanstalk

There are a few options for hosting:

- Running the server as a Lambda function
- Hosting the server on an EC2 instance
- Managing load balancing and scaling with Elastic Beanstalk

For those unfamiliar:

- **Lambda functions** are AWS's solution for _Serverless Functions_
- **EC2 (Elastic Compute Cloud)** is a _hosting platform_ for cloud computing
- **Elastic Beanstalk** is an _orchestration service_ that wrangles EC2, S3s, CloudWatch, Elastic Load, and many other good-to-haves in hosting an application

So, maybe it's unfair to say these are different options: Technically Elastic Beanstalk will make use of an EC2 instance with several other goodies baked in to handle the need to up and down scale my apps as needed.

I'm throwing in running the server as a lambda function as a fun idea. I'm not caching on the server directly, so it's potentially an option. However, I wanted to start with a more direct and traditional approach so that I have the experience for larger applications that require a regularly running server.

For quick implementation and a nice learning opportunity, I opted for Elastic Beanstalk.

# Code Pipeline

My CI/CD needs are pretty minimal for my old portfolio projects, but nonetheless, I like being able to push to Github and then let the deploy happen automatically. So I'm setting up my EB applications with code pipeline connecting to my repositories as well.

# Set Up for AWS

There are a few things we'll want to do to prepare for deploying to AWS:

1. Match port number to the Internet port
2. Ensure the version of Node is within AWS's accepted range
3. Generate static files
4. Alias the route to our static files
5. Include a Procfile for defining start script

In another article, I'll go into the details of generating and routing to our static files. For now, let's look at what getting an Express server that renders templates would look like with the first two steps.

## Match Port Number

If we use the typical fallback port for servers in local development: 3000, 5000, or 7000, you'll run into an Nginx error with status code 502: bad gateway. To prevent this, we have to set our default port number to 8081, the port typically used for HTTP protocols.

Depending on how your express app is structure, this can be updated in the `bin/www` file:

```
// bin/www

/**
 * Get port from environment and store in Express.
 */

var port = normalizePort(process.env.PORT || '8081');
app.set('port', port);

```

Or in your server file directly:

```
// server.js

const port = process.env.PORT || 8081;

app.listen(port, () => console.log(`Server started on port ${port}`));

```

## Match Node Version

The apps I worked with were from several years ago. And things have changed! I had to bump up multiple node version to comply with the AWS environment. This is done easily in the `package.json` file. It's worth verifying that your app is still running after making these changes and switching your local node with Node Version Manager:

```
// package.json

{
	...
	"engines": {
		"node": "^16.0.0",
		"npm": "6.13.4"
  }
}

```

# Deploying

You have a couple of options for deploying: Downloading the EB CLI, or using the web console. The web console is fairly straightforward and allows for easily bouncing between code pipeline, your application, and the environment generated from there. [This guide](https://aws.plainenglish.io/the-complete-guide-to-deploying-node-express-app-to-amazon-elastic-beanstalk-using-github-pipeline-b36eada99cac) will get you there.

# More To Come

So that's getting an Express app up on Elastic Beanstalk! Next time I'll talk about [bringing in React within the same project](/reactexpressapp) and the pitfalls to watch out for.


Hosting a Node Express App on AWS Elastic Beanstalk


I'm continuing research on cloud architecture this week. Here are some notes on Virtual Private Clouds (VPC). In these notes, I'll be covering what they are, why use them, and what are the parts that make up a VPC.

# VPC Overview

A VPC is a private sub-section of AWS that you control, where you can place your resources (EC2's, S3s, Databases). You have full control over who has access to these resources. AWS calls these subnets, IP address ranges, and subnets

Similar to a Facebook profile - a VPC allows you to control who can view your photos, posts, and videos.

The advantage of VPC within a public cloud provider is mainly enhanced security. You can be explicit about what resources are made publicly available, and what resources have strict access. An example would be making a web server publicly available through HTTP and HTTPS protocols, while limiting access to the connected database.

VPC's also allow you to specify a unique IP range for your application. Without a VPC, your IP range may be shared with other services on a public cloud provider. Should one of the other applications be flagged as malicious, a DNS will lump your application in with any access restrictions.

# Home Network Analogy

VPC's can be likened to a Home network. In your home network, you have:

- Wires that connect to internet.
- A modem that is the gateway to the internet.
- Wires connecting modem to router
- A router that connects to other devices on network and connects to modem for internet
- Computers / cell phones

The home private network is STILL private, even though it's connected to the internet.

Differences between removing routers and modems from your system is:

- The router can still connect to other devices if modem goes down
- If the router goes down instead, no connection are possible. Even if internet connection still coming in.

The external data flow is as follows:

Internet => Modem => Router / Switch => Firewall => Devices

For VPC's, the data flow is:

Internet => Internet Gateway => Route Table => Network Access Control List (NACL) => EC2 instances (Public) => Private Subnets.

With an analogy set, let's look at the different parts

# Internet Gateways (IGW)

These are a combination of hardware and software that provides your private network with a route to the world outside of the VPC. (Horizontally scaled so you have no bandwidth strain)

These get attached to VPC's. Without it, your VPC can communicate internally, but not with the internet.

Worth noting:

- Only one can be attached to a VPC.
- While there are active AWS Resources attached to the VPC, you can not detach the IGW. (Such as EC2 or RDS Database)

# Route Tables (RT)

These are rules that determine where network traffic is directed.

You'll have a *Main* route table, and possible supplemental route tables.

You *can* detach the IGW from the VPC, and then the route will lead to a "black hole" as AWS puts it.

- You can have multiple active route tables in a VPC
- You can't delete a route table with active "dependencies" (associated subnets)

# Network Access Control Lists (NACL)

NACL are an *optional layer of security* that acts as a firewall controlling traffic in and out of subnets. They have both *inbound* and *outbound* traffic. All traffic allowed by default.

Rules are evaluated by rule number, from lowest to highest. First rule evaluated that matches traffic type gets immediately applied and executed regardless of the rules that come after.

The wildcard symbol `*` is a catch all. If we don't allow traffic, it's denied by default.

Creating a New Network ACL will deny all by default. You add rules from there.

Different subnets can have different NACLs. 

You can control allowed protocols. If hosting a web server, you may only want to have HTTP and HTTPS.

A subnet can only be associated with one NACL at a time. 

Once resources are inside, AWS resources may have their own security measures (called Security Groups.) EC2s, for example, can set their own limits on what protocols it allows in.

# Subnets

> Definition: A sub-section of a network. Includes all the computers in a specific location.

A loose analogy - If your ISP is a network, your home is a subnetwork.

Subnets may be named like the following group:

- us-east-1a
- us-east-1b
- us-east-1c
- us-east-1d

Each are within separate availability zones. This helps create redundancy, availability, and fault tolerance. 

## Public v Private Subnets

*Public* subnets have a route to the internet. *Private* subnets do not.

Both will have separate route tables. One to internet, one not. 

In relation to your VPC and Availability Zones: A VPC spans multiple availability zones. A subnet is designated to only one.

# Availability Zones

VPC's come with multiple availability zones. They are physically separated within a region, where as subnets were logically separated. This allows our applications to have *High Availability* and *Fault Tolerance* - two important paradigms in cloud architecture.
 
> Availability Zone definition: Distinct location that are engineered to be isolated from failures in other Availability Zones. By launching instances in separate Availability Zones, you can protect your app from the failure of a single location.

These are a core benefit of using cloud services in AWS. We want duplicate resources span Availability Zones. 
 
You'll have a Primary Web Server, and a back up. As well as a Primary Redis DB, and a failover. 
 
Cloud infrastructure helps in the event of local disaster. If your home server dies, you need one off site.

A little more on High Availability and Fault Tolerance:
 
*High Availability* means the least amount of downtime as possible. It's what results in someone saying "My website is always available. I can always access my data in the cloud."
 
*Fault Tolerant* is resistance to error. It results in someone saying "One of my web servers failed, but my backup immediately took over. Or if something fails, it can repair itself."

# Nat Gateway

AWS has a shared responsibility model - there are portions of security that you are responsible, and portions that AWS is responsible for.

We are responsible for maintaining the OS of our systems. We need to update systems regularly with patches from the internet.

So, question - How do we download updates to private networks?

*NAT Gateway* solve this. A NAT Gateway sits within the public subnet and has an EIP - *Elastic IP Address*.

It has a route to the internet gateway. Once it's set up, we can update the Route Table to include the Nat Gateway. 

```
Destination: 0.0.0.0/0
Target: nat-id
```

A NAT gateway does not accept inbound traffic initiated from the internet. It only takes in outbound requests from subnet and receives responses from that request.

You don't have to manage the config for this. You will, however, need to setup NAT gateways within *all* of your private subnets.

# Sources

[AWS docs on VPC's](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)

[Cloudflare on VPC's](https://www.cloudflare.com/learning/cloud/what-is-a-virtual-private-cloud/)

[Linux Academy AWS Essentials](https://www.youtube.com/watch?v=ET_CSqdGsYg&list=PLv2a_5pNAko0Mijc6mnv04xeOut443Wnk&index=18&ab_channel=LinuxAcademy)ca

Amazon Virtual Private Clouds


![Secret Poets Society Preview](https://padilla-media.s3.amazonaws.com/software-project-assets/sps-preview.png)

# Secret Poets Society

[Github](https://github.com/cdpadilla42/secret-poets-society) | [View app in browser](http://secretpoetssociety-env.eba-m4efzmqx.us-east-1.elasticbeanstalk.com/)

**The Secret Poets Society** is a club of artists sharing work purely for arts sake.
Not for fame or glory! As part of the practice, the authors names are unlisted to visitors.

The site has three tiers of membership - guest, member, and admin.

- GUESTS can sign up and login to post their own poems, joining in the art for art's sake movement.
- MEMBERS have the added privilege of seeing which of their colleagues posted which poem and on what date.
- ADMINS can see what members see and also have the ability to delete any poem they see fit.

Tech used:

- NodeJS
- Express
- MongoDB & Mongoose
- Passport
- Handlebars.js
- Custom CSS

# MVC Design Pattern

This Node application follows the Model-View-Controller approach to design. Files are organized into their roles within the system. The Mongoose ORM serves as the data model, Handlebars.js is used for templating views, and Express routes and middleware serve as the controllers. Controllers are the bulk of this application, handling data validation, sanitization, and user authentication.

To handle authorization, the Passport package is used to coordinate login. Express Sessions are then used to maintain the user’s account session with the server. User data is stored in MongoDB, including encrypted login information and their membership tier. If a user is accessing a protected route, a specific controller is accessed. With the controller functions, the logged in user’s membership tier is checked against the permissions required for a given request. If they do not have the correct authorization, the user receives an error message rendered by the application. Otherwise, they are granted access.

# Data Security & Sanitization

My greatest area of learning through this application was Security and sanitization. Incoming data has the potential to be incorrect or, worse, malicious. The Express Validator package is used to clean the data of any malicious code. Another method with the Validator package ensures the inputs match the expected types and provide the required fields.

A special case is user login data, where the password needs an extra layer of security. A custom implementation of passport brings in BCrypt, a library for string encryption, to securely save a hashed password and decrypt it when the user is attempting to log in. This ensures if the network request is intercepted or if the database is accessed outside the application, critical data is not exposed.

# Challenges

While it was a pleasure using a new UI library, I quickly discovered that Handlebars.js has it’s limitations. The library can handle a fair amount of conditional rendering. But, as the application grew more complex, I found myself trying to make views reusable through logic that Handlebars didn’t support. For example, sharing form elements from the login page and the account creation page. This comes from my experience of working heavily in React, a library that makes breaking a page into components accessible and flexible.

The solution was to approach views from a page level, allowing there to be separate pages to share a fair amount of layout formatting, but to make the small tweaks necessary to better suit a page’s needs. Working with handlebars, it was still possible to utilize conditional rendering of items, such as the authors of the poems, while still allowing the server to perform the heavy lifting of logic.

# Hosting on AWS

This project is hosted on AWS through Elastic Beanstalk and updated with the Code Pipeline CI tool. You can read more about how I configured the project for AWS in my article [Hosting a Node Express App on AWS Elastic Beanstalk](/awseb).

# Next Steps

Much of what I learned in this project transitioned into a later application, Mystery-Cowboy-Theater. Another Node application, I took the pains I felt while using Handlebars’ page approach and switched over to React to break down the UI into components. Authorization was carried over into that project as well, this time using JWT’s to pass user data between the client and API.

# Poem Credits

Authors are viewable by members. Major poets include Shel Silverstein, Walt Whitman, and Robert Frost.


Building a Message Board with User Authentication in Express


![Taco Time Preview](https://padilla-media.s3.amazonaws.com/software-project-assets/tacotimepreview600.png)

# Taco Time

[Github](https://github.com/cdpadilla42/taco-time-nextjs) | [View app in browser](https://taco-time-nextjs.vercel.app/)

Taco Time is a fictional restaurant taking inspiration from Taco Deli here in Austin, TX. With the need to showcase and allow customers to order an array of breakfast and lunch tacos, this application dynamically renders item pages and maintains a detailed cart that stores their orders and customizations. This intricate project employs multiple modern web development tools and techniques, including Server Side Rendering, interacting with a GraphQL API, running server-less functions, and dynamically rendering individual item pages with Next JS’s dynamic routes. Tech used:

- Next.js
- React
- Redux
- GraphQL
- MongoDB
- Mongoose ORM
- Apollo Micro Server
- Apollo Client
- Styled-Components
- React-Transition-Group
- Stripe
- Deployed to Vercel

## Server Side Rendering with Next.js

Next.js allows for choosing between Server Side Rendering and Static Page Generation on a page-by-page basis. For this application, assuming owners may need to post notice that an item has sold out, I’ve opted for SSR. On the server, the application grabs the data it needs and renders the html that will be sent to the client. This process alone took a considerable amount of fine tuning as the application needs to interact with Apollo’s cache and await results from MongoDB. I was able to eradicate a bit of a nasty bug in this process by having the getServerSideProps function wait for the DB to establish a connection before rendering the page.

## Crafting API Resolvers in Apollo

The back end is an Apollo Micro Server. Since this iteration of the app only needed to interact with MongoDB to fetch items in the restaurant inventory, a lighter server seemed a great fit! The server takes in hand-crafted GraphQL schemas and resolvers. The resolvers then fetch the data from MongoDB through interacting with Mongoose schemas. A mutation method was implemented for me to add items to the database as a developer. A possible expansion would be to create a view for restaurant owners to interact with an elegant UI to do this themselves.

## Integration with Stripe API for Customer Checkout

The latest feature and my favorite to work through was bringing in Stripe’s checkout component and integrating with their api to charge credit cards for orders. In this implementation, testing mode is enabled so no charges are actually incurred, but test data is sent through the application. (Use card number 4242 4242 4242 4242) To ensure a secure checkout, the order is handled on the server. There, prices are recalculated with price information on items from the database to ensure correct charging. The order is then converted to a record in the database. Finally, an order is returned to the client with details on their purchase.

## Interacting with GraphQL API

To interact with the API, Apollo Client is used within the SSR functions. To allow for flexibility, the client initialization method is written to check for whether it is being used on the server or client. The benefit of only grabbing the relevant data is best seen between the menu page and an individual items page. The menu only needs the name, image, description, and category of an item. The GraphQL query then only requests what it needs. The full item display pages, then, will request further data, such as customizations, options, and price.


Chris Padilla/Blog

On This Day