From 458b1911c8589a1bec3e6e58e7a708d75983b3b9 Mon Sep 17 00:00:00 2001 From: f-w Date: Wed, 25 Oct 2023 17:36:16 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20=20@=20d0101?= =?UTF-8?q?ce3750c20c57146a29eb69c102b6fa22313=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- preview/404.html | 4 ++-- preview/docs/acknowledgments/index.html | 2 +- preview/docs/api-config/index.html | 2 +- preview/docs/benchmarks/index.html | 2 +- preview/docs/bulk-import/index.html | 2 +- preview/docs/conduct/index.html | 2 +- preview/docs/config-cronJobs/index.html | 2 +- preview/docs/config-httpHost/index.html | 2 +- preview/docs/config-nodeRoles/index.html | 2 +- preview/docs/config-notification/index.html | 2 +- preview/docs/config-oidc/index.html | 2 +- preview/docs/config-overview/index.html | 2 +- preview/docs/config-reverseProxyIpLists/index.html | 2 +- preview/docs/config-rsaKeys/index.html | 2 +- preview/docs/config-sms/index.html | 2 +- preview/docs/config-subscription/index.html | 2 +- preview/docs/quickstart/index.html | 2 +- preview/docs/shared/filterQueryParam.html | 2 +- preview/docs/shared/filterQueryParamCode.html | 2 +- preview/docs/shared/filterQueryParamExample.html | 2 +- preview/docs/shared/jmespathFilter.html | 2 +- preview/docs/shared/whereQueryParam.html | 2 +- preview/docs/shared/whereQueryParamCode.html | 2 +- preview/docs/shared/whereQueryParamExample.html | 2 +- preview/docs/upgrade/index.html | 2 +- preview/docs/web-console/index.html | 2 +- preview/docs/what's-new/index.html | 2 +- 27 files changed, 28 insertions(+), 28 deletions(-) diff --git a/preview/404.html b/preview/404.html index 7abe377df..ddbbdb6ea 100644 --- a/preview/404.html +++ b/preview/404.html @@ -24,10 +24,10 @@ NotifyBC - + -

404

How did we get here?
Take me home
+

404

There's nothing here.
Take me home
diff --git a/preview/docs/acknowledgments/index.html b/preview/docs/acknowledgments/index.html index 2ad77e5aa..ed60da9db 100644 --- a/preview/docs/acknowledgments/index.html +++ b/preview/docs/acknowledgments/index.html @@ -24,7 +24,7 @@ Acknowledgments | NotifyBC - +
diff --git a/preview/docs/api-config/index.html b/preview/docs/api-config/index.html index 3ea577000..8ed3bbaff 100644 --- a/preview/docs/api-config/index.html +++ b/preview/docs/api-config/index.html @@ -24,7 +24,7 @@ Configuration | NotifyBC - +

Configuration

The configuration API, accessible by only super-admin requests, is used to define dynamic configurations. Dynamic configuration is needed in situations like

  • RSA key pair generated automatically at boot time if not present
  • service-specific subscription confirmation request message template

Model Schema

The API operates on following configuration data model fields:

NameAttributes

id

config id

typestring, format depends on db
auto-generatedtrue

name

config name

typestring
requiredtrue

value

config value.
typeobject
requiredtrue

serviceName

name of the service the config applicable to

typestring
requiredfalse

Get Configurations

GET /configurations
diff --git a/preview/docs/benchmarks/index.html b/preview/docs/benchmarks/index.html
index 21dca595d..6a05bf7b2 100644
--- a/preview/docs/benchmarks/index.html
+++ b/preview/docs/benchmarks/index.html
@@ -24,7 +24,7 @@
     
     Benchmarks | NotifyBC
     
-    
+    
   
   
     
 Benchmarks
tl;dr
A NotifyBC server node can deliver 1 million emails in as little as 1 hour to a SMTP server node. SMTP server node's disk I/O is the bottleneck in such case. Throughput can be improved through horizontal scaling.
When NotifyBC is used to deliver broadcast push notifications to a large number of subscribers, probably the most important benchmark is throughput. The benchmark is especially critical if a latency cap is desired. To facilitate capacity planning, load testing on the email channel has been conducted. The test environment, procedure, results and performance tuning advices are provided hereafter.
 Environment
 Hardware
