A Little Tear


![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

Chris Padilla/Blog

On This Day