This content originally appeared on DEV Community and was authored by shrmpy
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
and
Requirements:
- Twitch extension client ID
§ Overview
§ Headers
preprocess flow
enableCors flow
- The wildcard (
*) in theAccess-Control-Allow-Originheader 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
DELETEfrom theAccess-Control-Allow-Methodsheader.
§ Test
Start the refactor by adding the new test:
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:
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
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():
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.
This content originally appeared on DEV Community and was authored by shrmpy
shrmpy | Sciencx (2021-11-20T05:33:36+00:00) CORS for a Twitch Extension. Retrieved from https://www.scien.cx/2021/11/20/cors-for-a-twitch-extension/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.