DEV Community: Brandon Benefield

Create your own Serverless OAuth Portal for Netlify CMS

Brandon Benefield — Thu, 09 Apr 2020 00:49:53 +0000

Acknowledgement
Prerequisites
Get your frontend running
Create the GitHub OAuth App
Save GitHub OAuth App credentials somewhere secure
Create your OAuth Lambdas
Triggering Lambdas
Write some OAuth code
From local to remote
Test your OAuth Lambdas
Start up your local frontend
Login into your local CMS backend

Acknowledgement

Before starting this post, I need to give a big shout out to Mark Steele whos Serverless solution is actually the basis of this post and you'll even be using some of the code from his repository, Netlify Serverless OAuth2 Backend.

Prerequisites

GitHub Account
AWS Account
AWS CLI
Basic knowledge of AWS is helpful but not necessary

Get your frontend running

Before we can worry about authenticating users to allow them to create content for our site, we first need a site to begin with. Head on over to the Netlify CMS one-click solutions page and choose a starter template. For the purposes of this post, we're going to use the One Click Hugo CMS template for no other reason than that is the template I am most familiar with. Choose your template and follow the instructions. In just a moment, you should land on your new websites' dashboard page.

Congrats, in just a few simple clicks you now have a website that you can use to start creating blog posts, pages, etc.

Create the GitHub OAuth App

Our next step is to create a GitHub OAuth Application. Alternatively, you can follow along with on the GitHub website or you can follow the next bit of instructions.

On GitHub, click on your profile picture in the top right corner of GitHub and at the bottom of the dropdown click on "Settings". On this page go ahead and click on "Developer Settings" on the bottom left of the navigation menu on the left hand side of the page. On the next page choose "OAuth Apps" and then click on the "New OAuth App" button on the top right of the page. Go ahead and fill in the form and click on the "Register application" button on the bottom left.

Save GitHub OAuth App credentials somewhere secure

Now that we have our OAuth application we need to store the sensitive information that was generated with it, Client ID and Client Secret. You need to treat these values as if they were your very own credentials into your bank account meaning do not share these with anyone.

Leave this browser tab open as we'll need those values in just a moment. Open a new tab and navigate to https://aws.amazon.com/ and click on the "Sign In to the Console" button at the top right of the page.

After you login use the "Find Services" search bar and search for "Secrets Manager" and click on the resulting search.

On the next page you need to click the "Store a new secret" button in the top right corner.

Fill in the form adding two new "Secret key/value" pairs as shown in the image below and click "Next" at the bottom right.

Fill in the next form as well and click "Next" at the bottom right of the page.

Leave this next page on its default settings and click "Next".

Finally, just scroll to the very bottom and click the "Store" button on the bottom right.

Create your OAuth Lambdas

This portion might sound daunting, especially if you've never had to handle anything cloud or authentication related but honestly, this part is pretty simple. There is a bit of confusing code but we'll go over it to get a better understanding of what's going on.

Head over to your AWS Lambda page and click on Create Function in the top right corner.

On the next screen go ahead and fill in a few of the options just like mine:

Author from Scratch
Function Name: CreateYourOwnServerlessOauthPortalForNetlifyCms__redirect (feel free to rename this)
Runtime: Node.js 12.x

There's no need to create a special role or give this role any special permissions. The default permissions that AWS attaches will be enough for this Lambda.

Now let's create a second Lambda with all the same parameters but this time replace __redirect with __callback and click on the "Choose or create an execution role" dropdown at the bottom left of the page, choose "Use an existing role" and select the role AWS created for the __redirect Lambda. If you followed my naming conventions it should be something along the lines of service-role/CreateYourOwnServerlessOauthPortalForNetlifyCms__r-role-abc123. We're reusing the same role because both Lambdas need permission to the same resource (Secrets Manager) so we can just reuse the same role and permissions. If needed in the future, you may change the roles or even add policy permissions to them as you see fit.

Great, you now have two Lambdas. From now on we'll refer to the first one as the __redirect Lambda and the second as the __callback Lambda.

Before we give our Lambdas permission I think it would be a good idea to see a common but easily fixed error. Open up your __redirect lambda and replace the code inside with the following:

const AWS = require('aws-sdk')
const secretsManager = new AWS.SecretsManager({ region: 'us-east-1' })

exports.handler = async () => {
    const secrets = await secretsManager.getSecretValue({ SecretId: 'GH_TOKENS' }).promise()
    return {
        statusCode: 200,
        body: JSON.stringify(secrets)
    }
}

Hit the "Save" and then the "Test" button at the top and you should receive an error saying:

{
  "errorType": "AccessDeniedException",
  "errorMessage": "User: arn:aws:sts::123123:assumed-role/CreateYourOwnServerlessOauthPortalForNetlifyCms__r-role-abc123/CreateYourOwnServerlessOauthPortalForNetlifyCms__redirect is not authorized to perform: secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:123123:secret:GH_TOKENS-abc123"
  ... More error message ....
}

This error is pretty self explanatory but can be confusing when you receive this in the middle of the stress that is learning AWS. Like I said, the fix is simple and the first step is to choose the "Permissions" tab right above your Lambda code.

Click on the dropdown arrow for the policy already created in the table and choose the "Edit policy" button.

Click on the "(+) Add addutuibak permissions" button on the right hand side of this next page.

Click on "Service" and search for "Secrets Manager" and choose the only option available.

Clck on "Actions", "Access level", and finally choose the "GetSecretValue" check box.

Next click on "Resources" and choose the "Specific" radial option then proceed to click "Add ARN" a little to the right of the radial options.

Go back to your SecretsManager, find stored secret and copy its ARN and paste it into the input opened from the "Add ARN" link.

Now click "Review policy" and then "Save changes" and you should be good to go. You can always double check by going back to view the policy, click the policy dropdown arrow and making sure it has the "Secrets Manager" policy attached to it.

Go back to your __redirect Lambda and click the "Test" button and you should now be greeted with a green success card, statusCode 200 and some JSON as the body.

Triggering Lambdas

Lambda functions are fun on their own but we'll need a way to trigger the code inside to run under certain conditions. For our use case, we just need an endpoint and have it run whenever someone hits that endpoint. Luckily enough, creating API Endpoints through the Lambda UI is really straight forward.

I'm going to explain how to do this for the __redirect Lambda but the steps are near identical for both. The only difference is the __callback URL will use the API Gateway created from the __redirect URL instead of creating a new API Gateway.

Navigate to your __redirect Lambda and click on the "Add trigger" button on the left side of the page.

On the next page just follow along with the image:

API Gateway
Create an API
HTTP API
Security: Open

Go ahead and navigate to your __callback Lambda and create a second trigger, this time choose your previously created API Gateway as the API choice in the second dropdown input.

You should now have two API endpoints that you can send data to or receive data from.

Write some OAuth code

Open up your terminal and navigate to where you would like to store your CMS repo. From there I want you to clone your repo and navigate inside. In the root of the repo create a new directory named "OAuthLambdas" and go inside.

mkdir OAuthLambdas
cd OAuthLambdas

Once inside, we need to initialize this directory as a Node project and install the node-fetch package using npm:

npm init -y
npm i node-fetch

Last, we need to create some new files and directories with the following commands:

mkdir handlers utils
touch handlers/redirect.js handlers/callback.js utils/authenticateGitHubUser.js utils/callbackHtmlPage.js

If done correctly, your OAuthLambdas directory should have the following structure:

OAuthLambdas/
---- handlers/
    ---- redirect.js
    ---- callback.js

---- node_modules/

---- utils/
    ---- authenticateGitHubUser.js
    ---- callbackHtmlPage.js

---- package.json

Open redirect.js and place the following code inside

const AWS = require('aws-sdk')

/**
 * Redirects users to our NetlifyCms GitHub OAuth2.0 page
 */
