Updated docs

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 0.6.4
+
+- Updated request to effectively use hoek 4.2.1
+- Removed unnecessary console.log
+- Updated documentation
+
 ## 0.6.3
 
 - Fixed find target bug in HAR injector

README.md

@@ -56,9 +56,9 @@ The following animation shows the first-time experience, where the default confi
 
 ## Configuration
 
-kras uses configuration files and command line options to be properly configred. The configuration files are named `.krasrc` and are looked up in the following order: home directory, local directory, via the command line specified configuration file. Configuration options are merged from left to right.
+kras uses configuration files and command line options to be properly configured. The configuration files are named `.krasrc` and are looked up in the following order: home directory, local directory, via the command line specified configuration file. Configuration options are merged from left to right.
 
-If specified the command line options have higher precendence. The following options exist.
+If specified the command line options have higher precedence. The following options exist.
 
 ```plain
   -c, --config  Sets the configuration file to use, by default .krasrc  [string]
@@ -67,6 +67,7 @@ If specified the command line options have higher precendence. The following opt
   -d, --dir     Sets the base directory of the server, by default ...   [string]
   --cert        Sets the certificate of the server, by default ...      [string]
   --key         Sets the key of the server, by default ...              [string]
+  --skip-api    Sets the management API to be inaccessible              [toggle]
 ```
 
 The `.krasrc` is a simple JSON format. An example is the following configuration:
@@ -167,7 +168,11 @@ Yes. Injectors are powerful stuff and can be written in your own code base / pro
 
 *I don't like the web client - what can I do?*
 
-The bundled client is only the default client. If you prefer you can interact with kras via `curl` or postman or any other possibility to run raw API requests. If this is too tedious you could also write a custom client. If the client is registered as an NPM package kras can also (via the configuration) serve that client from the mangement endpoint. Details are aggregated [in the client documentation](docs/client.md).
+The bundled client is only the default client. If you prefer you can interact with kras via `curl` or postman or any other possibility to run raw API requests. If this is too tedious you could also write a custom client. If the client is registered as an NPM package kras can also (via the configuration) serve that client from the management endpoint. Details are aggregated [in the client documentation](docs/client.md).
+
+*I need to protect the management API but how?*
+
+The management API can be protected with the `auth` option. More information can be read [in the authentication documentation](docs/auth.md).
 
 ## License
 

docs/auth.md

@@ -0,0 +1,23 @@
+# Authentication
+
+kras is mainly developer for a single developer use case, i.e., one person locally running the mock server. Nevertheless, the potential use cases and applications go far beyond that and may require that access to the management API / client is still available, however, restricted to certain persons.
+
+The configuration of kras allows protecting the full API. The client is then still accessible, but will show a login initially.
+
+The following snippet shows the simplest configuration. In the example we would allow only a single user access with `foo` being the corresponding user name.
+
+```json
+{
+  "auth": {
+    "provider": "simple",
+    "accounts": [{
+      "username": "foo",
+      "password": "bar"
+    }]
+  }
+}
+```
+
+By default, kras comes with a single identity provider only. The provider is called `simple` and has only one configuration option; `accounts`, which define the accounts to be allowed access. Usernames and passwords are directly stored in the configuration.
+
+Since the `simple` provider may be far too simple (and insecure) you may want to roll your own provider. This could be done via a middleware that provides the provider.

docs/client.md

@@ -1,6 +1,6 @@
 # Client
 
-The defaut management client is a single-page application that was build using React as view layer. It tries to be minimal yet complete.
+The default management client is a single-page application that was build using React as view layer. It tries to be minimal yet complete.
 
 kras also provides the ability to show other clients at the management endpoint. The configuration contains a `client` property, which (if supplied) should map to the file being served (e.g., `index.html`). The location can be relative to the base directory specific in the configuration (falls back to the current working directory if missing).
 
@@ -22,4 +22,4 @@ function fullUrl(url, query) {
 }
 ```
 
-Keep in mind that for WebSocket the decision also had to be made between secure websockets and normal websockets.
+Keep in mind that for WebSocket the decision also had to be made between secure and normal websockets.

docs/getting-started.md

@@ -38,7 +38,7 @@ The injectors are so queried in the order given in the configuration file (by de
 
 Besides the command line some options and configuration files some options can be changed at runtime. This is done from the manage endpoints of the mock server. By default, the management endpoint is available under `/manage`. It can be configured as well. Besides activating or deactivating injectors we'll also find information about previously handled requests and messages. We can also broadcast new events via the web socket channel.
 
-The web socket channel is (if activated) also proxied to the real API. However, as the mock server is sitting in between the real API and the client it is possible to also use it. This is done to allow simulating rare events such as a reboot of a SHC. Besides using the web interface to emit a message we can also send a message to the `~/broadcast` management endpoint (e.g., `/manage/broadcast`) using a POST message with the body representing the web socket message.
+The web socket channel is (if activated) also proxyed to the real API. However, as the mock server is sitting in between the real API and the client it is possible to also use it. This is done to allow simulating rare events such as a reboot of a SHC. Besides using the web interface to emit a message we can also send a message to the `~/broadcast` management endpoint (e.g., `/manage/broadcast`) using a POST message with the body representing the web socket message.
 
 Now that we know roughly how it works it is time to look at some of the ordinary injectors in more detail. We already know that the source files for all these injectors are sitting in a configured directory. There is also a watcher to refresh the injector's content when a watched file changes. Each injector only uses files following a specific pattern, e.g., *.json, as file name. Let's start with details for the JSON injector.
 

docs/har-injector.md

@@ -14,4 +14,4 @@ interface HarInjectorConfiguration {
 }
 ```
 
