Add Hapi yar session manager to the project

[Cruikshanks]

https://eaflood.atlassian.net/browse/WATER-4447

This is the first and key part in a series of changes to properly support 'flash' banner notifications in the project.

Yar adds session support to hapi

a persistent state across multiple browser requests using an iron encrypted cookie and server-side storage. yar tries to fit session data into a session cookie based on a configured maximum size. If the content is too big to fit, it uses server storage via the hapi plugin cache interface.

There are times we need to persist state across multiple browser requests. A common reason is when you need to take users through a journey before committing the change, for example, setting up a bill run.

We do not intend to use yar in these situations. We persist journeys using our SessionModel (check out app/controllers/bill-runs-setup.controller.js for an example). Most session managers like yar rely on creating a cookie. This will hold a session ID. Out-of-the-box they will also support you adding the rest of your session data to the cookie. But as it is common to 'blow' the cookie with too much data they will also support working with server-side storage.

The legacy code uses yar in conjunction with catbox-redis to store session data in Redis (the ID in the session is the ID for the record in Redis!) That's perfect for high-volume sites and to be fair is considered 'the norm'. But it adds cost and complexity to our project that we just do not need. Hence we save 'journey' data to our PostgreSQL DB in the sessions table.

The other need for a session manager is when you want to display a one-off notification banner to a user. For example, they've performed an action that has resulted in a change to the record.

• A licence review is currently not 'in progress'
• The user clicks the 'Mark progress' button. This sends a POST request
• The server updates the licence review to 'in progress' and redirects to the licence review page (as per the PRG pattern
• The redirect causes a GET request which results in the server getting the updated record
• The licence review is displayed to the user

In this situation we want to display a banner to the user confirming a change was just made. The problem is there is nothing to tell the GET request that this is so. We could do the following

• Don't redirect but respond directly from the POST
  • This breaks PRG which you'll see if you hit refresh. The browser will resend your POST request which might have unintended consequences
• Set a flag in the DB
  • You then have to add logic to the GET request to update the record and remove the flag. It is also storing something in the DB that we only care about from a UI/behaviour context
• Add a query string param
  • This can be seen by the user and feels a bit 'ick'. Also, it could be abused. There is nothing to stop users from adding the flag themselves to force the banner to appear. It also won't clear when the browser is refreshed.

We're not the first to encounter this problem. Hence why session cookies and yar exist. yar even has a feature specific to this use case.

• In the POST request call request.yar.flash('banner', 'This licence has been marked.')
• In the GET request call const [bannerMessage] = request.yar.flash('banner')

yar will store the message in the wrlsSession cookie. The call in the GET not only retrieves the value it also tells yar to delete it from the cookie. If the user hits refresh the second GET will find bannerMessage is null.

---

Note about multiple sessions

Unfortunately, adding yar to our service means there are now two session cookies. The legacy project being first means it gets 'dibs' on the default name 'session'. We did try to reuse the 'session' cookie. But you tell yar to use the server's cache instead of the cookie by setting its size to 0. This is how the legacy code has configured it which means any calls to set() or flash() result in nothing being persisted.

So, we create our own 'wrlsSession' cookie. The upside is we're not bound by the legacy cookie and when the time comes can drop it completely without additional work or adverse effects on the user.

[Jozzey]