exports.handler = async () => {
    const region = "us-east-1"  // the Region we saved OAuth App Client Id into the AWS SecretsManager
    const secretsManager = new AWS.SecretsManager({ region })  // SecretsManager API
    const SecretId = "GH_TOKENS"  // The Secret container we want to access (Not the values but this holds the values)
    const { SecretString } = await secretsManager.getSecretValue({ SecretId }).promise()  // This gives us all of the values from the Secrets Container
    const { CLIENT_ID } = JSON.parse(SecretString)  // SecretString stores our values as a string so we need to transform it into an object to make it easier to work with
    const Location = `https://github.com/login/oauth/authorize?client_id=${CLIENT_ID}&scope=repo%20user`  // Standard GitHub OAuth URL learn more here: https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#1-request-a-users-github-identity
    return {
        statusCode: 302,  // "302" required for AWS Lambda to permit redirects
        headers: { Location }  // "Location" header sets redirect location
    }
}

Open callback.js and place the following code inside

const { authenticateGitHubUser } = require('../utils/authenticateGitHubUser')

exports.handler = async (e, _ctx, cb) => {
    try {
        return await authenticateGitHubUser(e.queryStringParameters.code, cb)
    }
    catch (e) {
        return {
            statusCode: 500,
            body: JSON.stringify(e.message)
        }
    }
}

Open authenticateGitHubUser.js and place the following code inside

const AWS = require('aws-sdk')
const fetch = require('node-fetch')

const { getScript } = require('./getScript')

async function authenticateGitHubUser(gitHubAuthCode, cb) {
    const region = "us-east-1"
    const client = new AWS.SecretsManager({ region })
    const SecretId = "GH_TOKENS"
    const { SecretString } = await client.getSecretValue({ SecretId }).promise()
    const { CLIENT_ID, CLIENT_SECRET } = JSON.parse(SecretString)
    const postOptions = {
        method: 'POST',
        headers: { 'Content-Type': 'application/json', Accept: 'application/json' },
        body: JSON.stringify({
            client_id: CLIENT_ID,
            client_secret: CLIENT_SECRET,
            code: gitHubAuthCode
        })
    }
    const data = await fetch('https://github.com/login/oauth/access_token', postOptions)
    const response = await data.json()

    cb(
        null,
        {
            statusCode: 200,
            headers: {
                'Content-Type': 'text/html',
            },
            body: getScript('success', {
                token: response.access_token,
                provider: 'github',
            }),
        },
    )
}

exports.authenticateGitHubUser = authenticateGitHubUser

Open callbackHtmlPage.js and place the following code inside

function getScript(mess, content) {
    return `<html><body><script>
    (function() {
        function receiveMessage(e) {
        console.log('authorization:github:${mess}:${JSON.stringify(content)}')
        window.opener.postMessage(
            'authorization:github:${mess}:${JSON.stringify(content)}',
            '*'
        )
        window.removeEventListener("message", receiveMessage, false);
        }
        window.addEventListener("message", receiveMessage, false)
        window.opener.postMessage("authorizing:github", "*")
        })()
    </script></body></html>`;
}

exports.getScript = getScript

From local to remote

We have our Lambdas but only locally. We need an easy way to move that code from our machine to AWS Lambda so we can finally run this code. Finally, this is where the AWS CLI comes in handy.

With your terminal open make sure you're in the OAuthLambdas directory. From there you need to run the following commands replacing the --function-name values with whatever you've named your Lambdas over on AWS.

user@group:~$ zip -r ../foo.zip .

zip -r ../OAuthLambdas.zip .

aws lambda update-function-code \
--function-name CreateYourOwnServerlessOauthPortalForNetlifyCms__redirect \
--zip-file fileb://$PWD/../OAuthLambdas.zip

aws lambda update-function-code \
--function-name CreateYourOwnServerlessOauthPortalForNetlifyCms__callback \
--zip-file fileb://$PWD/../OAuthLambdas.zip

rm -rf ../OAuthLambdas.zip

On a successful update you should receive some JSON in your terminal similar to the following

{
    "FunctionName": "CreateYourOwnServerlessOauthPortalForNetlifyCms__callback",
    "FunctionArn": "arn:aws:lambda:us-east-1:abc123:function:CreateYourOwnServerlessOauthPortalForNetlifyCms__callback",
    "Runtime": "nodejs12.x",
    "Role": "arn:aws:iam::abc123:role/service-role/CreateYourOwnServerlessOauthPortalForNetlifyCms__c-role-0pttkkqs",
    "Handler": "index.handler",
    "CodeSize": 51768,
    "Description": "",
    "Timeout": 3,
    "MemorySize": 128,
    "LastModified": "2020-04-01T00:36:58.395+0000",
    "CodeSha256": "abc123=",
    "Version": "$LATEST",
    "TracingConfig": {
        "Mode": "PassThrough"
    },
    "RevisionId": "abc123",
    "State": "Active",
    "LastUpdateStatus": "Successful"
}

Go to AWS Lambda in your browser and manually check that both Lambdas have been updated

Test your OAuth Lambdas

Open your __redirect Lambda
Change "Handler" input found above the code on the right side to handlers/redirect.handler
Click "Save" in top right corner
Click "Test" button in top right corner
Click "Configure test events" from dropdown
Name the test "RedirectTest"
Insert following:

Go back to your browser and navigate to your __redirect Lambda in AWS. First thing you need to do is change the Handler input to match your Lambda. For __redirect this value will be handlers/redirect.handler. Make sure to click "Save" at the top right of the page.

Before testing this Lambda we need to set the data that will be passed to it. This Lambda is pretty simple and isn't expecting any data. Click on the dropdown input left of the "Test" button and choose "Configure test events" and replace the data inside with an empty object.

Now we need to click "Test" at the top right corner of the page and you should be greeted with a nice success message similar to the following:

{
  "statusCode": 302,
  "headers": {
    "Location": "https://github.com/login/oauth/authorize?client_id=abc123&scope=repo%20user"
  }
}

Now that we know our __redirect Lambda is working as expected lets open up our __callback Lambda. Again, we need to change the Handler input to match what we're exporting. This time, the value will be handlers/callback.handler and click "Save".

Just like in our __redirect Lambda, we need to set our test data. Follow the same steps as above only this time we need to pass data to our Lambda. Put the following JSON inside and click "Save".

{
  "queryStringParameters": {
    "code": "abc123"
  }
}

Go ahead and click "Test" and if everything was set up correctly you should receive the following success message.

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "text/html"
  },
  "body": "<html><body><script>\n    (function() {\n      function receiveMessage(e) {\n        console.log('authorization:github:success:{\"provider\":\"github\"}')\n        window.opener.postMessage(\n          'authorization:github:success:{\"provider\":\"github\"}',\n          '*'\n        )\n        window.removeEventListener(\"message\", receiveMessage, false);\n      }\n      window.addEventListener(\"message\", receiveMessage, false)\n      window.opener.postMessage(\"authorizing:github\", \"*\")\n      })()\n    </script></body></html>"
}

This looks confusing but it means everything is working. If you look at the body property you'll notice that it's the same code in our callbackHtmlPage.js file.

Start up your local frontend

In terminal navigate to root of your project
In terminal run command yarn or npm i
In terminal run yarn start or npm start
You will know your project is up and running if your terminal looks similar to the following

We're almost there! I can see the finish line. Last thing to do is to run our CMS locally and successfull authenticate.

Back to your terminal, make sure you're in the root of your project and run the following commands.

yarn
yarn start

Let your dependencies download and let Hugo and Webpack finish its tasks. When that's complete you should see the following in your terminal.

                   | EN  
-------------------+-----
  Pages            | 10  
  Paginator pages  |  0  
  Non-page files   |  0  
  Static files     | 43  
  Processed images |  0  
  Aliases          |  1  
  Sitemaps         |  1  
  Cleaned          |  0  

