DEV Community: shrmpy

CORS for a Twitch Extension

shrmpy — Sat, 20 Nov 2021 05:33:36 +0000

This article is the fourth in a multi-part series to walk through the creation of a Twitch extension. For the fourth part, the goal is to refactor the CORS headers.

To go directly to the project, the source code repository is available at

shrmpy / pavlok-panel

Requirements:

Twitch extension client ID

§ Overview

§ Headers

`preprocess` flow

`enableCors` flow

The wildcard (*) in the Access-Control-Allow-Origin header is the primary change in this refactor work. It is time to restrict the origin to the hosting server (ID.ext-twitch.tv) of the Twitch extension.
Another change that should not add extra scope, is to remove DELETE from the Access-Control-Allow-Methods header.

§ Test

Start the refactor by adding the new test:

func TestAccessControlAllowOrigin(t *testing.T) {
        // prepare data
        conf := ebs.NewConfig()
        conf.ExtensionId("HOSTNAME-TEST")
        expectMethods := "POST, GET, OPTIONS, PUT"
        expectHeaders := "Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization"
        expectOrigin := "https://HOSTNAME-TEST.ext-twitch.tv"
        req := newTestRequest("GET")

        // run handler logic
        result, err := ebs.MiddlewareCORS(conf, handler)(req)
        assert.IsType(t, nil, err)
        assert.Equal(t, http.StatusOK, result.StatusCode)

        // check for expected CORS
        assert.Equal(t, expectMethods, result.Headers["Access-Control-Allow-Methods"])
        assert.Equal(t, expectHeaders, result.Headers["Access-Control-Allow-Headers"])
        assert.Equal(t, expectOrigin, result.Headers["Access-Control-Allow-Origin"])
}

Calling the test runner will lead to compile errors:

go test $PWD/cmd/auth

§ Refactor

Add the new package files to define the configuration and middleware:

package ebs

import (
    "fmt"
    "os"
)

// configuration
// to make environment variables available to testing
const EXTENSION_ID = "EXTENSION_ID"

type Config struct {
    extensionId string
}

func NewConfig() *Config {
    return &Config{}
}

func (c *Config) ExtensionId(id string) {
    c.extensionId = id
}

func (c *Config) Hostname() string {
    // format the hostname for the CORS allow-origin
    // 1. For Netlify, EXTENSION_ID environment variable should be defined
    // 2. Locally for testing, rely on configuration field
    if c.extensionId != "" {
        return fmt.Sprintf("https://%s.ext-twitch.tv", c.extensionId)
    }

    cid := os.Getenv(EXTENSION_ID)
    if cid != "" {
        c.extensionId = cid
        return fmt.Sprintf("https://%s.ext-twitch.tv", c.extensionId)
    }

    return ""
}

package ebs

import (
    "net/http"

    "github.com/aws/aws-lambda-go/events"
)

type HandlerFunc func(events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error)

/*
func MiddlewareTemplate(next HandlerFunc) HandlerFunc {
    return func(ev events.APIGatewayProxyRequest)
            (events.APIGatewayProxyResponse, error) {
        return next(ev)
    }
}
*/

func MiddlewareCORS(conf *Config, next HandlerFunc) HandlerFunc {
    return func(ev events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
        // preflight check is short-circuited
        if ev.HTTPMethod == "OPTIONS" {
            return blankResponse(conf, "", http.StatusOK), nil
        }
        // without next, just act same as preflight
        if next == nil {
            return blankResponse(conf, "", http.StatusOK), nil
        }

        // run next handler along chain
        resp, err := next(ev)
        if err != nil {
            return resp, err
        }

        // post-process
        resp.Headers = enableCors(conf, resp.Headers)

        return resp, nil
    }
}

func enableCors(conf *Config, headers map[string]string) map[string]string {
    m := map[string]string{
        "Access-Control-Allow-Origin":  conf.Hostname(),
        "Access-Control-Allow-Methods": "POST, GET, OPTIONS, PUT",
        "Access-Control-Allow-Headers": "Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization",
    }
    // TODO merge, if CORS headers exist
    for key, val := range headers {
        m[key] = val
    }
    return m
}

