Git Product home page Git Product logo

deprecated-hookshot's Introduction

deprecated-hookshot

⚠️ This repo has been deprecated. Please use @mapbox/cloudfriend shortcuts instead: hookshot shortcuts. ⚠️

hookshot

A simple helper to build a connection between 3rd-party service webhooks and your AWS Lambda functions.

Respond to Github push events

const hookshot = require('@mapbox/hookshot');
const webhook = hookshot.github('lambda function logical name');

You want to write a Lambda function and you want it to be triggered every time a push is made to a Github repository.

Hookshot helps you create a CloudFormation template that creates an API Gateway HTTPS endpoint. You define your Lambda function in the same template, and launch a CloudFormation stack. This provides you with a URL and a secret key that you can provide to a Github webhook integration.

Hookshot takes care of authenticating incoming requests. Any requests that did not come from Github or were not properly encrypted using your secret key are rejected, and will never make it to your Lambda function.

Your Lambda function will receive a shortened version of a Github push event. Here's an example:

{
  "ref": "refs/head/changes",
  "after": "0d1a26e67d8f5eaf1f6ba5c57fc3c7d91ac0fd1c",
  "before": "9049f1265b7d61be4a8904a9a27120d2064dab3b",
  "deleted": false,
  "repository": {
    "name": "public-repo",
    "owner": {
      "name": "baxterthehacker"
    }
  },
  "pusher": {
    "name": "baxterthehacker"
  }
}

However that data will be "wrapped" a few levels deep. To access the data as a JavaScript object, you will want your Lambda function's code to parse the incoming event as follows:

module.exports.handler = (event, context, callback) => {
  const message = JSON.parse(event.Records[0].Sns.Message);
}

Respond to arbitrary POST requests

const hookshot = require('@mapbox/hookshot');
const webhook = hookshot.passthrough('lambda function logical name');

If you simply need to be able to invoke a Lambda function through a straightforward POST request, hookshot has you covered here as well.

Note that in this case, your Lambda function will receive every HTTP POST request that arrives at the API Gateway URL that hookshot helped you create. You are responsible for any authentication that should be performed against incoming requests.

Your Lambda function will receive an event object which includes the request method, headers, and body, as well as other data specific to the API Gateway endpoint created by hookshot. See AWS documentation here for a full description of the incoming data.

In order to work properly, your lambda function must return a data object matching in a specific JSON format. Again, see AWS documentation for a full description.

CORS handling

Your API Gateway endpoint will be set up to allow cross-origin resource sharing (CORS) required by requests from any web page. Preflight OPTIONS requests will receive a 200 response with CORS headers. And the response you return from your Lambda function will be modified to include CORS headers.

How to use this module

  1. Create a CloudFormation template (in JavaScript) that defines
  • a Lambda function that you've designed to process incoming requests, and
  • the IAM role that your Lambda function will need in order to function.
  1. Use the JavaScript function exported by this module to create the rest of the resources required. Merge those resources with your own using cloudfriend.

  2. Create the CloudFormation stack by deploying your template using cfn-config, or by using cloudfriend's build-template command to produce the template as a JSON document and launch it in the AWS console.

  3. Your stack will output the URL for your webhook's endpoint, and a secret token. If generating a Github webhook, provide these values to Github as a new webhook (see settings/hooks/new for your repository). Make sure to specify the Content type as application/json.

There are a few examples of very simple github and passthrough templates in this repositories' /test/ directory.

deprecated-hookshot's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

deprecated-hookshot's Issues

Eng standards inventory

Required Elements

If any elements in the below list are not checked, this repo will fail standards compliance.

  • Not running node 4 or below
  • Has at least some test coverage?
  • Has a README?
  • Has no hard-coded critical secrets like API keys? (Use secret-shield -r $repo! Install info here.)