Watching for changes in ~/dev/one-click-hugo-cms-dev.to-post/site/{content,data,layouts,static}
Press Ctrl+C to stop
Watching for config changes in site/config.toml
ℹ ｢wds｣: Project is running at http://localhost:3000/
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: Content not from webpack is served from ~/dev/one-click-hugo-cms-dev.to-post/dist
ℹ ｢wds｣: 404s will fallback to /index.html
ℹ ｢wdm｣: wait until bundle finished: /
ℹ ｢wdm｣: Hash: c80db40b3737e7b46070
Version: webpack 4.42.0

Good! From here just open your browser, navigate to http://localhost:3000, and make sure your coffee website loads.

Login into your local CMS backend

The last step, I promise. Navigate to your CMS login page, http://localhost:3000/admin/, click on the "Login with GitHub" button.

This should open up a separate window asking you to give your GitHub OAuth app the required permissions.

Just follow the steps and after a few clicks the window should close and you are now authenticated into your CMS and ready to write some new content.

Conclusion

Alright, you've done it! Grab a drink, sit back, and relax with confidence that you authentication system is working and secure, backed by GitHub.

I'm only human so if you see any mistakes please do not hesitate to leave a comment correcting me! I'd really appeciate the help.

If you run into any errors make sure to double check your work. If you can't figure it out then leave a comment with your situation and any relevant errors.

Securing Microservices with Auth0 Pt. 4 (Bring it all together)

Brandon Benefield — Thu, 03 Oct 2019 21:59:14 +0000

This is the third part to a series of posts called Securing Microservices with Auth0. If you missed the previous post, I would suggest you go back and read that post first.

Overview

In this part of the Securing Microservices with Auth0 series, we're going to finally secure our Resource Service by requiring that all requests to an endpoint must first go through our Auth Service. If you remember from the previous post, if the request fails due to an invalid access_token then the request stops there. If the request goes through and sends over a valid User we can then make a query to our DB to perform CRUD operations on behalf of a user.

Just to clarify the Auth Flow, let's take another look at the diagram from the previous post.

Make request from client side (or Postman), passing up our access_token
Resource Service make request to Auth Service
Auth Service sends access_token to Auth0
Auth Service sends a User object back to Resource Service
Resource Service performs CRUD operation
Return data back to the client

Back to the Resource Service

Create `RestInterceptorAll` Interceptor

Back in our Resource Service, we need to create another Interceptor. This Interceptor is going to be very similar to the Interceptor from our Auth Service and the idea is pretty much the same. Go ahead and create a new package in your Resource Service, Interceptors, and create a new class, RestInterceptorAll.java.

RestInterceptorAll.java

package ${}.${}.TodoApp_API.Interceptors;

import ${}.${}.TodoApp_API.Models.User;
import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestTemplate;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
public class RestInterceptorAll extends HandlerInterceptorAdapter {

    @Override
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) throws Exception {
        try {
            HttpHeaders headers = setAuthorizationHeader(req);
            HttpEntity<String> entity = new HttpEntity<>("headers", headers);
            User user = getUserInfoFromAuthService(entity);
            req.getSession().setAttribute("user", user);
            return super.preHandle(req, res, handler);
        } catch (Exception e) {
            // Users "access_token" is wrong so we should notify them that they're unauthorized (401)
            res.setStatus(401, "401 Unauthorized");
            // Return "false" so the "ValidateController" method isn't called
            return false;
        }
    }

    // Sets the "Authorization" header value (Authorization: Bearer ${access_token})
    private HttpHeaders setAuthorizationHeader(HttpServletRequest req) {
        HttpHeaders headers = new HttpHeaders();
        headers.set("Authorization", req.getHeader("Authorization"));
        return headers;
    }

    // Sends a GET request grab the users info
    private User getUserInfoFromAuthService(HttpEntity<String> entity) {
        RestTemplate httpRequest = new RestTemplate();
        return httpRequest.exchange(
                "http://localhost:8081/api/validate",
                HttpMethod.GET,
                entity,
                User.class
        ).getBody();
    }

}

I'm sure you'll notice that it's extremely similar to our Auth Service, and like I said, the idea is pretty much the same.

Intercept requests to an endpoint
Make HTTP request to our Auth Service
Auth Service will then validate the access_token

Create `MvcConfig` Config

Again, similar to our Auth Service, we need to register our Interceptor. Create a new package, Configs, and inside create a new file, MvcConfig.java

MvcConfig.java

package ${}.${}.TodoApp_API.Configs;

import ${}.${}.TodoApp_API.Interceptors.RestInterceptorAll;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    private RestInterceptorAll restInterceptorAll;

    @Autowired
    public MvcConfig(RestInterceptorAll restInterceptorAll) {
        this.restInterceptorAll = restInterceptorAll;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // Registers our "RestInterceptorAll" into the list of global interceptors
        registry.addInterceptor(restInterceptorAll);
    }

}

Revisiting the `TodoController` Controller

Now that we've registered our Interceptor, we need to alter our Controller for some additional security. At this point, a user could easily send up an access_token that is for user1@gmail.com but they could send this from the /api/todos/user2@gmail.com. We need to make sure that not only is the access_token valid, but that we're grabbing data for the correct user.

To save space, I'm only going to show a portion of the TodoController. I'd really like to encourage you to use the same pattern in this @GetMapping method and try to secure the rest of your methods. If you have trouble, don't worry, I'll provide the updated code in the controller.

TodoController.java

@RestController
@RequestMapping("/api/todos")
public class TodoController {

    private TodoService todoService;

    @Autowired
    public TodoController(TodoService todoService) {
        this.todoService = todoService;
    }

    /**
     * Returns a List of Todos
     * Here we are adjusting the parameters for our "GetAll" method
     * We want to grab the User object being passed around the current session
     * and compare the users email address from the User object with the
     * path variable for the current URL
     * If something doesn't match we're going to tell the user that they're
     * 401 Unauthorized
     */
    @GetMapping("/{userEmailAddress}")
    public List<Todo> findAllByUserEmailAddress(
            @SessionAttribute User user,
            @PathVariable String userEmailAddress,
            HttpServletResponse res) {

        if (user.getEmail().equals(userEmailAddress)) {
            return todoService.findAllByUserEmailAddress(userEmailAddress);
        } else {
            todoService.unAuthorizedAccess(res);
            return null;
        }
    }

    ... the rest of the methods are down here ...
}

Conclusion

Wow, you did it! You should have a pretty secure set of microservices ready to be extended into whatever amazing project you can think up.

I'm sure I'll get a few confusing looks about why we're not wiring up the frontend we create in part one. That's because this really wasn't meant to be a full-fledged tutorial on React and I really wanted to focus on the backend. Hopefully, if you made it this far, you learned something new and I encourage you to flesh out your frontend. If you do happen to finish this project, be sure to host it somewhere and share it in the comments below.

What did we learn?

The Microservice Architecture
Securing a SPA with Auth0
Spring Interceptors
How to make HTTP requests using RestTemplate from Spring
How to validate access_tokens

Securing Microservices with Auth0 Pt. 3 (Auth Service)

Brandon Benefield — Sat, 28 Sep 2019 20:03:11 +0000

This is the third part to a series of posts called Securing Microservices with Auth0. If you missed the previous post, I would suggest you go back and read that post first.

Overview

In this part of the Securing Microservices with Auth0 series, we're going to create the Auth Service microservice. The Auth Services job is to keep our applications' endpoints secure from any malicious users.

The idea here is that when a user makes a request from the frontend to an endpoint, sending up an Authorization: Bearer ${access_token} header, the request will then be redirected to our Auth Service where that access_token will be sent to our /userinfo endpoint provided to us by Auth0. Auth0 will attempt to validate the token and if successful our request will then be sent to an endpoint on our Auth Service that will finally return a User object to our API that will eventually return some data back to the frontend. Now, that was a lot of information so hopefully, this flowchart will help.

You can also go ahead and play around with the code for this post. This branch, bbenefield89/tutorial_pt3, is the UI, Insecure RESTful API (Resource Service), and our Auth Service.

Create the Auth Service