Two computers, connected by 1Gbps LAN, are used to host
  • NotifyBC
    • Mac Mini Late 2012 model
    • Intel core i7-3615QM
    • 16GB RAM
    • 2TB HDD
  • SMTP and mail delivery 
    • Lenovo ThinkCentre M Series 2015 model
    • Intel core i5-3470
    • 8GB RAM
    • 256GB SSD
 Software Stack
The test was performed in August 2017. Unless otherwise specified, the versions of all other software were reasonably up-to-date at the time of testing.
  • NotifyBC
    • MacOS Sierra Version 10.12.6
    • Virtualbox VM with 8vCPU, 10GB RAM, created using miniShift v1.3.1+f4900b07
    • OpenShift 1.5.1+7b451fc with metrics
    • default NotifyBC OpenShift installation, which contains following relevant pods 
      • 1 mongodb pod with 1 core, 1GiB RAM limit
      • a variable number of Node.js app pods each with 1 core, 1GiB RAM limit. The number varies by test runs as indicated in result.
  • SMTP and mail delivery
    • Windows 7 host
    • Virtualbox VM with 4 vCPU, 3.5GB RAM, running Windows Server 2012
    • added SMTP Server feature
    • in SMTP Server properties dialog box, uncheck all of following boxes in Messages tab 
      • Limit message size to (KB)
      • Limit session size to (KB)
      • Limit number of messages per connection to
      • Limit number of recipients per message to
 Procedure
  1. update or create file /src/config.local.js through configMap. Add sections for SMTP server and a custom filter function
    var _ = require('lodash');
diff --git a/preview/docs/bulk-import/index.html b/preview/docs/bulk-import/index.html
index 09d87b0e1..4af2c7a48 100644
--- a/preview/docs/bulk-import/index.html
+++ b/preview/docs/bulk-import/index.html
@@ -24,7 +24,7 @@
     
     Bulk Import | NotifyBC
     
-    
+    
   
   
     
     Bulk Import
    To facilitate migrating subscriptions from other notification systems, NotifyBC provides a utility script to bulk import subscription data from a .csv file. To use the utility, you need
    • Software installed 
      • Node.js
      • Git
    • Admin Access to a NotifyBC instance by adding your client ip to the Admin IP List
    • a csv file with header row matching subscription model schema. A sample csv file is providedopen in new window. Compound fields (of object type) should be dot-flattened as shown in the sample for field confirmationRequest.sendRequest
    To run the utility
    git clone https://github.com/bcgov/NotifyBC.git
diff --git a/preview/docs/conduct/index.html b/preview/docs/conduct/index.html
index b4d4cdfc2..201e3a561 100644
--- a/preview/docs/conduct/index.html
+++ b/preview/docs/conduct/index.html
@@ -24,7 +24,7 @@
     
     Code of Conduct | NotifyBC
     
-    
+    
   
   
     
     Code of Conduct
    As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
    We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
    Examples of unacceptable behavior by participants include:
    • The use of sexualized language or imagery
    • Personal attacks
    • Trolling or insulting/derogatory comments
    • Public or private harassment
    • Publishing other's private information, such as physical or electronic addresses, without explicit permission
    • Other unethical or unprofessional conduct
    Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
    By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
    This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
    Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting a project maintainer. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.
    This Code of Conduct is adapted from the Contributor Covenantopen in new window, version 1.3.0, available at http://contributor-covenant.org/version/1/3/0/open in new window
    
diff --git a/preview/docs/config-cronJobs/index.html b/preview/docs/config-cronJobs/index.html
index 6bd23e017..6b0ad4576 100644
--- a/preview/docs/config-cronJobs/index.html
+++ b/preview/docs/config-cronJobs/index.html
@@ -24,7 +24,7 @@
     
     Cron Jobs | NotifyBC
     