Rubric

  • 1 pt Is in Version Control/Github ✅ (free points)
  • 1-2 pt node version:
    • 2 pt Best: running node 8+ 🏅
    • 1 pt Questionable: node 6
    • 0 pt Not ok: running node4 or below ⛔️
  • 1 pt No hard-coded config parameters?
  • 1 pt No special branches that need to be deployed?
  • 1 pt All production stacks on latest master?
  • 1 pt No hard-coded secrets like API keys?
  • 1 pt No secrets in CloudFormation templates that don’t use [secure]?
  • 1 pt CI enabled for repo?
  • 1 pt Not running Circle CI version 1? (Point awarded if using Travis)
  • 1 pt nyc integrated to show test coverage summary?
  • 1-3 pt test coverage percentage from nyc?
    • 3 pt High coverage: > 90%
    • 2 pt Moderate coverage: between 75 and 90% total coverage
    • 1 pt 0 - 74% test coverage
  • 1-2 pt evidence of bug fixes/edge cases being tested?
    • 2 pt Strong evidence/several instances noted
    • 1 pt Some evidence
  • 1 pt no flags to enable different functionality in non-test environments?
  • 1 pt Has README?
  • 1-2 pt README explains purpose of a project and how it works to some detail?
    • 2 pt High (but appropriate) amount of detail about the project
    • 1 pt Some detail about the project documented, could be more extensive
  • 1 pt README contains dev install instructions?
  • 1 pt README contains CI badges, as appropriate?
  • 1-2 pt Code seems self-documenting: file/module names, function names, variables? No redundant comments to explain naming conventions?
    • 2 pt Strongly self-documented code, little to no improvements needed
    • 1 pt Some evidence of self-documenting code
  • 1 pt No extraneous permissions in IAM roles?
  • 1 pt Stack has alarms for AWS resources used routed to PagerDuty? (CPU utilization, Lambda failures, etc.)
  • 1 pt Stack has other appropriate alarms routed to PagerDuty? (Point awarded if no other alarms needed)
  • 1 pt Alarms documented?
  • master branch protected?
    • 1 pt PRs can only be merged if tests are passing?
    • 1 pt PRs must be approved before merging?
  • 2 pt BONUS: was this repo covered in a deep dive at some point?

Total possible: 30 points (+2 bonus)
Grading scale:

Point Total Qualitative Description Scaled Grade
28+ points Strongly adheres to eng. standards 5
23-27 points Adheres to eng. standards fairly well 4
18-22 points Adheres to some eng. standards 3
13-17 points Starting to adhere to some eng. standards 2
9-12 points Following a limited number of eng. standard practices 1
< 9 points Needs significant work, does not follow most standards 0

Repo grade: 2 (13 points)

cc @mapbox/assembly-line

CF template with multiple webhooks would have naming collisions

The generic resource names like "WebhookApi" mean that you can only use hookshot once within any given CloudFormation template, right? (Otherwise, one webhook's resources would override the other's.)

Am right in thinking there are reasons you might want to have multiple webhooks within a single template — or is that bad thinking? If so, maybe we can scope the resource names to fit the specific Lambda function?

Return full message from GitHub

First, this is really awesome!

Just a quick note, returning a shortened version of the message is good in the case when you want to subscribe for a Push event, but I think it could be useful to return the full message if the user (me) want to subscribe to other event other than Push.

cc @rclark

Update readme to be general

Readme is pretty specific to github. Let's pivot in a direction where we are giving helpers for a variety of 3rd-party services (e.g. pagerduty and slack)

Use API key instead of creating an AWS IAM user

From reading the template, it looks like the AWS IAM user is only created to generate a secret key. While the user has no permissions, generally abusing IAM users like this should be avoided, and future scheduled IAM clean ups would most likely target such users for immediate deletion.

API Gateway has a key service built-in, and regardless of whether or not you use the API key to restrict access via the native API gateway key validation, or build the API key validation into your function, it's preferable to creating an IAM user for this.

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-apikey.html

Replace AWS::ApiGateway::Deployment name on updates

When I was updating the request template for the API Gateway passthrough method, I noticed that the method was not updating between CloudFormation updates. The updates only went into effect if I deleted and recreated the stack.

I think this can be avoided by creating a random resource name each time the stack is updated. This forces the original resource to be deleted, and the new resource to be created.

Publish!

Don't forget to publish this to npm, sir.

driving-with-gopher

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.