Just like in the last part of this series, I've once again made the decision to go with the Spring Framework. You'll soon see how quick and effortless it is to secure your application(s) using Spring Security.

Let's head on over to the Spring Initializr and like last time, add in the details for your project and pick the libraries you'd like to start with.

Project Details

Libraries

Download your project and let's get started.

Inside our Auth Service

Because we'll eventually have multiple services running we need to make sure that each service uses an open port. Inside of your application.yml/application.properties go ahead and set your port to 8081.

application.yml

server:
  port: 8081

Create `User` Model

Create a new package called Models and inside create a new class called User.java and insert the following code.

User.java

package ${}.${}.TodoApp_Auth.Models;

import lombok.Data;

@Data
public class User {

    private String email;
    private boolean email_verified;
    private String family_name;
    private String given_name;
    private String locale;
    private String name;
    private String nickname;
    private String picture;
    private String sub;
    private String updated_at;

}

The User class will be used to map the response from https://auth0Username.auth0.com/userinfo to an object that will be passed back to your Resource Service. Back in our Resource Service we will then user the users email value to grab Todos specific to that user.

Create `RestInterceptorAll` Interceptor

Create a new package called Interceptor and inside create a new class called RestInterceptorAll.java and insert the following code.

RestInterceptorAll.java

package ${}.${}.TodoApp_Auth.Interceptors;

import io.github.bbenefield89.TodoApp_Auth.Models.User;
import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestTemplate;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
public class RestInterceptorAll extends HandlerInterceptorAdapter {

    @Override
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) throws Exception {
        /**
         * Wrap the logic of this method in a try/catch
         * If this method fails then we know that something is wrong with the "access_token"
         */
        try {
            HttpHeaders headers = setAuthorizationHeader(req);
            HttpEntity<String> entity = new HttpEntity<>("headers", headers);
            User user = getUserInfoFromAuth0(entity);
            req.getSession().setAttribute("user", user);
            return super.preHandle(req, res, handler);
        } catch (Exception e) {
            // Users "access_token" is wrong so we should notify them that they're unauthorized (401)
            res.setStatus(401, "401 Unauthorized");
            // Return "false" so the "ValidateController" method isn't called
            return false;
        }
    }

    // Sets the "Authorization" header value (Authorization: Bearer ${access_token})
    private HttpHeaders setAuthorizationHeader(HttpServletRequest req) {
        HttpHeaders headers = new HttpHeaders();
        headers.set("Authorization", req.getHeader("Authorization"));
        return headers;
    }

    // Sends a GET request grab the users info
    private User getUserInfoFromAuth0(HttpEntity<String> entity) {
        RestTemplate httpRequest = new RestTemplate();
        return httpRequest.exchange(
                "https://bbenefield.auth0.com/userinfo",
                HttpMethod.GET,
                entity,
                User.class
        ).getBody();
    }

}

Create `MvcConfig` Config

Create a new package called Configs and inside create a new class called MvcConfig.java and insert the following code.

MvcConfig.java

package ${}.${}.TodoApp_Auth.Configs;

import io.github.bbenefield89.TodoApp_Auth.Interceptors.RestInterceptorAll;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    private RestInterceptorAll restInterceptorAll;

    @Autowired
    public MvcConfig(RestInterceptorAll restInterceptorAll) {
        this.restInterceptorAll = restInterceptorAll;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // Registers our "RestInterceptorAll" into the list of global interceptors
        registry.addInterceptor(restInterceptorAll);
    }

}

Create `ValidateController` Controller

Create a new package called Controllers and inside create a new class called ValidateController.java and insert the following code.

ValidateController.java

package ${}.${}.TodoApp_Auth.Controllers;

import ${}.${}.TodoApp_Auth.Models.User;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.SessionAttribute;

@RestController
@RequestMapping("/api/validate")
public class ValidateController {

    // Really simple, if the request makes it this far we can return the "User" object
    @GetMapping
    public User validateUser(@SessionAttribute User user) {
        return user;
    }

}

Manually testing our Auth Service

Now that we've written our Auth Service we need to make sure things are working.

Grab an `access_token`

To get an access_token you need to start up your frontend and log in as a user. Typically, I just log in through Google. To actually get the access_token you need to call the getTokenSilenty() method that comes from react-auth0-wrapper.js on the frontend. As an example, you can take a look at my Profile.js component in the test() method near the bottom of the file.

The getTokenSilently() method will return your users access_token.

Test Auth Service through Postman

After getting the access_token make sure you copy it and open up Postman and let's make a GET request to our Auth Service.

Example Request

GET http://localhost:8081/api/validate

Headers: Authorization: Bearer ${access_token}

Example Response

{
    "email": "bsquared18@gmail.com",
    "email_verified": true,
    "family_name": "Benefield",
    "given_name": "Brandon",
    "locale": "en",
    "name": "Brandon Benefield",
    "nickname": "bsquared18",
    "picture": "https://lh6.googleusercontent.com/-ASD8&89ASD/photo.jpg",
    "sub": "google-oauth2|9071248919",
    "updated_at": "2019-09-28T18:21:16.685Z"
}

If you pass in invalid access_token you should receive an empty response with an HTTP Status 401 Unauthorized.

Conclusion

First, give yourself a pat on the back as you've completed the most difficult portion of this series. Security is extremely complicated and takes a long time to wrap your head around so congratulations!

Let's take a look at what you've learned in this post:

How to write Interceptors to intercept a request to a Controller
How to make HTTP requests using RestTemplate provided by Spring
How to deny access to an endpoint and return a custom HTTP Status
How to validate access_tokens sent from your frontend

In the next and final post (link coming soon) of this series, we're going to return to our Resource API where we will make a request to the API will be presented with a list of Todos from a specific user if they've been properly authenticated.

Securing Microservices with Auth0 Pt. 2 (Resource Service)

Brandon Benefield — Wed, 25 Sep 2019 21:59:36 +0000

This is the second part to a series of posts called Securing Microservices with Auth0. If you missed the previous post, I would suggest you go back and read that post first.

Overview

In this part of the Securing Microservices with Auth0 series, we're going to be creating the Resource Service microservice. The Resource Service will be our applications REST API and will perform CRUD operations on specific users Todos. By this I mean we will be able to:

C: Create (POST)
R: Read (GET)
U: Update (PATCH)
D: Delete (DELETE)

At first, this service will be insecure and will not need any sort of authentication. It's important that we see the issues that come with insecure applications both from the developer perspective and the user perspective. After creating our Auth Service, which will be a different microservice in another post in this series, we will then perform authorization on requests being sent to our Resource Service.

You can also go ahead and play around with the code for this post. This branch, bbenefield89/tutorial_pt2, is the UI portion and the insecure RESTful API (Resource Service).

Creating the Resource Service

For this series, I've decided to go with the Spring Framework to create our backend. Microservices are not Java/Spring Framework specific and we can just as easily create our microservices in any language that has the ability to create a web server and make HTTP requests. This means we could potentially create our Resource Service using Express the Node Web Framework and then turn around and create our Auth Service using Django the Python Web Framework. This is one of many of the advantages of going with a microservice architecture when creating your applications.

Enough talk, it's time for action! Let's head over to Spring Initializr where you can quickly create the boilerplate code for your Spring application.

When you land on the Spring Initializr page go ahead and enter in the basic information for your project. As an example, my projects information will look like this:

And my chosen dependencies will be:

Go ahead and click on the green button at the bottom that says Generate the project. This will prompt you to download your project as a zip folder.

Unzip your project, feel free to discard the zipped folder, and let's open up our project in our favorite IDE and get to work.

Inside our Resource Service

Now that we're ready to go, let's find our first file at TodoApp_API/src/main/resources/application.properties and rename that to application.yml as I'm a fan of YAML when it comes to Springs configuration properties.

Inside our application.yml file you'll notice it's empty. Go ahead and place the following text inside:

server:
  port: 8080

