Rather than enable a behavior we would rather not keep by default, we'll keep it opt-in and link to it so that users who have issues can find the setting
Elasticsearch is deprecating the ability to use ascending sort for terms
aggregations, so we render a deprecation notice whenever a user views a
visualization that uses a terms aggregation with ascending sort by
count. We only render this error message once per route so it does not
spam the users constantly when they have things like auto-refresh
enabled on a dashboard.
Traditionally we've relied on the kbn-version header for csrf
protection, but that is also used for the client-side Kibana version
check that alerts users when their client is out of date and needs to be
refreshed, so it must match the version of Kibana exactly.
This poses a problem for any programmatic access that would only get set
up once but may run repeatedly throughout the future (e.g. watcher), so
there's now the additional option of specifying the kbn-xsrf header
instead. The value of the header does not matter, but its very presence
is all that is necessary to avoid xsrf attacks.
The xsrf protection just needs either one of these headers to exist.
Kibana currently stores it's entire application state in the URL by rison encoding it and sticking it into a query string parameter, _a for AppState and _g for GlobalState.
This has functioned fine for a while, but Internet Explorer's short URL length restriction are starting to become a problem for more and more users. To provide these users with a workaround this adds an advanced config option that will store the state in sessionStorage instead of the URL.
This is accomplished by hashing the serialized version of the state, storing a short version of the hash in the URL, and storing the whole serialized state in sessionStorage using the hash + state-type as a key.
Since sessionStorage is limited in size, we must clean up old stored states after they become unreachable to the application. This is done using the new `LazyLruStore` class, a wrapper around sessionStorage. This wrapper helps us maintain the list of stored states based on the time they are accessed (On each set the access time is updates).
It's cleanup style is configured with it's maxItems, idealClearRatio, and maxIdealClearPercent configurations. The defaults for which should be sufficient.
`maxItems`: limits the store to n items, removing the oldest item when the list overflows
`idealClearRatio+maxIdealClearPercent`: when `store.setItem(key, value)` throws an error we try to clear space equal to `idealClearRatio * (key+value).length`, but no more space than `totalSize * maxIdealClearPercent`
The tests in master are currently failing regularly because our current browser tests are serious memory hogs. Investigation reveals that nearly every test is retaining all of the memory it causes to be allocated. We have made some progress to being able to diagnose the problems, but we expect that problem to take some serious work to fix. We need a short-term solution though, and this is it.
Rather than modify the bundling process, we will shard the top-level test suites by name. For now, we've created 4 shards, but adding new shards is trivial if we need to.
Sharding is accomplished by creating a murmur3 hash of the top level suite names, then bucketing based on the hash output. If a test suite resolves to shard2, but we are running shard1, we simply never pass the function to `mocha.describe()`. Rather than redefine every describe statement, we have shimmed the global `window.describe()` function to accomplish this.