func blankResponse(conf *Config, descr string, status int) events.APIGatewayProxyResponse {

    h := enableCors(conf, make(map[string]string))
    h["Content-Type"] = "application/json"

    return events.APIGatewayProxyResponse{

        Headers:    h,
        StatusCode: status,
    }
}

There will be references to enableCors in preprocess.go and main.go files that need to be cleaned-up.

The changes also break one of the existing tests. So fix the old test for the preflight request

func TestPreflight(t *testing.T) {
        // prep test data
        conf := ebs.NewConfig()
        expectMethods := "POST, GET, OPTIONS, PUT"
        expectHeaders := "Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization"
        expectOrigin := ""
        req := newTestRequest("OPTIONS")

        // run the handler logic
        result, err := ebs.MiddlewareCORS(conf, handler)(req)
        assert.IsType(t, nil, err)
        assert.Equal(t, http.StatusOK, result.StatusCode)
        // check for expected CORS
        assert.Equal(t, expectMethods, result.Headers["Access-Control-Allow-Methods"])
        assert.Equal(t, expectHeaders, result.Headers["Access-Control-Allow-Headers"])
        assert.Equal(t, expectOrigin, result.Headers["Access-Control-Allow-Origin"])
}

Afterwards, the compile should be successful. Plus calling the test runner this time should have zero fails. All done? not yet. Even though the tests pass, the middleware has not been applied to the original handler. Go to the main.go file and adjust the init() and lambda.Start():

var conf *ebs.Config

func init() {
        conf = ebs.NewConfig()
        secret := os.Getenv("EXTENSION_SECRET")
        helper = newService(decodeSecret(secret))
}

func main() {
        lambda.Start(
                ebs.MiddlewareCORS(conf,
                        handler,
                ),
        )
}

Finally, the new configuration also expects a new environment variable EXTENSION_ID. Go to the Netlify Site settings | Build & deploy | Environment page. Click the Add variable button. Name it EXTENSION_ID and paste the Twitch extension client ID.

Remember coding standards before saving the changes:

go fmt $PWD
go fmt $PWD/cmd/auth
git add config.go middleware.go $PWD/cmd/auth
git commit -m'refactor CORS allow-origin'
git push origin gh-issue-NNN

* Notes, Lessons, Monologue

Why change the Access-Control-Allow-Origin? We used the wildcard (*) in the early iterations, in order to make the requests work. At the time, there were CORS errors to overcome and without knowing the correct values required, we chose to allow all. Now it's time to restrict access for security. So we learned that the Twitch extension is hosted from the ID.ext-twitch.tv server and this would be the correct value for the Allow-Origin header.

Why the middleware? It was in our backlog. So it was a matter of when. For this refactor, the idea was to intercept the response to shape the headers (that affect CORS). To intercept the response, do processing, and then continue the response flow, fits the description of middleware. The other benefit of middleware is consolidation and uncluttering the business logic. Before, we checked for preflight in preprocess, repeated basic responses, and made a direct call to enableCors from the main handler. Now CORS header logic is in one place, ebs.MiddlewareCORS.

Why did the test pass before the init and lambda.Start was patched? is the test pointless? The test only covers the middleware for the inputs supplied. The test doesn't execute the main() or init() functions. It may seem pointless, which is important to pause and reflect. Writing the test forced the design for a way to control the value of EXTENSION_ID. Before now, an environment variable was the first choice. So thinking test first, we knew we needed another approach because assigning the environment variable in test scaffolding is not self-contained; the test would need to push any existing environment onto some stack before test run, then pop the environment after tests finish. The environment requires this kind of management because we don't want the test to clobber the variable of the host's environment. Even this precaution isn't self-contained because what if you run tests in parallel? Each test will step on each others' environment variable assignment. A very wordy way to say that's why we created the configuration in this refactor. It might appear as if the configuration struct is an one-off just for the test, but the real value is that it forced us to undertake the decoupling.

Why not use dot env files? Honestly, I didn't think of it. At the time, I considered TOML/YAML for the configuration, and decided it was overkill. Remember that we want to do the minimum to make a test green. The config.go that we defined is lean in the current incarnation. Down the road, it may be the case that dot env files will be the solution that scales.