It's not much, and to be honest Spring defaults it's PORT to 8080 but I like to be as clear as possible, especially when we have multiple services for the same application.

Creating the `Todo` Entity

We've already discussed the application and yes, this is going to be yet another todo app but I believe creating something you're familiar with is best when learning about new technology. Might as well focus on the technology instead of the logic.

Create a new package at TodoApp_API/src/main/java/${}/${}/TodoApp_API and name it Entities (TodoApp_API/src/main/java/${}/${}/TodoApp_API/Entities). This package is where we're going to create all of our Entities which are basically just a Java representation of a row in our DB.

Inside the Entities folder, create a new Java file and name it Todo.java and inside of it place the following code (filling in the ${} with your own path). Be sure to read the comments as I'll explain some of the code as we go.

Todo.java

package ${}.${}.TodoApp_API.Entities;

import lombok.Data;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

/**
 * This annotation comes from "Lombok" and allows us to forget about writing
 * a lot of boilerplate code like "Constructors/Getters/Setter"
 */
@Data
// Creates this class as a Bean to be picked up by Spring
@Entity
public class Todo {

    // Lets JPA know this is the unique identifier for our DB
    @Id
    // Sets the value that should be automatically generated for our ID in the DB
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    // We'll use the users' email address to find a user's todos
    private String userEmailAddress;

    /**
     * Notice we don't have to write anything else
     * Lombok will take care of this for us
     */

}

Creating the `TodoRepository` "Repository"

The Repository for an Entity is going to be an interface that will extend another interface that comes with a ton of helpful methods to perform all of our CRUD operations.

Create another package named TodoRepositories and place it at TodoApp_API/src/main/java/${}/${}/TodoApp_API/Repositories. Inside create a new file named TodoRepository.java and inside place the following code:

TodoRepository.java

package ${}.${}.TodoApp_API.Repositories;

import ${}.${}.TodoApp_API.Entities.Todo;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

import java.util.List;

/**
 * Sets this interface up to be found by Spring
 * Later on we'll be taking advantage of the @Autowired annotation where this interface will then become a
 * concrete class
 */
@Repository
/**
 * Our repository interface needs to extend the JpaRepository interface and pass along two arguments
 * 1. The Entity class that this repository is responsible for
 * 2. The id data type we chose for the Entity this Repository is responsble for
 * In this example, we've chosen to create our id as a Long data type
 */
public interface TodoRepository extends JpaRepository<Todo, Long> {

    /**
     * This is a custom method we'll be using to get a list of todos depending on the users email address
     * JPA supports a type of DSL where we can create methods that relate to an Entity by using keywords
     * 1. "findAll": returns a List of Todo
     * 2. "By": This signifies that we are going to be giving something specific to look for in the DB
     * 3. "UserEmailAddress": Find a Todo that contains the correct "userEmailAddress" in the DB
     */
    public List<Todo> findAllByUserEmailAddress(String userEmailAddress);

    /**
     * Another custom method. This method will take the ID of a Todo and the users email address to return a
     * single Todo
     */
    public Todo findByIdAndUserEmailAddress(Long todoId, String userEmailAddress);

    /**
     * This custom method will delete a single Todo depending on the ID and the userEmailAddress
     */
    public void deleteByIdAndUserEmailAddress(Long todoId, String userEmailAddress);

}

That's it for our Repository. We've only added a few methods but JpaRepository will still give us access to a lot more of the inner methods that we haven't defined.

Creating the `TodoService` "Service"

The idea behind a Service in this context is to bridge the gap between a Controller and a Repository. This is also where you will write your business logic. Splitting up your code like this keeps things small and typically easier to reason about.

Go ahead and create another package named Services and place it at TodoApp_API/src/main/java/${}/${}/TodoApp_API/Services. Inside, create a file named TodoService.java.

TodoService.java

package ${}.${}.TodoApp_API.Services;

import ${}.${}.TodoApp_API.Entities.Todo;
import ${}.${}.TodoApp_API.Repositories.TodoRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

/**
 * Lets Spring know to pick this up at runtime
 * You've probably noticed that so far we haven't really told Spring when to use any of our classes and that's
 * because of "Component Scanning". To learn more about the Component Scanning go to the following URL
 * https://www.baeldung.com/spring-component-scanning
 */
@Service
public class TodoService {

    TodoRepository todoRepository;

    /**
     * @Autowired annotation sets this constructor to be called when booting our application and will automagically
     * inject any dependencies that we specify in the arguments
     * This is also known as "Dependency Injection" and is one of the more attractive aspects of the Spring Framework
     */
    @Autowired
    public TodoService(TodoRepository todoRepository) {
        this.todoRepository = todoRepository;
    }

    // Returns a List of all of a users Todos
    public List<Todo> findAllByUserEmailAddress(String userEmailAddress) {
        return todoRepository.findAllByUserEmailAddress(userEmailAddress);
    }

    // Return a single Todo
    public Todo findByIdAndUserEmailAddress(Long todoId, String userEmailAddress) {
        return todoRepository.findByIdAndUserEmailAddress(todoId, userEmailAddress);
    }

    // Create/Update a new Todo and returns that Todo
    public Todo save(String userEmailAddress, Todo todo) {
        todo.setUserEmailAddress(userEmailAddress);
        return todoRepository.save(todo);
    }

    // Delete a Todo
    public void deleteByIdAndUserEmailAddress(Long todoId, String userEmailAddress) {
        todoRepository.deleteByIdAndUserEmailAddress(todoId, userEmailAddress);
    }

}

Creating the `TodoController` "Rest Controller"

Okay, we're almost finished with our first pass on our Resource Service. We just need to create the Controller that will determine our services' URL endpoints.

Create your final package named Controllers and place it at TodoApp_API/src/main/java/${}/${}/TodoApp_API/Controllers. Inside, create yet another file and name it TodoController.java and place the following code inside.

TodoController.java

package io.github.bbenefield89.TodoApp_API.Controllers;

import io.github.bbenefield89.TodoApp_API.Entities.Todo;
import io.github.bbenefield89.TodoApp_API.Services.TodoService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api/todos")
public class TodoController {

    private TodoService todoService;

    @Autowired
    public TodoController(TodoService todoService) {
        this.todoService = todoService;
    }

    // Returns a List of Todos
    @GetMapping("/{userEmailAddress}")
    public List<Todo> findAllByUserEmailAddress(@PathVariable String userEmailAddress) {
        return todoService.findAllByUserEmailAddress(userEmailAddress);
    }

    // Returns a single Todo
    @GetMapping("/{userEmailAddress}/{todoId}")
    public Todo findByIdAndUserEmailAddress(@PathVariable String userEmailAddress, @PathVariable Long todoId) {
        return todoService.findByIdAndUserEmailAddress(todoId, userEmailAddress);
    }

    // Creates a new Todo
    @PostMapping("/{userEmailAddress}")
    public Todo save(@PathVariable String userEmailAddress, @RequestBody Todo todo) {
        return todoService.save(userEmailAddress, todo);
    }

    // Deletes a single Todo
    @DeleteMapping("/{userEmailAddress}/{todoId}")
    public void deleteByIdAndUserEmailAddress(@PathVariable String userEmailAddress, @PathVariable Long todoId) {
        todoService.deleteByIdAndUserEmailAddress(todoId, userEmailAddress);
    }

}

Manually testing our endpoints

Now that we've written our endpoints it's time we test them to make sure everything works. I would suggest downloading Postman for API testing.

Let's go ahead and start making some HTTP requests.

POST `localhost:8080/api/todos/user@gmail.com` (Create Todo)

Example Request

{
    "title": "Get a haircut",
    "userEmailAddress": "user@gmail.com"
}

Example Response

{
    "id": 1,
    "title": "Get a haircut",
    "userEmailAddress": "user@gmail.com"
}

GET `localhost:8080/api/todos/user@gmail.com` (Get All Todos)

Example Request

Nothing required

Example Response

[
    {
        "id": 1,
        "title": "Get a haircut",
        "userEmailAddress": "user@gmail.com"
    }
]

