* add /twitch/status/:user badge
* update comments
* use a proper schema for the Twitch API calls
* use a token to make Twitch api calls
* fix handling of rate-limit error and bad token error
* [twitch] get a token as soon as creating a Twitch service
* [twitch] start both requests to users and stream before awaiting
* [twitch] set a timeout to replace the token before it expires
* [twitch] use authHelper
* [twitch] skip tests when no credentials
* [twitch] add one more status test
* twitch: do not check whether a user exists
* Refactor existing metrics support into MetricHelper
This completes the refactor done at https://github.com/badges/shields/pull/3662#issuecomment-509011229 in anticipation of adding more metrics support, such as response size of an upstream service, or response time.
* Clean up
* Renames
* Add response time metrics
This adds around 30 new metrics to cover response times at a fairly granular level. We may be able to shrink the number of buckets with time, though I think using 30 metrics is probably okay given that I think may become our most important metric.
* Fix
* add base class for Graphql APIs
* add GithubAuthV4Service + updates to GH token pool
* update github forks to use GithubAuthV4Service
* rename GithubAuthService to GithubAuthV3Service
Use of this feature [has been discouraged for a long time](https://nodejs.org/api/domain.html).
Since most of our code is now bubbling through async, we aren't really getting these "vendor errors" anymore.
Errors that _do_ bubble up through the services have been reported to Sentry since #3706, though they seem to be missing a bunch of their stack traces. Sentry also seems to be combining unrelated internal errors. (https://github.com/badges/shields/issues/3709#issuecomment-514299441) Maybe this will help.
Adding TypeScript to the frontend and a `.d.ts` file to `core` (see #3742) has multiplied out the different combinations of lint rules. ESLint has support for file-pattern-based overrides, which we've used in some places, but we've also maintained a separate eslintrc for `frontend/`.
This merges the config together, with the strategy of putting all the rules at the top level except where they conflict, and applying settings to exactly the files where they should apply.
This introduces a few new errors in the server but they are true positives – hoisting and lowercase class names – things we don't really need to be doing).
This is a reworking of #3410 based on some feedback @calebcartwright left on that PR.
The goals of injecting the secrets are threefold:
1. Simplify testing
2. Be consistent with all of the other config (which is injected)
3. Encapsulate the sensitive auth-related code in one place so it can be studied and tested thoroughly
- Rather than add more code to BaseService to handle authorization logic, it delegates that to an AuthHelper class.
- When the server starts, it fetches the credentials from `config` and injects them into `BaseService.register()` which passes them to `invoke()`.
- In `invoke()` the service's auth configuration is checked (`static get auth()`, much like `static get route()`).
- If the auth config is present, an AuthHelper instance is created and attached to the new instance.
- Then within the service, the password, basic auth config, or bearer authentication can be accessed via e.g. `this.authHelper.basicAuth` and passed to `this._requestJson()` and friends.
- Everything is being done very explicitly, so it should be very clear where and how the configured secrets are being used.
- Testing different configurations of services can now be done by injecting the config into `invoke()` in `.spec` files instead of mocking global state in the service tests as was done before. See the new Jira spec files for a good example of this.
Ref #3393
Fixes https://github.com/badges/shields/issues/3260
Problem happens when a value of a color in an old PNG static badge is a number: http://localhost:8080/my-label/my-message.png?color=1. In this case `color` in `queryParams` is a number.
0a0b5b3f03/core/server/server.js (L203-L212)
Surprisingly service test listed below is passing currently on master - value `1` is represented in `queryParams` as a String (only in test).
`services/static-badge/static-badge.tester.js`
```js
t.create('Old static badge with a number as a color')
.get('/foo/bar.png?color=1', { followRedirect: false })
.expectStatus(301)
.expectHeader('Location', '/badge/foo-bar-1.png')
```
Moreover I added some code + description allowing to debug server.
I find having these in a consistent order makes the services much faster to read.
This is the order I’ve generally been using:
1. Category
2. Route
3. Examples
4. Rendering
5. Other helpers (`fetch()`, `transform()`)
6. `handle()`