What does the call ebs.MiddlewareCORS(conf, handler)(req) do? why is the lambda.Start different? In the test, this line invokes the function wrapped by the middleware. The invoke uses the req variable as the parameter to that function. With the lambda.Start, the function pointer is being supplied. That reference can be resolved at a later time.

Why pass the configuration as a parameter to the middleware call? This is the "trick". We needed a way to specify a setting in the handler. Before writing the test, this wasn't an issue since using an environment variable has global scope; the handler would have access to the variable. Inside the test, we need to specify the setting and supply it to the handler without using globals. So the configuration becomes the parameter.

Authorization of a Twitch Extension

shrmpy — Thu, 04 Nov 2021 05:43:27 +0000

This article is the third in a multi-part series to walk through the creation of a Twitch extension. For the third part, the goal is to refactor the authorization.

To go directly to the project, the source code repository is available at

shrmpy / pavlok

twitch extension project

and

shrmpy / pavlok-panel

Requirements:

CORS
OAuth2
encryption

§ Overview

§ Routes

`/auth` flow

There was claims-extraction processing in earlier incarnations as part of the state field construction. In examining the flow, the diagram helps show there is no longer a claims-extraction step. It's been isolated from preprocess which means now the logic that enforces the extension secret is missing. We have to decide how to re-enable the verification of the extension secret. This will be the focus of our first refactor effort.
Also confirmed after diagramming, the Fauna data abstraction layer is not used. After double-checking via grep, it's safe to remove the fauna.go file.

`/callback` flow

§ Test

Start the refactor by adding another test to the main_test.go file:

func TestWrongExtensionSecret(t *testing.T) {
        // prepare data
        wrongHeader := make(map[string]string)
        wrongHeader["Authorization"] = "Bearer WRONG-KEY"
        req := events.APIGatewayProxyRequest{
                HTTPMethod: "GET",
                Body:       "",
                Headers:    wrongHeader,
        }

        // run request handlerlogic
        result, err := handler(req)
        assert.IsType(t, nil, err)
        assert.Equal(t, http.StatusOK, result.StatusCode)

        // case specific expectation
        missing := newResponse("Wrong authorization header", http.StatusUnauthorized)
        expected := ignoreTimestamp(missing.Body)
        actual := ignoreTimestamp(result.Body)
        // inspect content
        assert.Equal(t, expected, actual)
}

Calling the Go test runner:

go test $PWD/cmd/auth

should give a FAIL with output resembling:

--- FAIL: TestWrongExtensionSecret (0.00s)
    main_test.go:89:
                Error Trace:    main_test.go:89
                Error:          Not equal:
                                expected: "{\"errors\":[{\"code\":\"DEMO-401\",\"detail\":\
"Wrong authorization header\",,\"status\":\"401\"}]}"
                                actual  : "{\"Location\":\"https://app.pavlok.com/oauth/aut
