From aa8e0fda6cd337561283cabb47f3bf040b2ed95e Mon Sep 17 00:00:00 2001 From: Jason Fox Date: Tue, 4 Jun 2024 09:53:45 +0200 Subject: [PATCH] Prettify --- README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 80a5361..618955b 100644 --- a/README.md +++ b/README.md @@ -206,9 +206,10 @@ The `idm` container is a web application server listening on two ports: - Port `3443` has been exposed for secure HTTPS traffic for the site and REST API > [!NOTE] -> HTTPS should be used throughout for any secured application, but to do this properly, -> **Keyrock** requires a trusted SSL certificate - the default certificate is self-certified and available for testing -> purposes. The certificates can be overridden by attaching a volume to replace the files under `/opt/fiware-idm/certs`. +> +> HTTPS should be used throughout for any secured application, but to do this properly, **Keyrock** requires a trusted +> SSL certificate - the default certificate is self-certified and available for testing purposes. The certificates can +> be overridden by attaching a volume to replace the files under `/opt/fiware-idm/certs`. > > In a production environment, all access should occur over HTTPS, to avoid sending any sensitive information using > plain-text. Alternatively HTTP can be used within a private network behind a configured HTTPS Reverse Proxy @@ -231,10 +232,10 @@ The `idm` container is driven by environment variables as shown: | IDM_HTTPS_PORT | `3443` | Port used by the **Keyrock** App Server for HTTP traffic this has been altered from the default 443 | > [!NOTE] -> that this example has secured the MySQL password using **Docker Secrets** By using -> `IDM_DB_PASS` with the `_FILE` suffix and referring to a secrets file location. This avoids exposing the password as -> an `ENV` variable in plain-text - either in the `Dockerfile` Image or as an injected variable which could be read -> using `docker inspect`. +> +> that this example has secured the MySQL password using **Docker Secrets** By using `IDM_DB_PASS` with the `_FILE` +> suffix and referring to a secrets file location. This avoids exposing the password as an `ENV` variable in +> plain-text - either in the `Dockerfile` Image or as an injected variable which could be read using `docker inspect`. > > The following list of variables (where used) should be set via secrets with the `_FILE` suffix in a Production System: > @@ -296,6 +297,7 @@ git checkout NGSI-LD ``` > [!NOTE] +> > The initial creation of Docker images can take up to three minutes Thereafter, all services can be initialized from the command-line by running the @@ -308,8 +310,7 @@ the repository: Where `` will vary depending upon the exercise we wish to activate. -> [!NOTE] -> If you want to clean up and start over again you can do so with the following command: +> [!NOTE] If you want to clean up and start over again you can do so with the following command: > > ```console > ./services stop @@ -545,8 +546,7 @@ Once an account is created, the user is sent an eMail to confirm their existence The REST API is also able to create and amend users without their own interaction - this could be useful for bulk CRUD actions for example. -> [!NOTE] -> An eMail server must be configured to send out invites properly, otherwise the invitation may be deleted as +> [!NOTE] An eMail server must be configured to send out invites properly, otherwise the invitation may be deleted as > spam. For testing purposes, it is easier to update the users table directly: `update user set enabled = 1;` All the CRUD actions for Users require an `X-Auth-token` header from a previously logged in administrative user to be