Kapacitor responses are paginated, and sometimes users have more than
the default 100 tasks that are returned from Kapacitor. This replaces
the previous Kapa client with one that automatically follows paginated
responses from Kapacitor's ListTasks endpoint and returns the full
response.
Tests for the KapacitorRulesGet endpoint had to be updated because they
did not account for "limit" and "offset", and so led to an infinite
loop with the paginated client. A correct kapacitor backend will not
have this behavior
The kapacitor client used in the kapacitor endpoints is limited to
fetching whatever limit you provide it. If you provide no limit, it
defaults to a limit of 100. We use this default behavior currently.
Some users have more than 100 tasks, so we need a client that's capable
of continually fetching tasks from Kapacitor until there are none left,
and returning the full response to the frontend.
This introduces a PaginatingKapacitorClient which does exactly that.
Also, test coverage was added around the KapacitorRulesGet endpoint,
since it was previously untested.
Because we are now creating new instances of dashboards when we create a
response, it's critical to copy every element of Dashboards from the
previous to the new instance.
We were not previously copying the Type field of cells, so this was
defaulting to the empty string zero value. This patch adds "Type" to the
tests and ensures that it's properly copied
In anticipation of adding Axes to cells, I wanted some test coverage to
be in place before I made the change.
This covers the happy path case as well as focusing on individual
applications. To come are focusing on a measurement and a test for when
the store is unavailable.
Also removed LegacyBounds marshaling since it was no longer necessary
Conflicts resolved:
bolt/internal/internal.go
bolt/internal/internal.pb.go
bolt/internal/internal.proto
bolt/internal/internal_test.go
chronograf.go
server/cells_test.go
server/dashboards_test.go
server/swagger.json
When creating new dashboards to set defaults, not all properties of the
dashboard were being copied. This ensures that they are so that zero
values are not used for things like the ID and Name.
Dashboard responses had data races because multiple goroutines were
reading and modifying dashboards before sending them out on the wire.
This patch introduces immutability in the construction of the response,
so that each goroutine is working with its own set of dashboardResponse
structs.
The contract with the frontend states that bounds should come back as an
empty array instead of null when there are no bounds present. We must
explicitly specify []string{} for this to happen.
Certain aspects of the frontend requires the presence of these three
axes, so part of the contract established is that the backend will
always provide them. Since we centralize creation of
dashboardCellResponses, this is where these axes are added to all cell
responses.
Additionally, because there was previously no coverage over the
dashboard cells endpoints, a test has been added to cover the
DashboardCells method of Service.
Due to various limitations with the previous implementation of Bounds as
a [2]int64{}, we've decided to change this to a []string{}. This will
allow clients to store arbitrary data specifying a bound and interpret
it as they wish.
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
Cells now have axes which represent their visualization's viewport. This
updates the Swagger documentation to reflect this.
Things to be aware of
=====================
The form of "axes" is that of a map<string,object>, which is represented
in Swagger by an "additionalProperties" key (search for "string to model
mapping" here: https://swagger.io/specification/).
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
Cells now have axes which represent their visualization's viewport. This
updates the Swagger documentation to reflect this.
Things to be aware of
=====================
The form of "axes" is that of a map<string,object>, which is represented
in Swagger by an "additionalProperties" key (search for "string to model
mapping" here: https://swagger.io/specification/).
It's useful for operators to classify users into separate groups which
we have termed "organizations". For other OAuth providers, the notion of
an organization typically fell along company lines. For example,
MegaCorp might have a "MegaCorp" GitHub organiztion, and all email
addresses would have the domain "megacorp.com".
Auth0 is slightly different in that MegaCorp would likely run their own
Auth0 provider for their internal services, so "organizations" in Auth0
are no longer synonymous with "large organizations" (or companies).
Instead, Auth0 organizations could be used to restrict access to
Chronograf instances based on team membership within an organization.
To make use of Auth0 organizations, operators should modify users'
app_metadata to include the key "organization". Its value should be the
organization which that user belongs to. This can be done automatically
through arbitrary rules using Auth0 Rules.
Auth0 is an OpenID Connect compliant OAuth2 provider, so we're able to
re-use the generic OAuth2 provider to implement it. The routes required
by Auth0 have been hardcoded for user convenience.
Also, Auth0 requires users to register a subdomain of auth0.com when
signing up. This must be provided to chronograf through the
`--auth0-domain` parameter (or `AUTH0_DOMAIN` ENV). This is **distinct**
from the `PUBLIC_URL`. For example, for a Chronograf hosted at
`http://www.example.com`, and an Auth0 domain of
`http://oceanic-airlines.auth0.com`, a client-id of `notpennysboat` and a
client-secret of `4-8-15-16-23-42`, the command line options would look
like:
```
chronograf \
--auth0-domain=http://oceanic-airlines.auth0.com \
--auth0-client-id=notpennysboat \
--auth0-secret=4-8-15-16-23-24
--public-url=http://www.example.com
-t `uuidgen`
```
When using a basepath of /chronograf, the app would present a
never-ending spinner when visiting the root route. This was because the
prefixingRedirector middleware which is responsible for appending the
basepath to redirects from downstream http.Handlers thought that the
prefix was already appended since it saw `/chronograf/v1`. In reality,
it should have produced a location like `/chronograf/chronograf/v1`.
The solution was to look beyond the first instance of a prefix and check
for the presence of another prefix to detect if a prefix was already
applied by a downstream handler.
The Basepath option should be applied in anything that will be consumed
by the React application. This is because from its perspective, the
proxy sitting between it and the backend wants those prefixes regardless
of what it does with them before handing the request back to the
Chronograf backend. Consequently, there's situations in the backend
where we need to have the `opts.Basepath` or the `basepath` that we
alter when `opts.PrefixRoutes` is set. The `basepath` is strictly for
altering routing decisions made by the backend.
There's subtle places where routes are supplied to the frontend that
need to always have the `opts.Basepath` set as well. Another commit
addressed the "Location" header of Redirects, for example.
The router that we use has a feature that will automatically redirect
routes in certain situations where it feels a trailing slash would be
appropriate. Because the underlying router is totally unaware of
upstream prefixing activity, the "Location" that it sends clients to is
incorrect because it doesn't have the prefix.
This introduces a middleware that catches any downstream 3XX class
responses and replaces the Location header with the prefixed version of
it, plus a trailing slash. It does this only when the prefix has not
been applied already by some downstream middleware.
This adds the status code to the response log message to make it easier
to diagnose issues. It also replaces the placeholder "Success" message
with the decoded value of the HTTP Status, resulting in messages like:
INFO[0041] Response: Temporary Redirect code=307
...and so on. Both easily consumable by humans and machines.
Basepath was previously not working here because the strings constructed
via concatenation had a trailing slash at the end:
Before:
rootPath => "/someprefix/chronograf/v1/"
After:
rootPath => "/someprefix/chronograf/v1"
The julienschmidt/httprouter that the bouk/httprouter is based on has
support for ignoring trailing slashes, which is behavior that we want.
However, routing decisions involving this rootPath string were being
made by a `strings.HasPrefix` function. This conditional seeks to
apply the token middleware only in cases where routes _under_
`/chronograf/v1` are accessed (e.g. `/chronograf/v1/sources`). In cases
where the paths were effectively equal, this conditional accidentally
worked because the string `/chronograf/v1` does not have the prefix
`/chronograf/v1/`. When this was corrected to use `path.Join`, this case
became true and caused the token middleware to be applied.
`path.Join` is the correct way to construct paths, since this prevents
issues where a fragment like `/foo/` is concatenated with a fragment
like `/bar/quux/` to yield the string `/foo//bar/quux/`.
Given that continuing to use concatenation is no longer an option, the
solution is to compare the lengths of the strings to ensure that the
path under comparison is longer than the prefix it's being tested
against. This guarantees that the subject path is a route underneath the
`/chronograf/v1` route.
Updated the logout link in the UI to use a link provided by the
/chronograf/v1/ endpoint. We also replaced many instances of string
concatenation of URL paths with path.Join, which better handles cases
where prefixed and suffixed "/" characters may be present in provided
basepaths. We also refactored how Basepath was being prefixed when using
Auth. Documentation was also updated to warn users that basepaths should
be applied to the OAuth callback link when configuring OAuth with their
provider.
Timothy J. Raymond
Tim Raymond
Jared Scheib
Chris Goller
Jared Scheib
Hunter Trujillo
Kent Wang
Regan Kuchan
Andrew Watkins