-    
+    
   
   
     
     Cron Jobs
    NotifyBC runs several cron jobs described below. These jobs are controlled by sub-properties defined in config object cron. To change config, create the object and properties in file /src/config.local.js.
    By default cron jobs are enabled. In a multi-node deployment, cron jobs should only run on the master node to ensure single execution.
    All cron jobs have a property named timeSpec with the value of a space separated fields conforming to unix crontab formatopen in new window with an optional left-most seconds field. See allowed rangesopen in new window of each field.
     Purge Data
    This cron job purges old notifications, subscriptions and notification bounces. The default frequency of cron job and retention policy are defined by cron.purgeData config object in file /src/config.ts
    module.exports = {
diff --git a/preview/docs/config-httpHost/index.html b/preview/docs/config-httpHost/index.html
index 834292736..eeecc78eb 100644
--- a/preview/docs/config-httpHost/index.html
+++ b/preview/docs/config-httpHost/index.html
@@ -24,7 +24,7 @@
     
     HTTP Host | NotifyBC
     
-    
+    
   
   
     
     HTTP Host
    httpHost config sets the fallback http host used by
    • mail merge token substitution
    • internal HTTP requests spawned by NotifyBC
    httpHost can be overridden by other configs or data. For example
    • internalHttpHost config
    • httpHost field in a notification
    There are contexts where there is no alternatives to httpHost. Therefore this config should be defined.
    Define the config, which has no default value, in /src/config.local.js
    module.exports = {
diff --git a/preview/docs/config-nodeRoles/index.html b/preview/docs/config-nodeRoles/index.html
index d1da91657..e670f7f49 100644
--- a/preview/docs/config-nodeRoles/index.html
+++ b/preview/docs/config-nodeRoles/index.html
@@ -24,7 +24,7 @@
     
     Node Roles | NotifyBC
     
-    
+    
   
   
     
diff --git a/preview/docs/config-notification/index.html b/preview/docs/config-notification/index.html
index ab2f430ea..815595b40 100644
--- a/preview/docs/config-notification/index.html
+++ b/preview/docs/config-notification/index.html
@@ -24,7 +24,7 @@
     
     Notification | NotifyBC
     
-    
+    
   
   
     
     Notification
    Configs in this section customize the handling of notification request or generating notifications from RSS feeds. They are all sub-properties of config object notification. Service-agnostic configs are static and service-dependent configs are dynamic.
     RSS Feeds
    NotifyBC can generate broadcast push notifications automatically by polling RSS feeds periodically and detect changes by comparing with an internally maintained history list. The polling frequency, RSS url, RSS item change detection criteria, and message template can be defined in dynamic configs.
    Only first page is retrieved for paginated RSS feeds
    If a RSS feed is paginated, NotifyBC only retrieves the first page rather than auto-fetch subsequent pages. Hence paginated RSS feeds should be sorted descendingly by last modified timestamp. Refresh interval should be adjusted small enough such that all new or updated items are contained in first page.
    For example, to notify subscribers of myService on updates to feed http://my-serivce/rss, create following config item using POST configuration API
    {
diff --git a/preview/docs/config-oidc/index.html b/preview/docs/config-oidc/index.html
index 85ddf76e7..888ee363b 100644
--- a/preview/docs/config-oidc/index.html
+++ b/preview/docs/config-oidc/index.html
@@ -24,7 +24,7 @@
     
     OIDC | NotifyBC
     
-    
+    
   
   
     
     OIDC
    NotifyBC currently can only authenticate RSA signed OIDC access token if the token is a JWT. OIDC providers such as Keycloak meet the requirement.
    To enable OIDC authentication strategy, add oidc configuration object to /src/config.local.js. The object supports following properties
    1. discoveryUrl - OIDC discoveryopen in new window url
    2. clientId - OIDC client id
    3. isAdmin - a predicate function to determine if authenticated user is NotifyBC administrator. The function takes the decoded OIDC access token JWT payload as input user object and should return either a boolean or a promise of boolean, i.e. the function can be both sync or async.
    4. isAuthorizedUser - an optional predicate function to determine if authenticated user is an authorized NotifyBC user. If omitted, any authenticated user is authorized NotifyBC user. This function has same signature as isAdmin
    A example of complete OIDC configuration looks like
    module.exports = {
diff --git a/preview/docs/config-overview/index.html b/preview/docs/config-overview/index.html
index aad282aa9..f0a5abae6 100644
--- a/preview/docs/config-overview/index.html
+++ b/preview/docs/config-overview/index.html
@@ -24,7 +24,7 @@
     
     Configuration Overview | NotifyBC
     
-    
+    
   
   
     
     Configuration Overview
    Helm Chart Configurations
    The document pages in this section cover NoitfyBC app level configurations only. If your NotifyBC is deployed to Kubernetes using Helm, you can also customize infrastructure level configurations.
    There are two types of configurations - static and dynamic. Static configurations are defined in files or environment variables, requiring restarting NotifyBC to take effect, whereas dynamic configurations are defined in databases and updates take effect immediately.
     Static Configurations
    Most static configurations are specified in file /src/config.ts. If you need to change, instead of updating /src/config.ts file, create local file /src/config.local.js or environment specific file /src/config.<env>.js, which is only included when environment variable NODE_ENV equals <env>. Besides js, ts and json file extensions are also supported. The rest of the documentation assumes the file extension is js. Content in these files are deeply merged in following ascending precedence
    • default file /src/config.ts
    • environment specific file /src/config.<env>.js
    • local file /src/config.local.js
    Run build script whenever changing file in /src
    Every time a file under /src, including config files, is updated, run yarn build before restarting NotifyBC to take effect.
    Following configs should be customized per installation
    In addition, if installing from source code
    Customizing other configs only if needed.
     Dynamic Configurations
    Dynamic configs are managed using REST configuration api.
    Why Dynamic Configs?
    Dynamic configs are needed in cases such as
    • to allow define service-specific configs such as message templates
    • in a multi-node deployment, configs can be generated by one node (typically master) and shared with other nodes
    
diff --git a/preview/docs/config-reverseProxyIpLists/index.html b/preview/docs/config-reverseProxyIpLists/index.html
index 203546f8a..09e9eba81 100644
--- a/preview/docs/config-reverseProxyIpLists/index.html
+++ b/preview/docs/config-reverseProxyIpLists/index.html
@@ -24,7 +24,7 @@
     
     Reverse Proxy IP Lists | NotifyBC
     
-    
+    
   
   
     
     Reverse Proxy IP Lists
    SiteMinder, being a gateway approached SSO solution, expects the backend HTTP access point of the web sites it protests to be firewall restricted, otherwise the SiteMinder injected HTTP headers can be easily spoofed. However, the restriction cannot be easily implemented on PAAS such as OpenShift. To mitigate, two configuration objects are introduced to create an application-level firewall, both are arrays of ip addresses in the format of dot-decimalopen in new window or CIDRopen in new window notation
    • siteMinderReverseProxyIps contains a list of ips or ranges of SiteMinder Web Agents. If set, then the SiteMinder HTTP headers are trusted only if the request is routed from the listed nodes.
    • trustedReverseProxyIps contains a list of ips or ranges of trusted reverse proxies. If NotifyBC is placed behind SiteMinder Web Agents, then trusted reverse proxies should include only those between SiteMinder Web Agents and NotifyBC application. When running on OpenShift, this is usually the OpenShift router. Express.js trust proxyopen in new window is set to this config object.
    By default trustedReverseProxyIps is empty and siteMinderReverseProxyIps contains only localhost as defined in /src/config.ts
    module.exports = {
diff --git a/preview/docs/config-rsaKeys/index.html b/preview/docs/config-rsaKeys/index.html
index f2d0cfe7a..46c6de238 100644
--- a/preview/docs/config-rsaKeys/index.html
+++ b/preview/docs/config-rsaKeys/index.html
@@ -24,7 +24,7 @@
     
     RSA Keys | NotifyBC
     
-    
+    
   
   
     
     RSA Keys
    When NotifyBC starts up, it checks if an RSA key pair exists in database as dynamic config. If not it will generate the dynamic config and save it to database. This RSA key pair is used to exchange confidential information with third party server applications through user's browser. For an example of use case, see Subscription API. To make it work, send the public key to the third party and have their server app encrypt the data using the public key. To obtain public key, call the REST Configuration API from an admin ip, for example, by running cURL command
    curl -X GET 'http://localhost:3000/api/configurations?filter=%7B%22where%22%3A%20%7B%22name%22%3A%20%22rsa%22%7D%7D'
diff --git a/preview/docs/config-sms/index.html b/preview/docs/config-sms/index.html
index 2ccbdf9c9..c6f1f16b0 100644
--- a/preview/docs/config-sms/index.html
+++ b/preview/docs/config-sms/index.html
@@ -24,7 +24,7 @@
     
     SMS | NotifyBC
     
-    
+    
   
   
     
     SMS
     Provider
    NotifyBC depends on underlying SMS service providers to deliver SMS messages. The supported service providers are
    Only one service provider can be chosen per installation. To change service provider, add following config to file /src/config.local.js
    module.exports = {
diff --git a/preview/docs/config-subscription/index.html b/preview/docs/config-subscription/index.html
index bb019ddb6..aee5aef97 100644
--- a/preview/docs/config-subscription/index.html
+++ b/preview/docs/config-subscription/index.html
@@ -24,7 +24,7 @@
     
     Subscription | NotifyBC
     
-    
+    
   
   
     
     Subscription
    Configs in this section customize behavior of subscription and unsubscription workflow. They are all sub-properties of config object subscription. This object can be defined as service-agnostic static config as well as service-specific dynamic config, which overrides the static one on a service-by-service basis. Default static config is defined in file /src/config.ts. There is no default dynamic config.
    To customize static config, create the config object subscription in file /src/config.local.js
    module.exports = {
diff --git a/preview/docs/quickstart/index.html b/preview/docs/quickstart/index.html
index 2902a8235..127be7b6a 100644
--- a/preview/docs/quickstart/index.html
+++ b/preview/docs/quickstart/index.html
@@ -24,7 +24,7 @@
     
     Quick Start | NotifyBC
     
-    
+    
   
   
     
     Quick Start
    For the impatient, here's how to get a boilerplate NotifyBC instance up and running if you have git and node.js installed:
    git clone https://github.com/bcgov/NotifyBC.git
diff --git a/preview/docs/shared/filterQueryParam.html b/preview/docs/shared/filterQueryParam.html
index 880f50cf5..16bc4d3cc 100644
--- a/preview/docs/shared/filterQueryParam.html
+++ b/preview/docs/shared/filterQueryParam.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
    a filter containing properties where, fields, order, skip, and limit
    - parameter name: filter
diff --git a/preview/docs/shared/filterQueryParamCode.html b/preview/docs/shared/filterQueryParamCode.html
index c4ba9e172..ceac2fc17 100644
--- a/preview/docs/shared/filterQueryParamCode.html
+++ b/preview/docs/shared/filterQueryParamCode.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
diff --git a/preview/docs/shared/filterQueryParamExample.html b/preview/docs/shared/filterQueryParamExample.html
index ccef0791c..59239fbfd 100644
--- a/preview/docs/shared/filterQueryParamExample.html
+++ b/preview/docs/shared/filterQueryParamExample.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
    the value of the filter query parameter is URL-encoded stringified JSON object
    ```json
diff --git a/preview/docs/shared/jmespathFilter.html b/preview/docs/shared/jmespathFilter.html
index 7b42dfcea..f8074e76b 100644
--- a/preview/docs/shared/jmespathFilter.html
+++ b/preview/docs/shared/jmespathFilter.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
      <div class="description">a string conforming to jmespath <a href="http://jmespath.org/specification.html#filter-expressions">filter expressions syntax</a> after the question mark (?). The filter is matched against the <i><a href="../api-subscription#data">data</a></i> field of the subscription. Examples of filter
diff --git a/preview/docs/shared/whereQueryParam.html b/preview/docs/shared/whereQueryParam.html
index e6107edc6..8635a5b8f 100644
--- a/preview/docs/shared/whereQueryParam.html
+++ b/preview/docs/shared/whereQueryParam.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
    a where query parameter with value conforming to MongoDB Query Documentsopen in new window
    - parameter name: where
diff --git a/preview/docs/shared/whereQueryParamCode.html b/preview/docs/shared/whereQueryParamCode.html
index f4a4fac3a..8a71063f4 100644
--- a/preview/docs/shared/whereQueryParamCode.html
+++ b/preview/docs/shared/whereQueryParamCode.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
diff --git a/preview/docs/shared/whereQueryParamExample.html b/preview/docs/shared/whereQueryParamExample.html
index 975db0252..2bcff275d 100644
--- a/preview/docs/shared/whereQueryParamExample.html
+++ b/preview/docs/shared/whereQueryParamExample.html
@@ -24,7 +24,7 @@
     
     NotifyBC
     
-    
+    
   
   
     
    the value of the where query parameter is URL-encoded stringified JSON object
    ```json
diff --git a/preview/docs/upgrade/index.html b/preview/docs/upgrade/index.html
index 14b9222ab..1a4428b44 100644
--- a/preview/docs/upgrade/index.html
+++ b/preview/docs/upgrade/index.html
@@ -24,7 +24,7 @@
     
     Upgrade Guide | NotifyBC
     
-    
+    
   
   
     
     Upgrade Guide
     v1 to v2
    Upgrading NotifyBC from v1 to v2 involves two steps
    1. Update your client code if needed
    2. Upgrade NotifyBC server
     Update your client code
    NotifyBC v2 introduced backward incompatible API changes documented in the rest of this section. If your client code will be impacted by the changes, update your code to address the incompatibility first.
     Query parameter array syntax
    In v1 array can be specified in query parameter using two formats
    1. by enclosing array elements in square brackets such as &additionalServices=["s1","s2] in one query parameter
    2. by repeating the query parameters, for example &additionalServices=s1&additionalServices=s2
    In v2 only the latter format is supported.
     Date-Time fields
    In v1 date-time fields can be specified in date-only string such as 2020-01-01. In v2 the field must be specified in ISO 8601 extended format such as 2020-01-01T00:00:00Z.
     Return status codes
    HTTP response code of success calls to following APIs are changed from 200 to 204
     Administrator API
     Upgrade NotifyBC server
    The procedure to upgrade from v1 to v2 depends on how v1 was installed.
     Source-code Installation
    1. Stop NotifyBC
    2. Backup app root and database!
    3. Make sure current branch is tracking correct remote branch
      git remote set-url origin https://github.com/bcgov/NotifyBC.git
diff --git a/preview/docs/web-console/index.html b/preview/docs/web-console/index.html
index fc43c0d52..d0767ea89 100644
--- a/preview/docs/web-console/index.html
+++ b/preview/docs/web-console/index.html
@@ -24,7 +24,7 @@
     
     Web Console | NotifyBC
     
-    
+    
   
   
     
       Web Console
      After installing NotifyBC, you can start exploring NotifyBC resources by opening web console, a curated GUI, at http://localhost:3000open in new window. You can further explore full-blown APIs by clicking the API explorer Swagger UI embedded in web console.
      Consult the API docs for valid inputs and expected outcome while you are exploring the APIs. Once you are familiar with the APIs, you can start writing code to call the APIs from either user browser or from a server application.
      What you see in web console and what you get from API calls depend on how your requests are authenticated.
       Ip whitelisting authentication
      The API calls you made with API explorer as well as API calls made by web console from localhost are by default authenticated as super-admin requests because localhost is in admin ip list by default. Ip whitelisting authentication status is indicated by the verified_user icon on top right corner of web console.
      To see the result of non super-admin requests, you can choose one of the following methods
      • customize admin ip list to omit localhost (127.0.0.1)
      • access web console from another ip not in the admin ip list
       Client certificate authentication
      If your ip is not in the admin ip list but you have setup a client certificate issued by NotifyBC server in browser, the API calls you made with API explorer as well as API calls made by web console are also authenticated as super-admin requests. Client certificate authentication status is indicated by the verified icon on top right corner of web console.
       Anonymous
      If you access web console from a client that is not in the admin ip list, you are by default anonymous user. Anonymous authentication status is indicated by the LOGINlogin button on top right corner of web console. Click the button to login.
       Access token authentication
      If you have not configured OIDC, the login button opens a login form. After successful login, the login button is replaced with the Access Token text field on top right corner of web console. You can edit the text field. If the new access token you entered is invalid, you are essentially logging yourself out. In such case Access Token text field is replaced by the LOGINlogin button.
      The procedure to create an admin login account is documented in Administrator API
      Tokens are not shared between API Explorer and web console
      Despite API Explorer appears to be part of web console, it is a separate application. At this point neither the access token nor the OIDC access token are shared between the two applications. You have to use API Explorer's Authorize button to authenticate even if you have logged into web console.
       OIDC authentication
      If you have configured OIDC, then the login button will direct you to OIDC provider's login page. Once login successfully, you will be redirected back to NoitfyBC web console. OIDC authentication status is indicated by the LOGOUTlogout button.
      If you passed isAdmin validation, you are admin; otherwise you are authenticated user.
       SiteMinder authentication
      To get results of a SiteMinder authenticated user, do one of the following
      • access the API via a SiteMinder proxy if you have configured SiteMinder properly
      • use a tool such as curl that allows to specify custom headers, and supply SiteMinder header SM_USER:
      curl -X GET --header "Accept: application/json" \
diff --git a/preview/docs/what's-new/index.html b/preview/docs/what's-new/index.html
index 0599a337f..40cf83258 100644
--- a/preview/docs/what's-new/index.html
+++ b/preview/docs/what's-new/index.html
@@ -24,7 +24,7 @@
     
     What's New | NotifyBC
     
-    
+    
   
   
     
       What's New
      NotifyBC uses semantic versioningopen in new window.
       v5.0.0
      See Upgrade Guide for more information.
      • Runs on Nest
      Why v5?
      NotifyBC was built on Node.js LoopBackopen in new window in the beginning. While Loopback is an awesome framework, it is evident by 2022 Loopback is no longer actively maintained
      1. features such as GraphQL have been in experimental state for years
      2. recent commits are mostly chores rather than enhancements
      3. core developers have ceased to contribute
      To pave the way for future growth, switching platform becomes necessary. Nest was chosen because
      1. both Nest and Loopback are server-side Node.js frameworks
      2. Nest has the closest feature set as Loopback. To a large extent Nest is a superset of Loopback.
      3. Nest incorporates more technologies
       v4.1.0
      • Issue #50open in new window: Email message throttle
      • applied sms throttle to all sms messages rather than just broadcast push notification.
      • docs updates
       v4.0.0
      See v3 to v4 upgrade guide for more information.
      • Issue #48open in new window: SMS message throttle
      • Re-ordered config file precedence
      • Re-organized Email and SMS configs
      • docs updates
       v3.1.0
      • Issue #45open in new window: Reliability - Log skipped dispatches for broadcast push notifications
      • docs updates
       v3.0.0
      See v2 to v3 upgrade guide for more information.
       v2.9.0
       v2.8.0
       v2.7.0
       v2.6.0
      • Helm chart updates
      • docs updates
       v2.5.0
       v2.4.0
      • Issue #16open in new window: Support client certificate authentication
      • misc web console adjustments
      • docs updates
       v2.3.0
      • Issue #15open in new window: Support OIDC authentication for both admin and non-admin user
      • misc web console adjustments
      • docs updates
       v2.2.0
      • Issue #14open in new window: Support Administrator login, changing password, obtain access token in web console
      • misc web console adjustments
      • docs updates
       v2.1.0
      • Issue #13open in new window: Upgraded Vuetify from v0.16.9 to v2.4.3
      • misc web console adjustments
      • docs updates
       v2.0.0
      See Upgrade Guide for more information.
      • Runs on LoopBack v4
      • All code is converted to TypeScript
      • Upgraded OASopen in new window from v2 to v3
      • Docs is converted from Jekyll to VuePress
      Why v2?
      NotifyBC has been built on Node.js LoopBackopen in new window framework since 2016. LoopBack v4, which was released in 2019, is backward incompatible. To keep software stack up-to-date, unless rewriting from scratch, it is necessary to port NotifyBC to LoopBack v4. Great care has been taken to minimize upgrade effort.