horize?client_id=\\u0026redirect_uri=\\u0026response_type=code\\u0026state=2e54fb84beedc5b2
53be28d3dac67edf6bae84141b1b2ba56f3668a0e646100e1c156721e0\"}"

                                Diff:
                                --- Expected
                                +++ Actual
                                @@ -1 +1 @@
                                -{"errors":[{"code":"DEMO-401","detail":"Wrong authorizat
ion header",,"status":"401"}]}
                                +{"Location":"https://app.pavlok.com/oauth/authorize?client
_id=\u0026redirect_uri=\u0026response_type=code\u0026state=2e54fb84beedc5b253be28d3dac67edf
6bae84141b1b2ba56f3668a0e646100e1c156721e0"}
                Test:           TestWrongExtensionSecret
FAIL
FAIL    github.com/shrmpy/pavlok/cmd/auth       0.015s
FAIL

The output tells us that the expected result was a JSON struct containing the 401 status code. Except the actual result was JSON containing the Pavlok OAuth hyperlink; the handler ran normally. In the test, we purposely wire-up incorrect values for the Authorization header to force the error scenario. So this indicates that the current logic ignores the header contents.

§ Refactor

To trigger the verification of the extension secret, we add the claims-extraction call to the bottom of the preprocess function:

        // extension secret is enforced by claims extraction
        cl, err := helper.claims(token)
        if err != nil {
                log.Print("Malformed claims meta data")
                return newResponse("Wrong authorization header", http.StatusUnauthorized),
errors.New("claims")
        }

        log.Printf("Claims (ch/role): %s / %s", cl.ChannelID, cl.Role)

        return events.APIGatewayProxyResponse{}, nil
}

Run the test again:

go test $PWD/cmd/auth

which should be clean and free of FAIL test output.

Then make sure we follow the Go coding standards:

go fmt $PWD/cmd/auth

Now we can commit the change:

git add $PWD/cmd/auth
git commit -m'add claims extraction in preprocess'
git push origin gh-issue-num

Then navigate to the git repo, and create the merge request. This should launch the deploy preview on Netlify.

Once the preview logs look normal, it's safe to complete the merge request back at the git repo, and remove the patch branch. Netlify should launch a new build for production based on the main branch.

After the build is done, visit the Twitch extensions console to check that the panel is still okay.

The shock button will create entries in the Netlify function logs
The API response will be added in Discord via the webhook

This was enough to get the test to work, and the desired behavior. Refactoring can easily snowball. So we try to chip away, and be careful to minimize taking two steps backwards.

* Notes, Lessons, Monologue

Why is a refactor needed? The code is developed in iterations. In the early rounds, it's a race to get behavior to work. To achieve this, it is normal to follow the "happy path" and postpone negative cases for later. Due to the API requirements, significant work was already interleaved into the iterations to be able to exercise the API calls. So the refactor should be more manageable and not as daunting.

WTF, you made a tutorial that deployed unfinished code?! True. The series is my journey into Twitch extension development. Whenever there is a trade-off, I try to "do no harm". So now, it's valuable to analyze the authorization in public view. To get more eyes, and reveal any gaps.

Why write tests? In refactoring code, it is best to put tests in place before any changes. The tests should document expected behavior. Then in the process of changes, run the tests frequently to catch breaking code as early as possible.

Why are there no mocks? Unfortunately, it's laziness. More refactoring is necessary to make the package testable. Probably lump it with the middleware tech debt.

Why no tests for positive cases? For now, relying on old fashioned manual interaction to verify. More refactoring is required before automation is friction-less (e.g., configure environment variables, mocks).

Why verify the header, things seem to work fine? The Authorization header tells the EBS that a request originates from a trusted application. If we allow all requests, the EBS will be flooded and resource limits for the free tier will be exhausted.

Activate a Twitch Extension Panel

shrmpy — Tue, 19 Oct 2021 07:19:01 +0000

This article is the second in a multi-part series to walk through the creation of a Twitch extension. For the second part, the goal is to install the front-end panel.

To go directly to the project, the source code repository is available at github.com/shrmpy/pavlok-panel

Requirements:

2FA
Deploy EBS

§ Steps

There will be steps from part 1 of the series that overlap. So some steps may already be done. That said, the intention is for part 2 to be as self-contained as reasonable.

Enable two-factor. Follow the instructions from Twitch support docs. 2FA is a requirement for creating extensions.
Follow the tutorial to register a new extension. Specifically (repeated here):
Creating the Extension in the Console

1) Go to the Extensions Developer Console. From this console, you can start the process of creating a new Extension, view and clone your Extensions, and manage specific versions of your Extension(s). Login with your Twitch ID. You should see a page like this:

2) Click the Create an Extension button on the right side of the page.

3) Fill in the Name Your Extension section with any name you want, and then click Continue.