GET `localhost:8080/api/todos/user@gmail.com/1` (Get a Single Todo)

Example Request

Nothing required

Example Response

{
    "id": 1,
    "title": "Get a haircut",
    "userEmailAddress": "user@gmail.com"
}

DELETE `localhost:8080/api/todos/user@gmail.com/1` (DELETE a Single Todo)

Example Request

Nothing required

Example Response

Nothing returned

Great, everything works! The only problem now is that our endpoints aren't secured (to be fair we don't really have any users either). This means, you as the user hacker_man@gmail.com could easily access my data and vice versa.

Conclusion

In this post, you didn't learn much about Spring or Auth0 but you did learn about creating RESTful endpoints which is an important step to the process. Not to mention, you now see how easy it is for insecure endpoints to be accessed by the wrong people.

In the next section of this series (link coming soon), you'll get an introduction on how to create a very simple Auth Service that uses:

Spring Security: Prevent access to users that are not authed
Prehandle: A method to intercept requests to endpoints that we can use to run logic before all requests (the secret sauce of our auth)

Securing Microservices with Auth0 Pt. 1 (UI)

Brandon Benefield — Sun, 22 Sep 2019 22:45:48 +0000

Overview

This is going to be a series of posts where I will walk you through creating a SPA using React and using a Microservice Architecture to create your backend with the Spring Framework (Resource API, Authentication Server) using Auth0 to secure your frontend and microservices.

You can also go ahead and play around with the code for this post. This branch, bbenefield89/tutorial_pt1, is just the UI portion for now. You can also take a look at the master branch if you'd like but that branch is specifically for me to play around with as I write this series.

If you decide to play around with the code I've provided, you're going to need to create a file at todoapp_ui/src/auth_config.json and inside you will need to provide some credentials that are specific to your Application on Auth0.

Example auth_config.json

{
    "domain": "myAuth0Username.auth0.com",
    "clientId": "as98d6ashasdH"
}

What is a Microservice

In short, the Microservice Architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

-- James Lewis and Martin Fowler (2014)

Just to clarify, a Microservice is a small subset of your entire application. This is the exact opposite of a Monolithic application where everything is written and contained in the same code base, everything runs on the same PORT whereas each Microservice will be self-contained and running on a different PORT.

The advantages of going with a Microservice Architecture is that we break out our application into smaller more digestible pieces of code. Coming from mainly the frontend, React, the way I wrapped my head around this idea is how we write components. For example, let's say we were writing a component to take in some data, iterate over the data, and display this to the user.

class TodoList extends Components {

    // state

    render() {
        return (
            <ul>
                {this.state.todos.map(todo => {
                    return <li key={todo.id}>{todo.title}</li>
                })}
            </ul>
        )
    }

    // methods grabbing data and saving in state

}

While this isn't the worst thing to do, we could break our components apart so that each one of our components is only concerned with one thing. We will now create a component, TodoList, which will render a list of todos. Then we will create a TodoItem component which is only concerned with that one single todo item.

Todolist.js

class TodoList extends Components {

    // state

    render() {
        return (
            <ul>
                {this.state.todos.map(todo => {
                    return <TodoItem key={todo.id} title={todo.title} />
                })}
            </ul>
        )
    }

    // methods grabbing data and saving in state

}

TodoItem.js

function TodoItem({ title }) {
    return (
        <li>{title}</li>
    )
}

While yes this is a small example it should serve its purpose of an example of a Microservice. I would like to point out that I'm not saying React components are Microservices but this is just an easy way of explaining what a Microservice could be. We now have two separate "services" that are concerned with one thing and only one thing. TodoList is concerned with iterating over data and TodoItem is concerned with what to do with the data passed down as props.

Now, the way we're going to go about creating our Microservices will be in the form of a Resource Service (Todo API) and an Auth Service. This could also be extended and you could go ahead and write some other services as your project grows, Email/Notification Service, Message Queue Service, etc.

Frontend: Handles UI and Authentication with Auth0
Resource Service: Responsible for CRUD operations for our Todo's
Auth Service: Responsible for Authorizing requests to any of our Microservices

Aside

It's important to understand the difference between Authentication and Authorization.

Authentication: When you log into an application you are being Authenticated
Authorization: When you are requesting resources, API, webpage, etc., you are then being checked if you are Authorized to access the resource(s).

Let's write some code

With that explanation out of the way, we can finally get started writing some code. In this post, we're going to write the UI for our application. We will also write the logic to secure frontend routes that can only be accessed to users who have been Authorized to access the page.

Create React App

Open up your terminal, using the npx command provided by npm let's create our frontend boilerplate

user@group:~/$ npx create-react-app todoapp_ui

After your boilerplate application has been created let's go ahead and open up the app in our favorite IDE.

Install Auth0 Dependency

Next, we need to install the @auth0/auth0-spa-js dependency in order to auth users. We will also be using the access_token that we receive after successfully authenticating a user to later authorize requests to our Resource Server.

user@group:~/todoapp_ui$ npm i @auth0/auth0-spa-js

Create Auth0 Account + Application (Free)

Before moving on we need to set up an account with Auth0. Afterwards, go ahead and create your first Application. Go ahead and click on the Applications link on the left hand side.

From there, look to the far right of your screen and click the large orange button + CREATE APPLICATION.

Name your app, mine will be named TodoApp, and choose the Single Page Web Application option.

Choose the Quick Start tab and select React, or you can use another type but for this tutorial, we're going to use React.

From here, instead of rewriting everything that Steve Hobbs from Auth0 has written, I would suggest you go ahead and follow his tutorial. Just follow this specific tutorial, don't go to the next tutorial, Calling an API.

Manually testing our frontend

After you've gone through the tutorial from Auth0 you should have a fully functioning frontend with public and private routes. Users who have logged in should be able to access their Profile on your application and those who are not authorized should be redirected to the Home Page.

Conclusion

In this post, we learned how easily we can secure our frontend routes and have complete user auth in just a few easy steps.

In the next post, we're going to start building out the Resource Service to grab our users Todos. First, it will insecure and in the final post, we will write the logic to secure the endpoints from a completely different Microservice.

Webpack: How to Create Dynamic Entry & Output paths

Brandon Benefield — Sun, 01 Sep 2019 20:48:48 +0000

TLDR;

For those that don't want to read and just want the config file then here you go. All you need to do is change the path string passed to the glob.sync(...) method to match your needs.

const glob = require('glob')
const path = require('path')

module.exports = {
    entry: glob.sync('./Projects/**/index.js').reduce((acc, path) => {
        const entry = path.replace('/index.js', '')
        acc[entry] = path
        return acc
    }, {}),

    output: {
        filename: './[name]/main.js',
        path: path.resolve(__dirname)
    }
}

The idea behind creating dynamic entry and output paths with Webpack might seem confusing. When I was trying to figure out the situation and began to ask around, I received a lot of "Why do you need that?".

The "why" is pretty simple. I've found myself in a situation where I'm writing a lot of one-off scripts, each doing something of their own and typically have nothing to do with another script. Because of this, I had some very niche needs for my project. Mainly, having the ability to build and minify each script into their own subdirectory.

The real magic of this Webpack config file is in the entry property. The entry property is capable of taking:

string

entry: './my/path/index.js'

string[]

entry: ['./my/first/path/index.js', './my/second/path/index.js']

object

entry: {
    'my/first/path': './my/first/path/index.js',
    'my/second/path': './my/second/path/index.js'
}

Function => string | string [] | object

entry: () => './my/path/index.js'

Now, let's dive into what's actually happening in this config file. Make sure to read the comments as I'm going to attempt to explain everything going on in the code itself as comments.

webpack.config.js

/**
 * When passed a string, Glob will attempt to find each file that matches the
 * path given and return each path to the file as string[]
 */
const glob = require('glob')

/**
 * The Path API will be used to get the absolute path to the directory where we
 * plan to run Webpack
 */
