Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2025-01-25 00:07:47 +01:00
Code Issues Projects Releases Wiki Activity

Fix typos in documentation

Browse Source
This commit is contained in:
Valentin Jonovs 2019-03-05 09:26:34 +01:00 committed by Ivar Conradi Østhus
parent 868f43a3b2
commit 7c67e6bcc3
12 changed files with 76 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/activation-strategies.md
View File

@ -3,11 +3,11 @@ id: activation_strategy
title: Activation Strategies
---
It is powerful to be able to turn a feature on and off instantaneously, without redeploying the application. The next level of control comes when you are able to enable a feature for specific users or enable it for a small subset of the users. We achieve this level of control with the help of activation strategies. The most simple strategy is the “default” strategy, which basically means that the feature should be enabled to everyone.
It is powerful to be able to turn a feature on and off instantaneously, without redeploying the application. The next level of control comes when you are able to enable a feature for specific users or enable it for a small subset of users. We achieve this level of control with the help of activation strategies. The most straightforward strategy is the “default” strategy, which basically means that the feature should be enabled to everyone.
The definition of an activation strategy lives in the Unleash API and can be created via the Unleash UI. The implementation of activation strategies lives in the various client implementations.
The definition of an activation strategy lives in the Unleash API and can be created via the Unleash UI. The implementation of activation strategies lives in various client implementations.
Unleash comes with a few common activation strategies. Some of them require the client to provide the [unleash-context](./unleash-context.md), which gives necessary context for unleash.
Unleash comes with a few common activation strategies. Some of them require the client to provide the [unleash-context](./unleash-context.md), which gives the necessary context for Unleash.
## default
@ -15,15 +15,15 @@ It is the simplest activation strategy and basically means "active for everyone"
## userWithId
Active for users with a userId defined in the userIds-list. Typically I want to enable a new feature only for myself in production, before I enable it for everyone else. To achieve this we can use the “UserWithIdStrategy”. This strategy allows you to specify a list of user ids that you want to expose the new feature for. (A user id may of course be an email if that is more appropriate in your system.)
Active for users with a `userId` defined in the `userIds` list. Typically I want to enable a new feature only for myself in production before I enable it for everyone else. To achieve this, we can use the “UserWithIdStrategy”. This strategy allows you to specify a list of user IDs that you want to expose the new feature for. (A user id may, of course, be an email if that is more appropriate in your system.)
**Parameters**
- userIds - _List of user ids you want the feature toggle be enabled for_
- userIds - _List of user IDs you want the feature toggle to be enabled for_
## gradualRolloutUserId
Gradually activates feature toggle for logged in users. Stickiness based on the user id. This strategy guarantees that the same user gets the same experience every time, across devices. It also guarantees that a user which is among the first 10% will also be among the first 20% of the users. Thus we ensure that users get the same experience. Even if we gradually increase the number of users who are exposed to a particular feature. To achieve this we hash the user id and normalise the hash value to a number between 1 and 100 with a simple modulo operator.
The `gradualRolloutUserId` strategy gradually activates a feature toggle for logged in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalise the hash value to a number between 1 and 100 with a simple modulo operator.
![hash_and_normalise](assets/hash_and_normalise.png)
@ -36,7 +36,7 @@ Starting from v3.x all clients should use the 32-bit [MurmurHash3](https://en.wi
## gradualRolloutSessionId
Gradually activates feature toggle. Stickiness based on session id. It is almost identical to the `gradualRolloutUserId` strategy, with the exception that it works on session ids. This makes it possible to target all users (not just logged in users), guaranteeing that a user will get the same experience within a session.
Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature toggle, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged in users), guaranteeing that a user will get the same experience within a session.
**Parameters**
@ -45,7 +45,7 @@ Gradually activates feature toggle. Stickiness based on session id. It is almost
## gradualRolloutRandom
Randomly activates the feature toggle. No stickiness. We have found this rollout strategy very useful in some scenarios, especially when we enable a feature which is not visible to the user. It is also the strategy we use to sample metrics and error reports.
The `gradualRolloutRandom` strategy randomly activates a feature toggle and has no stickiness. We have found this rollout strategy very useful in some scenarios, especially when we enable a feature which is not visible to the user. It is also the strategy we use to sample metrics and error reports.
**Parameters**
@ -53,7 +53,7 @@ Randomly activates the feature toggle. No stickiness. We have found this rollout
## remoteAddress
Active for remote addresses defined in the IPs list. We sometimes use this strategy to enable a feature only for IP's in our office network.
The remote address strategy activates a feature toggle for remote addresses defined in the IP list. We occasionally use this strategy to enable a feature only for IPs in our office network.
**Parameters**
@ -61,7 +61,7 @@ Active for remote addresses defined in the IPs list. We sometimes use this strat
## applicationHostname
Active for client instances with a hostName in the hostNames-list.
The application hostname strategy activates a feature toggle for client instances with a hostName in the `hostNames` list.
**Parameters**