4) On this versions page, be sure to fill out respective fields
- Type of Extension — (Required) Select Panel.
- Version Number — (Required) Leave this as 0.0.1.
- Summary — (Optional) This will be viewable by broadcasters and viewers. It should be 1-2 brief sentences describing what your Extension does. To provide more detail, use the Description.
- Description — (Optional) More detail than the Summary about the functions of your Extension.
- Author Name — (Optional) The full name of the Extension author or organization that will receive credit on the Extensions manager.
- Author Email — (Optional) Contact information for the Extension creator. This is used to contact the developer with information about the Extension’s life cycle (e.g., reject/accept notifications). Twitch will never reveal this email to anyone on the site. If you provide this information, you’ll get a verification email soon after creating the Extension version. Be sure to check your email, as you need to verify ownership of the author email address.
- Support Email — (Optional) Public contact information for support-related queries from broadcasters.
5) Click Create Extension Version. You will then see the Status page of the Extension Manager. This page essentially shows the current status (Local Test) of the Extension in the Extension Life Cycle, and also provides you with next steps to move the Extension through the life cycle. You should see the following page:
Set the filenames of the broadcaster config, live config, and viewer panel.
- Click the Asset Hosting tab.
- The Panel Viewer Path should already be pre-filled with the name panel.html. If not, then input the name panel.html.
- The Config Path should already be pre-filled with the name config.html. If not, then input the name config.html.
- The Live Config Path should be empty. Input the name live_config.html.
- Click the Save Changes button to save the filename settings.
Choose Configuration Service from the Capabilities tab. Taken from the tutorial (repeated here):

Before testing the Extension, go to the Console Manager and enable the Configuration Service. Go to the Capabilities tab of the Extension Manager, and scroll down to the second frame, where you should see a section titled “Select how you will configure your Extension.” Select Extension Configuration Service, and then save the changes.
Find the new extension secret as explained in Step 2: JWT Secret. Specifically (repeated here):

Concept: Each Extension maintains a shared secret that is used to sign tokens that validate the identity of users. Extension Secret is base64 encoded and is provided to you by the Extension Manager.

To retrieve the secret, lets go to the Extension Manager. To get to the Manager, go to the console, select a version of the Extension and click Manage. Once on this page, you will see the default status page. On the top right of the manager, click the Extension Settings button. You will see the following page:

Under the Extension Client Configuration section, copy the key provided. We need to use this key to verify that the token provided is signed with the same secret.
Obtain the ZIP archive of the front-end files. Navigate to the source code repository.

Click on the Releases link on the right hand column to reach the release files. Download the archive named panel.zip:
Upload ZIP archive. With the panel.zip downloaded from the source code repository, return to the console where the Files tab can be found (same as Go to Files link in Status tab).

Package your Extension
When you send Twitch an Extension, you need to bundle the Extension files into a zip file. Make sure you are bundling the files, not the folder containing your Extension files.

To upload your zip file to Twitch, choose Files > Upload Version in Assets > Choose File. Then click the purple Upload button at the bottom.

Now we’re ready to move to Hosted Test. Click Next Step in the top right, click Move To Hosted Test, and confirm your choice.
Switch to Hosted Test. Navigate to the Status tab. The heading will show Current Status: Local Test. Now the Move to Hosted Test button will be available. Click the button to change to Hosted Test.
Quick Deploy the EBS. The URL that Netlify creates for the deployment will be our EBS base URL. If you completed part 1 previously, then step #9 is already done.
Activate. Follow tutorial:

We are ready to see the Extension live on Twitch! To do so, go to the Status page of the Extension Manager, and scroll down to the section titled “Next Steps.” Click the View on Twitch and Install button.

Clicking this button will open a new tab with the Extension Details page.

Installation: Next, click the purple Install button. When the Extension is installed, you will see a confirmation pop-up informing you that Extension installation is complete, and that if you want to activate the Extension right now, you need to configure it.

Configuration: Click Configure. Upon doing so, you will be directed to the Broadcaster Configuration Page. Here we see the page we created where the Broadcaster can select the options they want viewers to be able to choose from.