const path = require('path')

module.exports = {
    /**
     * Pass Glob a relative path to each of our entry points
     * We will have different subdirectories inside of the Project directory so
     * we need to replace any of the directory names with a wildcard, **, which 
     * will recursively match any combination of directory names inside of any
     * number of subdirectories until it finds the index.js entry.
     * Then we use the Array.prototype.reduce method to iterate through the array
     * and return an object containing a path to each of our entry files
     * (index.js)
     */
    entry: glob.sync('./Projects/**/index.js').reduce((acc, path) => {
        /**
         * The "[name]" placeholder in the "output" property will be replaced
         * with each key name in our "entry" object. We need to make sure the
         * keys are a path to the "index.js" file but without the actual file
         * name. This is why we replace the file name, "index.js", with a string
         */
        const entry = path.replace('/index.js', '')
        /**
         * Here we start building our object by placing the "entry" variable from
         * the previous line as a key and the entire path including the file name
         * as the value
         */
        acc[entry] = path
        return acc
    }, {}),

    /**
     * The "output" property is what our build files will be named and where the
     * build file will be placed
     */
    output: {
        /**
         * Again, the "[name]" place holder will be replaced with each key in our
         * "entry" object and will name the build file "main.js"
         */
        filename: './[name]/main.js',
        /**         
         * We need to provide an absolute path to the root of our project and
         * thats exactly what this line is doing
         */
        path: path.resolve(__dirname)
    }
}

Result

This is all you need to create dynamic entry & output paths with Webpack. The question now is what kind of project architecture does this example work with?

> node_modules
  package.json
  package-lock.json
> Projects
  ---- > Proj_1
         ---- index.js
  ---- > Proj_2
         ---- index.js
  webpack.config.js

After running our Webpack and building our files our project will then look like

> node_modules
  package.json
  package-lock.json
> Projects
  ---- > Proj_1
         ---- index.js
         ---- main.js  // new build file
  ---- > Proj_2
         ---- index.js
         ---- main.js  // new build file
  webpack.config.js

Creating/Dispatching Custom JS Events

Brandon Benefield — Wed, 26 Jun 2019 03:34:11 +0000

Here's a quick introduction to creating and dispatching custom events. Much like click and change, we're also able to create, have elements watch for, and trigger our very own events.

There's two API's provided that we can access:

Event:

Few config options
Straight forward
Creates a new event

CustomEvent:

Same as Event
Flexible
Customizable config object

Simple custom events

/**
 * Simple custom event
 */
// Grab a reference to the <p> element
const p = document.querySelector('p')

// create a new event
const pEvent = new Event('pEvent')

// listen for the 'pEvent' on the <p> element
p.addEventListener('pEvent', e => {
  console.log('pEvent')
})

// trigger, or 'dispatch', the 'pEvent' event
p.dispatchEvent(pEvent)  // -> 'pEvent'

Add 'Event Bubbling' to a custom event

/**
 * Custom event with bubbling
 * Read more about 'bubbling' and 'capturing': https://javascript.info/bubbling-and-capturing
 */
const div = document.querySelector('div')
const divEvent = new Event('divEvent', { bubbles: true })

div.addEventListener('divEvent', e => {
  // should read 'Event dispatched from HTMLParagraphElement'
  console.log(`Event dispatched from ${e.target.constructor.name}`)
})

p.addEventListener('pEvent', e => {
  e.target.dispatchEvent(divEvent)
})

// Dispatch the event from the <p> element
// Notice that the event 'bubbles' up to the parent <div> tag
p.dispatchEvent(pEvent)

Triggering events built into JS

/**
 * Dispatching existing JS events (click, change, etc.)
 */
const button = document.querySelector('button')

button.addEventListener('click', () => {
  console.log('Button Clicked')
})

button.dispatchEvent(new Event('click'))  // Dispatch click using 'dispatchEvent'
button.click()  // Directly calling 'click' also works in this example

repl.it example of these examples in action

Example of when to use

Say, for example, you don't have access to the code base of a project you've been assigned. Say, for example, you can only use plain JavaScript. Now, let's say the project you're working on is using a hodgepodge of HTML/CSS/JS and Vue components all hanging out on the same page.

Now in this scenario, you need to access a method on an input that's triggered by the inputs change event, something along the lines of <input class="my_input" :onChange="makeChange" />, but only after a button on the page has been clicked. Well, if we're injecting a script and we don't have access to any of the components methods and properties this could be a pretty challenging task.

The quick and easy solution here is to dispatch the elements change event similar to the examples above.

const myInput = document.querySelector('.my_input')
const myButton = document.querySelect('.my_button')

myButton.addEventListener('click', () => {
  // dispatches the inputs 'change' event
  myInput.dispatchEvent(new Event('change'))
})

Fixing NPM Dependencies Vulnerabilities

Brandon Benefield — Thu, 13 Jun 2019 02:23:29 +0000

TLDR;

Run the npm audit command
Scroll until you find a line of text separating two issues
Manually run the command given in the text to upgrade one package at a time, e.g. npm i --save-dev jest@24.8.0
After upgrading a package make sure to check for breaking changes before upgrading the next package
Avoid running npm audit fix --force

Vulnerabilities

Every now and then after installing your projects dependencies, npm i, you will be met with an error from NPM that looks something like

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ braces                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jest [dev]                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ jest > jest-cli > micromatch > braces                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/786                       │
└───────────────┴──────────────────────────────────────────────────────────────┘


found 62 low severity vulnerabilities in 20610 scanned packages
  62 vulnerabilities require semver-major dependency updates.

This is actually an extremely small example of a typical vulnerability warning. As you can see from the text underneath the vulnerability it says

found 62 low severity vulnerabilities in 20610 scanned packages
  62 vulnerabilities require semver-major dependency updates.

Meaning that this example would have another 61 vulnerabilities ranging from low to high with of course high being the most dangerous vulnerability. For more info on any of these vulnerabilities, there is also a link to the vulnerability on NPM inside the More Info section of the warning.

At first, it may seem confusing on how to properly fix these vulnerabilities. NPM actually provides a service built into NPM that is supposed to automatically fix these issues, npm audit fix, but I've found that this will rarely work, and will leave you with nearly just as many vulnerabilities as before. In fact, here's an example of what happened after I ran npm audit fix.

fixed 0 of 62 vulnerabilities in 20610 scanned packages
  1 package update for 62 vulns involved breaking changes
  (use `npm audit fix --force` to install breaking changes; or refer to `npm audit` for steps to fix these manually)

NPM gives us the option to use the --force flag, npm audit fix --force, but even NPM will warn you about using this flag

user@group:~/npm_project$ npm audit fix --force
npm WARN using --force I sure hope you know what you are doing.

So what are we supposed to do? If our package manager isn't able to fix these vulnerabilities then surely we're out of luck and must find a way to survive with these vulnerabilities hoping nobody decides to exploit them against our project.

The Fix

Manually upgrade the packages one at a time with the command suggested by NPM instead of running the npm audit fix --force command. For example npm install --save-dev jest@24.8.0.

First of all, I want to say that this might be incredibly obvious to those that have run into this problem before. When I first saw these, it was a gigantic list of warnings and being the lazy developer that I am, I didn't even bother to scroll through the issues.

If you just continue to scroll up inside your console to the very first issue you'll actually run into a fix and yes, as you would expect, it's as simple as updating the package that's causing the issue.

user@group:~/npm_project$ npm audit --fix

                       === npm audit security report ===                        

# Run  npm install --save-dev jest@24.8.0  to resolve 62 vulnerabilities
SEMVER WARNING: Recommended action is a potentially breaking change
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ braces                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jest [dev]                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ jest > jest-cli > jest-config > babel-jest >                 │
│               │ babel-plugin-istanbul > test-exclude > micromatch > braces   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/786                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

... 61 more vulerabilities ...

