Merge branch 'stage' into promTo/stage

Author: iamchriswick

docs/.vuepress/nav/left/guides.js

@@ -57,5 +57,6 @@ module.exports = [
 //         '/guides/qr-acceptance',
 //     ];
 // }
+ 
+
 
-// 

docs/.vuepress/theme/components/PageResource.vue

@@ -132,14 +132,7 @@
                   "
                 >
                   Length: <code>{{ type.minLength }}</code>
-                </li>
-                <li v-else-if="type.minLength && type.maxLength">
-                  Length:
-                  <code
-                    >&#8804; {{ type.minLength }} && &#8805;
-                    {{ type.maxLength }}</code
-                  >
-                </li>
+                </li
                 <li v-else-if="type.minLength">
                   Length: <code>&#8805; {{ type.minLength }}</code>
                 </li>

docs/api/guides/introduction/authentication.md

@@ -2,25 +2,39 @@
 title: Authentication
 description: Authentication
 ---
-
 # Authentication
 
-In the Settle API different authentication levels (auth levels) can be achieved depending on the authentication method being used. In the [API Reference](/api/merchant/) the required level for each endpoint in the API is given. A list is given here of the auth levels in the Settle API, ordered from lowest to highest level:
+In the Settle API different authentication levels ***(Auth Levels)*** can be achieved depending on the authentication method being used. In the [API Reference](/api/merchant/) the required level for each endpoint in the API is given. A list is given here of the **Auth Levels** in the Settle API, ordered from lowest to highest level:
 
-1. OPEN _(no authentication required)_
-2. [SECRET](#authentication-using-secret)
-3. [KEY](#authentication-using-rsa-signature)
+1. OPEN *(no authentication required)*
+2. [**JWT** *(Shared Secret)*](#authentication-using-secret)
+3. [**RSA** *(Private/Public Keypair)*](#authentication-using-rsa-signature)
 
-When authenticated with a particular auth level, the client is also authorized for endpoints requiring a lower auth level. E.g. if authenticated with auth level [KEY](/guides/authentication/#authentication-using-rsa-signature), endpoints requiring [SECRET](/guides/authentication/#authentication-using-secret) or OPEN are also accessible.
+When authenticated with a particular **Auth Level**, the client is also authorized for endpoints requiring a lower authentication level. E.g. if authenticated with **Auth Level** [](/guides/authentication/#authentication-using-rsa-signature)RSA, endpoints requiring [JWT](/guides/authentication/#authentication-using-secret) or OPEN are also accessible.
 
 ## Required Request Headers
 
 Any request to the Settle API requires the following request headers:
 
-| X-Auka-Merchant: | This header should contain the Settle ID of the merchant as returned in the `id` field of the [`merchant`](https://developer.settle.eu/handlers.html#get--merchant--merchant_id-- 'GET /merchant/<merchant_id>/') endpoint. |
-| X-Auka-User: | The ID (username) of the user/client doing the request on behalf of the merchant. Users are created by the merchant through the Self Service Portal or by the integrator using the `user` endpoint. Each user has is an ID locally unique for the merchant and is assigned a shared secret and/or a RSA public key that is used for authentication. |
-| Authorization: | The value of this field depends on what kind of authentication scheme is being used. Currently the supported schemes are _SECRET_ and _RSA-SHA256_. The general form of this header is: `Authorization: <auth_scheme> <auth_data>` |
-| X-Auka-Integrator: | Only to be used by integrators acting as a proxy on behalf of merchant client, in which case it replaces the **X-Auka-User** header. The value of this field is the ID issued to the integrator by Settle. When this header is used only authentication using RSA signatures is allowed (not secret) and Settle will check the signature against the public key of the integrator. |
+#### X-Settle-Merchant
+
+This header should contain the Settle ID of the merchant as returned in the `id` field of the [ `merchant.profile.get` ](/api/reference/rest/v1/merchant.profile/get/) endpoint.
+
+#### X-Settle-User
+
+The ID of the user/client doing the request on behalf of the Merchant. Users are created by the Merchant through the Self Service Portal or by the Integrator using the [`merchant.apiKeys.create`](/api/reference/rest/v1/merchant.apiKeys/create/) endpoint. Each **X-Settle-User** has an ID locally unique for the Merchant and is assigned a **JWT** *(Shared Secret)* and/or an **RSA** Public Key that is used for authentication.
+
+#### Authorization
+
+The value of this field depends on what kind of authentication scheme is being used. Currently the supported schemes are **JWT** *(Shared Secret)* and **RSA-SHA256**.
+
+The general form of this header is:
+
+`Authorization: <auth_scheme> <auth_data>`
+
+#### X-Settle-Integrator
+
+Only to be used by integrators acting as a proxy on behalf of a Merchant client, in which case it replaces the **X-Settle-User** header. The value of this field is the ID issued to the integrator by Settle. When this header is used only authentication using **RSA** signatures is allowed *(not secret)* and Settle will check the signature against the public key of the integrator.
 
 ::: tip NOTE
 When using the Settle testbed environment, an **X-Testbed-Token** header is also required. The value of this header is the testbed token you received via email when activating your testbed account. It looks like:
@@ -29,12 +43,12 @@ When using the Settle testbed environment, an **X-Testbed-Token** header is also
 :::
 
 ::: tip NOTE
-The **X-Auka-Integrator** header MUST NOT be used unless the merchant clients are communicating _through_ a server, controlled by the integrator, acting as a proxy. If a client is using a direct connection to Settle, even though the integrator owns the client and may control it through some other channel, it MUST use merchant user credentials and the **X-Auka-User** header.
+The **X-Auka-Integrator** header MUST NOT be used unless the merchant clients are communicating *through* a server, controlled by the integrator, acting as a proxy. If a client is using a direct connection to Settle, even though the integrator owns the client and may control it through some other channel, it MUST use merchant user credentials and the **X-Auka-User** header.
 :::
 
-## Authentication using SECRET
+## Authentication using JWT
 
-- Auth Level: SECRET
+* **Auth Level:** JWT
 
 Authentication using a shared secret (JSON Web Token) is the simplest authentication method supported by Settle. This method requires an authorization header on the following form:
 
@@ -56,9 +70,9 @@ Authorization: SECRET MySecretPassword
 
 ## Authentication using RSA signature
 
-- Auth Level: KEY
+* **Auth Level:** RSA
 
-Settle generates and validates according to the _PKCS#1 v1.5_ (RSASSA-PKCS1-v1_5) standard described in **[RFC 3447](http://tools.ietf.org/html/rfc3447.html)**. The hash function used in the signing procedure is [SHA256](https://en.wikipedia.org/wiki/SHA-2).
+Settle generates and validates according to the *PKCS#1 v1.5* (RSASSA-PKCS1-v1_5) standard described in **[RFC 3447](http://tools.ietf.org/html/rfc3447.html)**. The hash function used in the signing procedure is [SHA256](https://en.wikipedia.org/wiki/SHA-2).
 
 ### Headers
 
@@ -70,7 +84,7 @@ The RSA authentication method requires two extra headers:
 
 #### X-Auka-Content-Digest
 
-> The _base64_ encoded hash digest of the request body. If the body is empty, the hash should be computed on an empty string. The value of the header should be on the form `<algorithm (uppercase)>=<digest value>`. So, if the SHA256 hashing algorithm is used on a request with empty body, the header will be: `X-Auka-Content-Digest: SHA256=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=` Currently only the SHA256 hashing algorithm is supported.
+> The *base64* encoded hash digest of the request body. If the body is empty, the hash should be computed on an empty string. The value of the header should be on the form `<algorithm (uppercase)>=<digest value>`. So, if the SHA256 hashing algorithm is used on a request with empty body, the header will be: `X-Auka-Content-Digest: SHA256=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=` Currently only the SHA256 hashing algorithm is supported.
 
 For RSA authentication the authorization header looks like this:
 
@@ -131,4 +145,4 @@ The Python script that was used for generating the signature and `X-Auka-Content
 
 ## Verifying signatures from Settle
 
-Whenever Settle is sending callbacks to the client over HTTPS the request from Settle is signed using the same RSA method as described in the above _[section](/guides/authentication/#authentication-using-rsa-signature)_. The client should authenticate callbacks from Settle by verifying the signature given by Settle in the Authorization header of the request. The public key used by Settle in test environments can be downloaded [`here`](https://developer.settle.eu/_downloads/testserver-pub.pem). The public key for the production environment can be obtained by contacting Settle.
+Whenever Settle is sending callbacks to the client over HTTPS the request from Settle is signed using the same RSA method as described in the above *[section](/guides/authentication/#authentication-using-rsa-signature)*. The client should authenticate callbacks from Settle by verifying the signature given by Settle in the Authorization header of the request. The public key used by Settle in test environments can be downloaded [`here`](https://developer.settle.eu/_downloads/testserver-pub.pem). The public key for the production environment can be obtained by contacting Settle.

docs/api/reference/rest/v1/merchant.balance/get.md

@@ -7,6 +7,7 @@ schema: merchant.balance
 operationId: merchant.balance.get
 operation: get
 method: get
+
 authLevel: JWT
 authRoles: USER, SUPERUSER, INTEGRATOR
 ---