-The `delay` option can artifically delay the response to requests. This is particularly useful to simulate something with exactly the same timing as the HAR file proposed.
+The `delay` option can artificially delay the response to requests. This is particularly useful to simulate something with exactly the same timing as the HAR file proposed.

docs/manage-api.md

@@ -77,7 +77,7 @@ Broadcasts the body of the request via websocket. Can be anything, such that no
 
 ### GET /data
 
-Gets the current request data split in normal requests, errored requests, and websocket messages.
+Gets the current request data split in normal requests, failed requests, and websocket messages.
 
 Example:
 
@@ -105,23 +105,23 @@ This is the live feed to be notified when a new request has been recorded.
 
 ### GET /data/request/:id
 
-A detailled view of a specific request.
+A detailed view of a specific request.
 
 Example:
 
 ```json
-{  
+{
   "id":"ba419f81-2b7f-4bf0-9147-9446bc3bf3d0",
   "start":"2018-03-09T20:50:36.223Z",
   "end":"2018-03-09T20:50:36.468Z",
-  "request":{  
+  "request": {
     "url":"/posts",
     "target":"/api",
-    "query":{  
+    "query": {
 
     },
     "method":"GET",
-    "headers":{  
+    "headers": {
       "host":"localhost:9000",
       "connection":"keep-alive",
       "upgrade-insecure-requests":"1",
@@ -132,18 +132,18 @@ Example:
     },
     "content":""
    },
-   "response":{  
-    "status":{  
-      "code":200,
+   "response": {
+    "status": {
+      "code": 200,
       "text":"OK"
     },
     "url":"https://jsonplaceholder.typicode.com/posts",
-    "content":{  
+    "content": {
       "type":"Buffer",
-      "data":[  
+      "data": [
         //...
       ],
-      "headers":{  
+      "headers": {
         "date":"Fri, 09 Mar 2018 20:50:36 GMT",
         "content-type":"application/json; charset=utf-8",
         "transfer-encoding":"chunked",
@@ -163,9 +163,9 @@ Example:
         "server":"cloudflare",
         "cf-ray":"3f906a31a8bb6c94-SJC"
       },
-      "injector":{  
+      "injector": {
         "name":"proxy-injector",
-        "host":{  
+        "host": {
           "name":"https://jsonplaceholder.typicode.com"
         }
       }
@@ -176,11 +176,11 @@ Example:
 
 ### GET /data/message/:id
 
-A detailled view on the specific websocket message.
+A detailed view on the specific websocket message.
 
 ### GET /data/error/:id
 
-A detailled view on the specific errored request.
+A detailed view on the specific failed request.
 
 ### GET /file/:name
 

docs/proxy-injector.md

@@ -23,4 +23,4 @@ interface ProxyInjectorConfiguration {
 }
 ```
 
-The mapping is already a general configuration, as the targets need to be known as well as their usual counterparts (e.g., to identify the correct URLs in an HAR file). The `agentOptions` can be used to specify more sophisticated options for the proxied request (e.g., which ciphers to use). The `proxy` option allows us to set a (corporate?) proxy to be used on the local machine (oh the irony - a proxy server that allows setting another proxy ...).
+The mapping is already a general configuration, as the targets need to be known as well as their usual counterparts (e.g., to identify the correct URLs in an HAR file). The `agentOptions` can be used to specify more sophisticated options for the proxyed request (e.g., which ciphers to use). The `proxy` option allows us to set a (corporate?) proxy to be used on the local machine (oh the irony - a proxy server that allows setting another proxy ...).

docs/webpack.md

@@ -37,7 +37,7 @@ Potentially, the port of kras needs to be changed, e.g., via the *.krasrc* in th
 
 For webpack (and many other bundlers, even task runners, e.g., Gulp) we can abuse the fact that kras was released not only as a CLI tool, but also as a library. So at the end of the day we may simply use the package within our application / run scripts to spawn / block the port we want it to.
 
-While it can make sense to run kras always, we usually want to run kras only during (live) development, i.e., when the webpack dev server is online. There are multiple ways to archieve this:
+While it can make sense to run kras always, we usually want to run kras only during (live) development, i.e., when the webpack dev server is online. There are multiple ways to achieve this:
 
 - Use a dedicated configuration file for the dev server
 - Branch in the main configuration file

package.json

@@ -1,6 +1,6 @@
 {
   "name": "kras",
-  "version": "0.6.3",
+  "version": "0.6.4",
   "description": "Efficient server proxying and mocking in Node.js.",
   "main": "dist/server/kras.js",
   "types": "dist/server/kras.d.ts",