The URL shown here (https://randomized-phrase.netlify.app) is an example, but the format of EBS base URL will be similar from the result of step #9.

Clicking the button connect pavlok (opens in new tab) will be the first test that the configuration fields are matched correctly. If everything works, the Pavlok OAuth Login prompt will display. Unless pop-up windows are blocked, in which case the browser configuration needs to allow dashboard.twitch.tv for this step.

If the Pavlok Login is successful, the pop-up will be closed and return you to the extension config view. Close the config view, and the extension will have the Activate dropdown available:

Choose Set as Panel 1 if that is available. Now the extension is activated.

§ Test

Go to the Stream Manager page on Twitch, and under the Quick Actions list click on the new extension. It should launch the Live Config view in a new window.
Click on the shock button and if everything is connected, the Pavlok API call will be invoked. If the Discord webhook is configured, the API result code will be logged in the respective channel, too.

* Notes, Lessons, Monologue

Legacy panel view flow; need to revise for iterations so far.

Legacy broadcaster config; need to revise.

Netlify Quick Deploy for a Twitch Extension EBS

shrmpy — Mon, 11 Oct 2021 05:59:38 +0000

This article is the first in a multi-part series to walk through the creation of a Twitch extension. For the first part, the goal is to host an EBS on Netlify.

To go directly to the project, the source code repository is available at github.com/shrmpy/pavlok

Requirements:

Netlify account
Fauna DB account
Twitch extension registration
Pavlok app registration
Discord webhook (optional)

§ Steps

Technically, there is a step zero because you'll need a GitHub/GitLab account. So if you don't have one already, sign-up first AND you'll be able to use that account as your OAuth login to do step #1.

Sign-up for a free account at Netlify.
Sign-up for a free account at Fauna DB with Netlify account credentials using OAuth:

After your new account is opened, make the database keys as described in the example. Specifically (repeated here for convenience):
a. Create a database

In the Fauna Cloud Console:
- Click “New Database”
- Enter “Netlify” as the “Database Name”
- Click “Save”
b. Create a database access key

In the Fauna Cloud Console:
- Click “Security” in the left navigation
- Click “New Key”
- Make sure that the “Database” field is set to “Netlify”
- Make sure that the “Role” field is set to “Admin”
- Enter “Netlify” as the “Key Name”
- Click “Save”
c. Copy the database access key’s secret

Save the secret somewhere safe; you won’t get a second chance to see it.
Register your Twitch extension according to the dev guide. Specifically (repeated here for convenience):
Configure the Extension
Configuring an Extension requires a few steps:
- Visit https://dev.twitch.tv/console/extensions, and click Create Extension.
- Type a unique name for your new Extension.
- Pick a type for your Extension. For this example, we’ll use a Panel Extension.
- Fill in any optional fields you choose.
- After filling in the optional fields, click Create Extension Version. You now have an extension!
Find the new extension secret as explained in Step 2: JWT Secret. Specifically (repeated here):

Concept: Each Extension maintains a shared secret that is used to sign tokens that validate the identity of users. Extension Secret is base64 encoded and is provided to you by the Extension Manager.

To retrieve the secret, lets go to the Extension Manager. To get to the Manager, go to the console, select a version of the Extension and click Manage. Once on this page, you will see the default status page. On the top right of the manager, click the Extension Settings button. You will see the following page:

Under the Extension Client Configuration section, copy the key provided. We need to use this key to verify that the token provided is signed with the same secret.
a) Sign-up for a free account at Pavlok. With the account opened, register your Pavlok app. Similar to the previous steps, it's necessary to keep the client ID and client secret for use later during the deployment. Their docs explain in some detail about the OAuth process. For our purposes, the "redirect URI" entry can start as a placeholder value of http://localhost:8080. the real value will be available after Netlify deploys successfully. Seen here, the field "Callback URL" example has the format https://randomized-phrase.netlify.app/api/pavlok/callback. The randomized-phrase is the hostname Netlify will create when done. So we will need to return to this Pavlok app page and enter the final URL.

b) (OPTIONAL) Create your Discord webhook as outlined in support doc. Specifically (repeated here for convenience):
1) Open your Server Settings and head into the Integrations tab:
2) Click the "Create Webhook" button to create a new webhook!

You'll have a few options here. You can:
- Edit the avatar: By clicking the avatar next to the Name in the top left
- Choose what channel the Webhook posts to: By selecting the desired text channel in the dropdown menu.
- Name your Webhook: Good for distinguishing multiple webhooks for multiple different services.
Run Quick Deploy to host on Netlify

Once you choose either GitHub or GitLab for your repository, the prompt will list the environment variable settings. Match the fields to the corresponding keys from previous steps.