24
docs/beta-features.md
View File

@ -5,27 +5,27 @@ title: Beta Features
## Beta Features
In this section we will introduce beta features available in Unleash. These features are considered stable enough to use in production, but they are subject to change in later versions in Unleash. You must therefore take extra care updating Unleash if you depend on these features.
In this section, we will introduce the beta features available in Unleash. These features are considered stable enough to use in production, but they are subject to change in later versions in Unleash. You must, therefore, take extra care updating Unleash if you depend on these features.
### Feature Toggle Variants
> This feature was introduced in _Unleash v3.2.0_. To enable this feature you must create a new feature toggle named `unleash.beta.variants` and make sure to enable it.
> This feature was introduced in _Unleash v3.2.0_. To enable this feature, you must create a new feature toggle named `unleash.beta.variants` and make sure to enable it.
Do you want to facilitate more advanced experimentations? Do you want to use Unleash to handle you A/B experiments? Say hello to feature toggle variants!
Do you want to facilitate more advanced experimentations? Do you want to use Unleash to handle your A/B experiments? Say hello to feature toggle variants!
You can now extend your feature toggles with multiple variants! This feature enable you to extend your toggle to also spread your traffic among a set of variants.
You can now extend feature toggles with multiple variants. This feature enables you to extend a feature toggle to divide your traffic among a set of variants.
![toggle_variants](assets/variants.png 'Feature Toggle Variants')
#### How does it work?
Unleash will first use activation strategies in order to decide whether a feature toggle is considered enabled or disabled for the current user.
Unleash will first use activation strategies to decide whether a feature toggle is considered enabled or disabled for the current user.
If the toggle is considered **enabled**, Unleash client will select the correct variant for the request. Unleash clients will use values from the Unleash context in order to make the allocation predictable. `UserId` is the preferred value, then `sessionId` and `remoteAdr`. If no context data is provided the traffic will be spread randomly for each request.
If the toggle is considered **enabled**, the Unleash client will select the correct variant for the request. Unleash clients will use values from the Unleash context to make the allocation predictable. `UserId` is the preferred value, then `sessionId` and `remoteAdr`. If no context data is provided, the traffic will be spread randomly for each request.
If the toggle is considered **disabled** you will get the built-in `disabled` variant.
> If you change the number of variants it will affect variant allocations. This means that some of the users will be moved to the next variant.
> If you change the number of variants, it will affect variant allocations. This means that some of the users will be moved to the next variant.
_Java SDK example:_
@ -38,15 +38,15 @@ System.out.println(variant.getName());
#### Client SDK Support
To make use of toggle variants you need to use a compatible client. Client SDK with variant support:
To make use of toggle variants, you need to use a compatible client. Client SDK with variant support:
- [unleash-client-node](https://github.com/Unleash/unleash-client-node) (from v3.2.0)
- [unleash-client-java](https://github.com/Unleash/unleash-client-java) (from v3.2.0)
#### Limitations
- Currently you can not set the variant weights yourself. The plan is to make this customizable. In order to have it stable over time the total weights needs to be stable, and we have currently defined the sum to be 100, meaning we have 100 slots to spread the traffic.
- You are only able to provide overrides based on `userId`. This allows you to control which variant a specific user should get. In the future you will be able to define overrides on all context parameters.
- Payload only support `type=string`. This might change in the future. For now you can pass an optional string payload to the client and your application is responsible for parsing it correctly (JSON, csv, etc).
- Currently, you can not set the variant weights yourself. The plan is to make this customizable. To have it stable over time the total weights need to be stable, and we have currently defined the sum to be 100, meaning we have 100 slots to spread the traffic.
- You are only able to provide overrides based on `userId`. This allows you to control which variant a specific user should get. In the future, you will be able to define overrides on all context parameters.
- The payload only supports `type=string`. This might change in the future. For now, you can pass an optional string payload to the client. Your application is responsible for parsing it correctly depending on the format, e.g. JSON, CSV, etc.
If you want to give feedback on this feature, experiences issues or have questions please feel free to open an issue request on [GitHub](https://github.com/Unleash/unleash/).
If you would like to give feedback on this feature, experience issues or have questions, please feel free to open an issue on [GitHub](https://github.com/Unleash/unleash/).

2
docs/client-sdk.md
View File

@ -3,7 +3,7 @@ id: client_sdk
title: Client SDK
---
In order to use Unleash in your application you will need an Unleash Client SDK. Unleash has offical client SDK's for Java, Node.js, Go, Ruby and Python. And we will be happy to add implementations in other langugages written by you! These libraries makes it very easy to use Unleash in you application.
To use Unleash in your application, you will need an Unleash Client SDK. Unleash has official client SDKs for Java, Node.js, Go, Ruby, and Python. We will be happy to add implementations in other languages written by you! These libraries make it very easy to use Unleash in your application.
### Official client SDKs:

20
docs/client-specification.md
View File

@ -5,7 +5,7 @@ title: Client Specification
# Client Specification 1.0
This document attempts to guide developers in implementing a Unleash Client SDK.
This document attempts to guide developers in implementing an Unleash Client SDK.
## System Overview
@ -17,17 +17,17 @@ Unleash is comprised of three parts:
![system_overview](https://raw.githubusercontent.com/Unleash/unleash/master/docs/assets/unleash-diagram.png 'System Overview')
In order to be super fast, the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off because it is just a simple function operating on local state, without the need to poll data from the database.
To be super fast, the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off because it is just a simple function operating on local state, without the need to poll data from the database.
## The Basics
All client implementations should strive to have a simple and consistent user API. It should be a simple method, called isEnabled, to check if a feature toggle is enabled or not. The method should return a `boolean` value, true or false.
All client implementations should strive to have a consistent and straightforward user API. It should be a simple method, called isEnabled, to check if a feature toggle is enabled or not. The method should return a `boolean` value, true or false.
```javascript
unleash.isEnabled('myAwesomeToggle');
```
The basic `isEnabled` method should also accept a default value. This should be used if the client does not know anything about that that toggle name. If the user does not specify a default value, false should be returned for unknown feature toggles.
The basic `isEnabled` method should also accept a default value. This should be used if the client does not know anything about a particular toggle. If the user does not specify a default value, false should be returned for unknown feature toggles.
**Calling unleash with default value:**
@ -66,7 +66,7 @@ A feature toggle is defined as:
}
```
A simple demo of the isEnable function in JavaScript-style (most implementation will probably be more functional):
A simple demo of the `isEnabled` function in JavaScript style (most of the implementation will likely be more functional):
```javascript
function isEnabled(name, unleashContext = {}, defaultValue = false) {
@ -94,7 +94,7 @@ function isEnabled(name, unleashContext = {}, defaultValue = false) {
Activation strategies are defined and configured in the unleash-service. It is up to the client to provide the actual implementation of each activation strategy.
Unleash also ships with a few built-in strategies and it is expected that client SDK's implement these. Read more about these [activation strategies](activation-strategies.md). For the built-in strategies to work as expected the client should also allow the user to define a [unleash-context](unleash-context.md). The context should be possible to pass in as part of the `isEnabled` call.
Unleash also ships with a few built-in strategies, and expects client SDK's to implement these. Read more about these [activation strategies](activation-strategies.md). For the built-in strategies to work as expected the client should also allow the user to define an [unleash-context](unleash-context.md). The context should be possible to pass in as part of the `isEnabled` call.
### Extension points
@ -102,16 +102,16 @@ Client implementation should also provide a defined interface to make it easier
## Fetching feature toggles (polling)
The client implementation should fetch toggles in the background, as regular polling. In thread based environment (e.g. Java) this needs to be done on a separate thread. The default poll interval should be **15 seconds**, and it should be configurable.
The client implementation should fetch toggles in the background as regular polling. In a thread-based environment, such as Java, this needs to be done in a separate thread. The default poll interval should be **15 seconds**, and it should also be configurable.
## Client registration
Client implementation should at initialization register with the unleash-server. The should send a registration as specified in the [api documentation](api/client/register-api.md). The registration must include all fields specified.
On start-up, the clients should register with the Unleash server. The registration request must include the required fields specified in the [API documentation](api/client/register-api.md).
## Metrics
Clients are expected to send metrics back to Unleash API at regular intervals. The metrics is a list of used toggles and how many times they evaluated to _yes_ or _no_ in the current period. Read more about how to send the metrics in the [metrics-api](api/client/metrics-api.md) documentation.
Clients are expected to send metrics back to Unleash API at regular intervals. The metrics are a list of used toggles and how many times they evaluated to yes or no in at the time of requesting the metrics. Read more about how to send metrics in the [Metrics API](api/client/metrics-api.md) documentation.
## Backup Feature Toggles
The SDK also persists the latest known state to a local file at the instance where the client is running. It will persist a local copy every time the client detects changes from the API. Having a local backup of the latest known state minimises the consequence of clients not being able to to talk to Unleash API at startup. This is required because network is unreliable.
The SDK also persists the latest known state to a local file on the instance where the client is running. It will store a local copy every time the client receives changes from the API. Having a local backup of the latest known state minimises the consequences of clients not being able to talk to the Unleash API on startup. This is necessary due to network unreliability.

2
docs/database-backup.md
View File

@ -3,7 +3,7 @@ id: database_backup
title: Database Backup
---
When upgrading to a new major version of Unleash it is advised to do a full database backup to ease rollback in case of failures.
When upgrading to a new major version of Unleash, we advise to do a full database backup to ease rollback in case of failures.
1. Create a database backup:

2
docs/database-schema.md
View File

@ -3,7 +3,7 @@ id: database_schema
title: Database Schema
---
This document describes our current database schema used in PostgreSQL. We use db-migrate to migrate (create tables, add columns etc) the database.
This document describes our current database schema used in PostgreSQL. We use db-migrate to migrate (create tables, add columns, etc.) the database.
## Table: _migrations_

8
docs/developer-guide.md
View File

@ -5,7 +5,7 @@ title: Developer guide
## PostgreSQL
To run and develop unleash you need to have PostgreSQL database (PostgreSQL v.9.5.x or newer) locally.
To run and develop unleash, you need to have PostgreSQL database (PostgreSQL v.9.5.x or newer) locally.
### Create a local unleash databases in postgres
@ -32,7 +32,7 @@ export TEST_DATABASE_URL=postgres://unleash_user:passord@localhost:5432/unleash_
## PostgreSQL with docker
If you dont want to install PostgreSQL locally you can spin up an instance with docker. We have created a script to ease this process: `scripts/docker-postgres.sh`
If you don't want to install PostgreSQL locally, you can spin up an Docker instance. We have created a script to ease this process: `scripts/docker-postgres.sh`
## Commands
@ -59,7 +59,7 @@ We use database migrations to track database changes.
### Making a schema change
In order to run migrations you will set the environment variable for DATABASE_URL
To run migrations, you will set the environment variable for DATABASE_URL
`export DATABASE_URL=postgres://unleash_user:passord@localhost:5432/unleash`
@ -102,7 +102,7 @@ Test your migrations:
## Publishing / Releasing new packages
Please run `npm run nsp` nad `npm run test` checks before publishing.
Please run `npm run nsp` and `npm run test` checks before publishing.
Run `npm run publish` to start the publishing process.

30
docs/getting-started.md
View File

@ -5,9 +5,9 @@ title: Getting Started
## Requirements
You will need Node.js >= 8.0.0 and a **PostreSQL** 9.5+ database instance to be able to run Unleash.
You will need Node.js >= 8.0.0 and a **PostgreSQL** 9.5+ database instance to be able to run Unleash.
When starting Unleash you must specify a database uri (can be set as environment variable DATABASE_URL) which includes a username and password, that have rights to migrate the database.
When starting Unleash you must specify a database URI (can be set as environment variable DATABASE_URL) which includes a username and password, that have rights to migrate the database.
On startup _Unleash_ will perform necessary migrations if needed.
@ -41,20 +41,20 @@ unleash
});
```
Available unleash options includes:
Available unleash options include:
- **databaseUrl** - the postgress database url to connect to. Should include username/password.
- **databaseSchema** - the postgress database schema to use. Defaults to 'public'
- **port** - Which port should the unleash-server bind to?
- **databaseUrl** - the postgres database url to connect to. Should include username/password.
- **databaseSchema** - the postgres database schema to use. Defaults to 'public'.
- **port** - which port the unleash-server should bind to.
- **enableLegacyRoutes** (boolean) - allows you to turn on/off support for legacy routes to support older clients. Enabled by default.
- **serverMetrics** (boolean) - Use this option to turn off prometheus metrics.
- **preHook** (function) - This is a hook if you need to provide any middlewares to express before `unleash` adds any. Express app instance is injected as first arguement.
- **preRouterHook** (function) - Use this to register custom express middlewares before the `unleash` specific routers are added. This is typically how you would register custom middlewares to handle authentication.
- **secret** (string) - Set this when you want to secure unleash. Used to encrypt the user session.
- **adminAuthentication** (string) - Use this when implementing custom admin authentication [securing-unleash](./securing-unleash.md). Possible values are:
- `none` - Will disable authentication altogether
- `unsecure` - (default) Will use simple cookie based authentication. UI will require the user to specify an email in order to use unleash.
- `custom` - Use this when you implement your own custom authentication logic.
- **serverMetrics** (boolean) - use this option to turn on/off prometheus metrics.
- **preHook** (function) - this is a hook if you need to provide any middlewares to express before `unleash` adds any. Express app instance is injected as first argument.
- **preRouterHook** (function) - use this to register custom express middlewares before the `unleash` specific routers are added. This is typically how you would register custom middlewares to handle authentication.
- **secret** (string) - set this when you want to secure unleash. Used to encrypt the user session.
- **adminAuthentication** (string) - use this when implementing custom admin authentication [securing-unleash](./securing-unleash.md). Possible values are:
- `none` - will disable authentication altogether
- `unsecure` - (default) will use simple cookie based authentication. UI will require the user to specify an email in order to use unleash.
- `custom` - use this when you implement your own custom authentication logic.
### 3. Docker
@ -84,7 +84,7 @@ function consoleLoggerProvider(name) {
}
```
The logger interface with its `debug`, `info`, `warn` and `error` methods expects format string support as seen in `debug` or the JavaScript `console` object. Many commonly used logging implementations cover this API, e.g. bunyan, pino or winston.
The logger interface with its `debug`, `info`, `warn` and `error` methods expects format string support as seen in `debug` or the JavaScript `console` object. Many commonly used logging implementations cover this API, e.g., bunyan, pino or winston.
### How do I set a logger provider?

14
docs/migration-guide.md
View File

@ -3,22 +3,22 @@ id: migration_guide
title: Migration Guide
---
Generally the intention is that `unleash-server` should always provide support for clients one lower major version. This should make possible to upgrade `unleash` gradually.
Generally, the intention is that `unleash-server` should always provide support for clients one major version lower than the current one. This should make it possible to upgrade `unleash` gradually.
## Upgrading from v2.x to v3.x
The notable change introduced in Unleash v3.x is a strict separation of api paths for client requests and admin requests. This makes it easier to implement different authentication mechanisms for the admin UI and all unleash-clients. You can read more about [securing unleash](https://github.com/Unleash/unleash/blob/master/docs/securing-unleash.md).
The notable change introduced in Unleash v3.x is a strict separation of API paths for client requests and admin requests. This makes it easier to implement different authentication mechanisms for the admin UI and all unleash-clients. You can read more about [securing unleash](https://github.com/Unleash/unleash/blob/master/docs/securing-unleash.md).
The recommended approach is to first upgrade the `unleash-server` to v3 (which still supports v2 clients). After this is done you should upgrade all your clients to v3.
The recommended approach is to first upgrade the `unleash-server` to v3 (which still supports v2 clients). After this is done, you should upgrade all your clients to v3.
After upgrading all your clients you should consider turning off legacy routes, used by v2 clients. Read more about this option in in the [gettings started guide](https://github.com/Unleash/unleash/blob/master/docs/getting-started.md#2-or-programmatically).
After upgrading all your clients, you should consider turning off legacy routes, used by v2 clients. Read more about this option in the [Getting started guide](https://github.com/Unleash/unleash/blob/master/docs/getting-started.md#2-or-programmatically).
## Upgrading from v1.0 to v2.0
### Caveat 1: Not used db-migrate to migrate the unleash database?
In FINN we used, for internal reasons, liquebase to migrate our database.
Because unleash from version 2.0 migrates the database internally, with db-migrate, you need to make sure that all previous migrations for version 1 exists, so unleash does not try to create tables that already exists.
In FINN we used liquibase, for internal reasons, to migrate our database.
Because unleash from version 2.0 migrates the database internally, with db-migrate, you need to make sure that all previous migrations for version 1 exist, so that Unleash does not try to create already existing tables.
#### How to check?
@ -30,4 +30,4 @@ Before starting unleash version 2 you have to run the SQL located under `scripts
### Caveat 2: databaseUrl (not database*Uri*)
Using unleash as a lib and injecting your own config? Then you should know that we changed the databaseUri config param name to **databaseUrl**. This to align it with the environment variable (DATABASE_URL), avoiding multiple names for same config param.
Using Unleash as a library and injecting your own config? Then you should know that we changed the `databaseUri` config param name to **databaseUrl**. This is to make sure the param is aligned with the environment variable `DATABASE_URL` and avoid multiple names for the same config param.

16
docs/securing-unleash.md
View File

@ -3,15 +3,15 @@ id: securing_unleash
title: Securing Unleash
---
The Unleash API is split in two different paths: `/api/client` and `/api/admin`. This makes it easy to have different authentication strategy for the admin interface and the client-api used by the applications integrating with Unleash.
The Unleash API is split into two different paths: `/api/client` and `/api/admin`. This makes it easy to have different authentication strategy for the admin interface and the client-api used by the applications integrating with Unleash.
## General settings
Unleash uses an encrypted cookie to maintain a user session. This allows users to be logged in across instances of Unleash. To protect this cookie you should specify the `secret` option when starting unleash.-
Unleash uses an encrypted cookie to maintain a user session. This allows users to be logged in across multiple instances of Unleash. To protect this cookie, you should specify the `secret` option when starting Unleash.
## Securing the Admin API
In order to secure the Admin API you have to tell Unleash that you are using a custom admin authentication and implement your authentication logic as a preHook. You should also set the secret option to a protected secret in your system.
To secure the Admin API, you have to tell Unleash that you are using a custom admin authentication and implement your authentication logic as a preHook. You should also set the secret option to a protected secret in your system.
```javascript
const unleash = require('unleash-server');
@ -40,7 +40,7 @@ Additionally, you can trigger the admin interface to prompt the user to sign in
}
```
Examples on custom authentication hooks:
Examples of custom authentication hooks:
- [google-auth-hook.js](https://github.com/Unleash/unleash/blob/master/examples/google-auth-hook.js)
- [basic-auth-hook.js](https://github.com/Unleash/unleash/blob/master/examples/basic-auth-hook.js)
@ -49,9 +49,9 @@ We also have a version of Unleash deployed on Heroku which uses Google OAuth 2.0
## Securing the Client API
A common way to support client access is to use pre shared secrets. This can be solved by having clients send a shared key in a http header with every client request to the Unleash API. All official Unleash clients should support this.
A common way to support client access is to use pre-shared secrets. This can be solved by having clients send a shared key in an HTTP header with every client request to the Unleash API. All official Unleash clients should support this.
In the [Java client](https://github.com/Unleash/unleash-client-java#custom-http-headers) this looks like:
In the [Java client](https://github.com/Unleash/unleash-client-java#custom-http-headers) this would look like this:
```java
UnleashConfig unleashConfig = UnleashConfig.builder()
@ -62,7 +62,7 @@ UnleashConfig unleashConfig = UnleashConfig.builder()
.build();
```
On the unleash server side you need to implement a preRouter hook which verifies that all calls to `/api/client` includes this pre shared key in the defined header. This could look something like this:
On the Unleash server side, you need to implement a preRouter hook which verifies that all calls to `/api/client` include this pre-shared key in the defined header. This could look something like this.
```javascript
const unleash = require('unleash-server');
@ -91,4 +91,4 @@ unleash
[client-auth-unleash.js](https://github.com/Unleash/unleash/blob/master/examples/client-auth-unleash.js)
PS! Remember to disable legacy route by setting the `enableLegacyRoutes` option to false. This will require all your clients to be on v3.x.
PS! Remember to disable legacy routes by setting the `enableLegacyRoutes` option to false. This will require all your clients to be on v3.x.

6
docs/unleash-context.md
View File

@ -3,7 +3,7 @@ id: unleash_context
title: Unleash Context
---
In order to standardise a few activation strategies we also needed to standardise a unleash context, which contains some fields that varies per requests, needed to implement the activation strategies.
To standardise a few activation strategies, we also needed to standardise the Unleash context, which contains fields that vary per request, required to implement the activation strategies.
The unleash context is defined by these fields:
@ -14,6 +14,6 @@ The unleash context is defined by these fields:
All fields are optional, but if they are not set you will not be able to use certain activation strategies.
E.g. the userWithId-strategy obviously depends on the userId field.
E.g., the `userWithId` strategy obviously depends on the `userId` field.
The properties field is more generic and can be used to provide more abritary data to the strategies. A common usage is to add more metadata, e.g. that the current user is a beta user, and thus the betaUser-strategy will use this info in its implementation.
The `properties` field is more generic and can be used to provide more abritary data to strategies. Typical usage is to add more metadata. For instance, the `betaUser` strategy may read a field from `properties` to check whether the current user a beta user.

8
website/pages/en/index.js
View File

@ -112,7 +112,7 @@ const Block = props => (
const FeatureCallout = () => (
<div className="productShowcaseSection paddingBottom" style={{textAlign: 'center'}}>
<p>
Unleash is a feature toggle system, that gives you a great overview over all feature toggles across
Unleash is a feature toggle system, that gives you a great overview of all feature toggles across
all your applications and services. It comes with official client implementations for Java, Node.js, Go, Ruby and Python.
</p>
<p>
@ -127,7 +127,7 @@ const UnleashClient = () => (
<h2>Client implementations</h2>
<p>
Unleash has offical SDK's for Java, Node.js, Go, Ruby and Python. And we will be happy to add implementations in other langugages written by you! These libraries makes it very easy to use Unleash in you application.
Unleash has official SDK's for Java, Node.js, Go, Ruby and Python. And we will be happy to add implementations in other languages written by you! These libraries make it very easy to use Unleash in your application.
</p>
<div className="gridBlock">
@ -165,7 +165,7 @@ const TryOut = () => (
content: 'We have deployed a demo version of [Unleash on Heroku](https://unleash.herokuapp.com). '+
'Here you can play with the Unleash UI, define some feature toggles and get a feel of how to use Unleash. <br /><br />'+
'It is even possible to use one of the Unleash client SDKs and test it out Unleash your application. '+
'To do this you should connect one of the clients using the hosted API url: https://unleash.herokuapp.com/api/.',
'To do this, you should connect one of the clients using the hosted API URL: https://unleash.herokuapp.com/api/.',
image: imgUrl('dashboard.png'),
imageAlign: 'left',
align: 'left',
@ -179,7 +179,7 @@ const ActivationStrategies = () => (
<Block background="dark">
{[
{
content: 'It\'s fine to have a system for turning stuff on and off. But some times we want more granular control, we want to decide who to the toggle should be enabled for. This is where [activation strategies](docs/activation_strategy) comes in to the picture. Activation strategies take arbitrary config and allows us to enable a toggle in various ways.',
content: 'It\'s great to have a system for turning stuff on and off. Sometimes, however, we want more granular control, and we want to decide who the toggle should be enabled for. This is where activation strategies come into the picture. Activation strategies take arbitrary config and allow us to enable a toggle in various ways.',
image: imgUrl('logo-inverted.png'),
imageAlign: 'right',
title: 'Activation strategies',