JWTMux was a disingenuous name because while JWTs are a very good choice
for a cookie encoding, they were not strictly required for use with this
mux. To better indicate the responsibilities of this mux, it's been
renamed "CookieMux," since its responsibilities end with persisting the
oauth2.Authenticator's encoded state in the browser. It is up to the
oauth2.Authenticator to choose the encoding.
If a --token-secret, --heroku-client-id, and --heroku-secret are
provided to Chronograf, it will add Heroku as an OAuth2 provider. These
tokens can be obtained (as of this writing) by visiting your "manage
account" page, navigating to "Applications," and then clicking "Register
New API Client" under the "API Clients" section.
Created an oauth2 package which encapsulates all oauth2 providers,
utility functions, types, and interfaces. Previously some methods of the
Github provider were used as http.HandlerFuncs. These have now been
pulled into a concrete type called a JWTMux to implement other Oauth2
providers.
JWTMux has all of the functionality required to take a token from any
provider and store it as a JWT in a browser, and that is the extent of
its responsibilities. It implements the oauth2.Mux interface which would
potentially allow other strategies of oauth2 credential storage.
Since this is a flag that is being accepted by the application, it makes
sense to group it with the other flags. Also, the `json` struct tag was
a remnant from an earlier attempt at implementing this feature, and is
no longer necessary.
URLPrefixer had nothing to do with assets, so it actually belongs up in
the mux, where we're assembling handlers together across the
application.
Also, the setup was painful to look at, and others will probably use the
same `Attrs`, so a `NewDefaultURLPrefixer` was added to spawn a prefixer
with only a prefix and a next handler.
React-router and also the client that we use in the frontend need to be
informed on how to access the Chronograf backend when it's being hosted
on a route other than /. To accomplish this, a data attribute is written
into the `<div>` which serves as our React root. We then make the React
router aware of this if it's set and also pass the prefix to axios (our
front end HTTP client) by way of window.
Originally, it was desired to have the basepath accessible via an API,
but this proved to be impossible because to access that API, the front
end would already need to know the basepath. The technique we went with
was arrived at independently, but is also used by Jupityr notebooks
which encountered the same problem.
The prefixer needs to not only replace `src="` attributes as it
currently does because that is not the only place a relative URL can
appear. It needs to also prefix URLs found in CSS which can also come
from the downstream http.ResponseWriter.
This adds support for an arbitrary list of patterns that will cause the
prefixer to insert its configured prefix. This is currently set to look
for `src`, `href`, and `url()` attributes.
Also, because we are modifying the stream, we need to suppress the
Content-Length generated by any downstream http.Handlers and instead
enable Transfer-Encoding: chunked so that we can stream the modified
response (we don't know apriori how many times we'll perform a
prefixing, so we can't calculate a final Content-Length). This is
accomplished by duplicating the Headers in the wrapResponseWriter that
is handed to the `Next` handler. We also handle the chunking and
Flushing that needs to happen as a result of using chunked transfer
encoding.
In order to support hosting chronograf under an arbitrary path[1], we
need to be able to rewrite all the URLs that are served in HTML and CSS.
Take, for example, the scenario where Chronograf is to be hosted under
`/chronograf` using Caddy and this example Caddyfile:
```
localhost:2020
gzip
proxy /chronograf localhost:8888 {
without /chronograf
}
```
Chronograf will not load properly when visiting
`http://localhost:2020/chronograf` because the requests for CSS, and
fonts will go to `http://localhost:2020/app-somegianthash.js` when they
should go to `http://localhost:2020/chronograf/app-somegianthash.js`.
This is the essence of issue #721.
To solve this, we add a URLPrefixer http.Handler, that acts as a
middleware. It inserts itself between any upstream handlers, and the
handler that was passed to it as its `Next` parameter and searches for
`src="` attributes. Upon discovering one of these attributes, it writes
the detected attribute and then the configured prefix. It then continues
writing the stream to the upstream http.ResponseWriter until
encountering another attribute until EOF.
Using my existing layout chaining, I added layouts wrapped in
go-bindata as the last option for loading layouts. This means
that the data store is preferred over file system over bindata.
With this functionality, we can simply distribute the single-file
binary.
Due to developer confusion over nomenclature, the ID was used in lieu of
the Application property of `Layout`. `layout.Application` holds the
user-facing name for a particular layout, and is what should be paired
with a measurement name in the `/mappings` endpoint.
Before
------
```
% curl http://localhost:8888/chronograf/v1/mappings
{
"mappings" : [
{
"name" : "18aed9a7-dc83-406e-a4dc-40d53049541a",
"measurement" : "disk"
}
]
}
```
After
-----
```
% curl http://localhost:8888/chronograf/v1/mappings
{
"mappings" : [
{
"measurement" : "disk",
"name" : "User Facing Application Name"
}
]
}
```
Connect #326
This populates the /mappings with data found in the LayoutStore. It uses
the ID for the layout as the mappings Name and pulls the Measurement
from there as well.
Tim Raymond
Chris Goller
Hunter Trujillo
Jade McGough
Jade McGough
gunnaraasen
Mark Rushakoff
Jack Zampolin
Will Piers
Ross McDonald
nathan haugo