Right before the vulnerability issue you'll notice the text # Run npm install --save-dev jest@24.8.0 to resolve 62 vulnerabilities which is exactly what we're looking for. You may also notice that the very next line says SEMVER WARNING: Recommended action is a potentially breaking change. Manually running this command instead of using the npm audit fix --force command lets us know exactly which packages we're updating. This is valuable for the scenario where updating these packages actually causes a breaking change.

Summary

So in the end, manually upgrading the vulnerable packages and running npm audit fix --force is going to have the same results. The only difference is that manually upgrading our packages will allow us to upgrade a single package, test for a breaking change, then update the next package, instead of just upgrading all of the packages at once, find a breaking change, then having no idea which package decided to screw things up.

How to Dockerize an ExpressJS Application

Brandon Benefield — Fri, 31 May 2019 00:02:43 +0000

What this is

This is a short example on how to Dockerize an ExpressJS application.
This post also assumes you are working from a *NIX based OS such as Ubuntu 18.10

What this is not

This is not a thorough guide on Docker, NodeJS, ExpressJS, or any other technologies that may be used.
This does not explain or walk you through the installation process of Docker or any technologies used.

Create Directory

We need to create a directory. This is where we are going to place all of our Docker Images' files as well as our ExpressJS files.

foo@foo:~/path/to/current/directory$ mkdir node_docker_project

Create Dockerfile

CD into the new directory and create a new file and name it Dockerfile without any extension name.

foo@foo:~/path/to/current/directory$ cd node_docker_project
foo@foo:~/node_docker_project$ touch Dockerfile

Place the next piece of code inside of the Dockerfile.

# Tell Docker to use the "node" Docker Image at version "10.15.3"
FROM node:10.15.3
# Create our containers WORKDIR and "node_modules" directory.
# Give the user:group "node" ownership of all files/directories in our containers WORKDIR
RUN mkdir -p /home/node/app/node_modules && chown -R node:node /home/node/app
# Tell our container which directory to use as the WORKDIR
WORKDIR /home/node/app
# Copy over our local version of "package.json" and "package-lock.json" into our container
COPY package*.json ./
# Creates a user for our container
USER node
# Installs our NPM packages from the "package.json" file we moved from local in to our container
RUN npm install
# Tells our container who owns the copied content
COPY --chown=node:node . .
# Exposes the port "3000" from our container
# This is also how we can connect to our container from our host machine (the one you're reading this from now)
EXPOSE 3000
# An array of commands our container needs to run when we start it
CMD ["npm", "run", "start"]

Create app.js

const express = require('express')
const app = express()
app.get('/', (req, res) => {
  res.send('Hello, world!')
})
app.listen(3000, () => console.log('Server listening @ 3000'))

Create package.json

Let's create our package.json file to hold our dependencies.

foo@foo:~/node_docker_project$ npm init -y

Then we need to install those dependencies.

foo@foo:~/node_docker_project$ npm i express
foo@foo:~/node_docker_project$ npm i --save-dev nodemon

We need Express as that is going to be the framework we are using for our server and we need Nodemon so that we can have automatic server restart by default. This will come in handy as you change files from local to the container. Without Nodemon, you would need to restart your container every time you make a change just to see the changes.

Create our Docker Image

Think of a Docker Image as the recipe and a Docker Container as the meal. In order to eat the meal we need to cook it using a recipe.

foo@foo:~/node_docker_project$ docker build -t node_project
foo@foo:~/node_docker_project$ docker images
REPOSITORY     TAG      IMAGE ID     CREATED          SIZE
node_project   latest   3esadssa     10 Seconds Ago   908MB

foo@foo:~/node_docker_project$ docker run --name myNodeProject -v $(pwd):/home/node/app -d -p 3000:3000 node_project
foo@foo:~/node_docker_project$ docker ps
CONTAINER ID  IMAGE         COMMAND          CREATED
123klasdkj    node_project  "npm run start"  6 seconds ago

STATUS        PORTS                   NAMES
Up 4 seconds  0.0.0.0:3000->3000/tcp  myNodeProject

Check your work

Now that we've created our container and it's up and running, we are able to connect to our container via the opened port(s). In our case we opened one port at 3000.

Open your browser and navigate to http://localhost:3000 and you should be greeted with our Hello, World! message that we place in the app.get('/' ...) request in the app.js file we created earlier.

Check that we can change the container files from our host machine

Go ahead and change the response text in our app.js file from Hello, World! to Docker is amazing!.

const express = require('express')
const app = express()
app.get('/', (req, res) => {
  res.send('Docker is amazing!')  // change this line
})
app.listen(3000, () => console.log('Server listening @ 3000'))

Back in your browser, either refresh with f5 or navigate back to http://localhost:3000 and you should see the new response.

Summary

The basics of Docker is actually pretty simple. All you need to do is:

Get a Docker Image
Create a Docker Container
Connect to your container via the opened port(s)

DEV Community: Brandon Benefield

Create your own Serverless OAuth Portal for Netlify CMS

Contents

Acknowledgement

Prerequisites

Get your frontend running

Create the GitHub OAuth App

Save GitHub OAuth App credentials somewhere secure

Create your OAuth Lambdas

Triggering Lambdas

Write some OAuth code

From local to remote

Test your OAuth Lambdas

Start up your local frontend

Login into your local CMS backend

Conclusion

Securing Microservices with Auth0 Pt. 4 (Bring it all together)

Overview

Back to the Resource Service

Create RestInterceptorAll Interceptor

Create MvcConfig Config

Revisiting the TodoController Controller

Conclusion

What did we learn?

Securing Microservices with Auth0 Pt. 3 (Auth Service)

Overview

Create the Auth Service

Project Details

Libraries

Inside our Auth Service

Create User Model

Create RestInterceptorAll Interceptor

Create MvcConfig Config

Create ValidateController Controller

Manually testing our Auth Service

Grab an access_token

Test Auth Service through Postman

Conclusion

Securing Microservices with Auth0 Pt. 2 (Resource Service)

Overview

Creating the Resource Service

Inside our Resource Service

Creating the Todo Entity

Creating the TodoRepository "Repository"

Creating the TodoService "Service"

Creating the TodoController "Rest Controller"

Manually testing our endpoints

POST localhost:8080/api/todos/user@gmail.com (Create Todo)

GET localhost:8080/api/todos/user@gmail.com (Get All Todos)

GET localhost:8080/api/todos/user@gmail.com/1 (Get a Single Todo)

DELETE localhost:8080/api/todos/user@gmail.com/1 (DELETE a Single Todo)

Conclusion

Securing Microservices with Auth0 Pt. 1 (UI)

Overview

What is a Microservice

Aside

Let's write some code

Create React App

Install Auth0 Dependency

Create Auth0 Account + Application (Free)

Manually testing our frontend

Conclusion

Webpack: How to Create Dynamic Entry & Output paths

TLDR;

Result

Creating/Dispatching Custom JS Events

Simple custom events

Add 'Event Bubbling' to a custom event

Triggering events built into JS

Example of when to use

Fixing NPM Dependencies Vulnerabilities

TLDR;

Vulnerabilities

The Fix

Summary

How to Dockerize an ExpressJS Application

What this is

What this is not

Create Directory

Create Dockerfile

Create `RestInterceptorAll` Interceptor

Create `MvcConfig` Config

Revisiting the `TodoController` Controller

Create `User` Model

Create `RestInterceptorAll` Interceptor

Create `MvcConfig` Config

Create `ValidateController` Controller

Grab an `access_token`

Creating the `Todo` Entity

Creating the `TodoRepository` "Repository"

Creating the `TodoService` "Service"

Creating the `TodoController` "Rest Controller"

POST `localhost:8080/api/todos/user@gmail.com` (Create Todo)

GET `localhost:8080/api/todos/user@gmail.com` (Get All Todos)

GET `localhost:8080/api/todos/user@gmail.com/1` (Get a Single Todo)

DELETE `localhost:8080/api/todos/user@gmail.com/1` (DELETE a Single Todo)