Secret phrase used to encrypt OAuth state field: Can be any random text that you choose. Used internally by the EBS and will never be displayed in UI.
Discord webhook: (OPTIONAL) Discord webhook URL step #4b
Secret from the Twitch Extension Manager: The secret from step #3
Secret from Fauna DB account: The secret from step #2
Github avatar: (OPTIONAL) The profile icon of your GitHub account.
Pavlok app client ID: The client ID from step #4a
Pavlok app secret: The secret from step #4a
Pavlok redirect: Use http://localhost:8080 for now. After deployment is completed, change it inside the Netlify site Build environment variables page. It will then become the Netlify deploy URL concatenated with /api/pavlok/callback

§ Test

curl -H "Accept: application/json" netlify-deploy-url/api/pavlok/auth

Where netlify-deploy-url is the resulting Netlify URL from step #5. The test only validates the service responds because the Authorization header is missing. So to actually show more, we can try the frontend of the Twitch extension, next.

§ End-to-end

At this point, the EBS is live, but we don't have the UI. The front-end will demonstrate the full trip end-to-end. To continue work on the front-end, try part 2 in the series.

* Notes, Lessons, Monologue

Why a separate EBS? To help visualize where the EBS sits, the sequence diagram shows one flow. If we chop off the left side that contains Panel / Twitch, it leaves the subsystem that is not coupled to the Twitch iframe and related restrictions. This makes some testing easier especially in early experiments. This was also because I was not using the Twitch Developer Rig. Since Twitch introduces extensions as simply web pages with the helper imported, I wanted to pursue that and postpone learning "Twitch" until later.

Why three (auth/callback/shock) routes? To troubleshoot and learn and test. Concepts were more obvious when I could say, "first auth goes to /auth, then callback goes to /callback, etc". It became more obvious when understanding the state field, and asking how to verify continuity (when Pavlok sends the browser to the callback). Refactoring will clean up duplicated code.

Why doesn't the Panel link directly to Pavlok's Login page? This is primarily a convenience so that the Panel doesn't keep any of the Pavlok fields required to construct the hyperlink. The EBS does the heavy lifting to format the URL and returns it to the Panel for it to launch a pop-up window. The side effect is that the Panel can stay thin (and remains truer to a presentation layer module).

Why is a thin Panel good? This is another happy accident from the Twitch JWT token which contains claims meta data. It made it possible to avoid adding data to the request. The Authorization header is required for the EBS to make sure requests are from trusted users. Then the token from the header is leveraged for the channel ID. Maybe this overloads the token, but for now it keeps the Panel minimal and less complicated (until we learn more about Twitch).

Why Netlify? Serverless (our last workstation suffered battery failure). Golang support. Build times are quick with helpful log output for troubleshooting. Abstracts AWS Lambda (protects us from some of the complexities).

Why Fauna DB? when the Twitch Configuration Service is already available as a key/value store. Good support between Netlify and Fauna makes other alternatives lower preference, but the primary benefit is testing without Twitch dependency. We still use the Twitch Configuration Service to store the EBS base URL; even though this makes the extension installation a little unfriendly, it helps us avoid having to hard-code the URL into the frontend.

Why Pavlok? The Pavlok API is the functional piece of this Twitch extension, but it can be seen as a real world example of an integration. A different third party API with OAuth2 should have very similar interfaces.

Why Discord? The Discord webhook is optional, but it is very helpful to observe the API result. Since testing without a Pavlok device, means the API calls cannot deliver the electric shocks. So using a Discord webhook serves the dual purpose of logging the API call, as well as verifying that connections are established to external systems.

DEV Community: shrmpy

CORS for a Twitch Extension

shrmpy / pavlok

twitch extension project

shrmpy / pavlok-panel

§ Overview

§ Headers

preprocess flow

enableCors flow

§ Test

§ Refactor

* Notes, Lessons, Monologue

Authorization of a Twitch Extension

shrmpy / pavlok

twitch extension project

shrmpy / pavlok-panel

§ Overview

§ Routes

/auth flow

/callback flow

§ Test

§ Refactor

* Notes, Lessons, Monologue

Activate a Twitch Extension Panel

§ Steps

§ Test

* Notes, Lessons, Monologue

Netlify Quick Deploy for a Twitch Extension EBS

§ Steps

§ Test

§ End-to-end

* Notes, Lessons, Monologue

`preprocess` flow

`enableCors` flow

`/auth` flow

`/callback` flow