From 311b714a4f2934bdf80c4c8aeabf1e4aebdf4cf2 Mon Sep 17 00:00:00 2001 From: Alan Cruikshanks Date: Mon, 16 Oct 2023 10:42:33 +0100 Subject: [PATCH] Fix and rename Authentication plugin MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit https://eaflood.atlassian.net/browse/WATER-4085 In [Create authentication plugin](https://github.com/DEFRA/water-abstraction-system/pull/351) we added the ability to authenticate and authorise requests to **water-abstraction-system** using the same data the rest of the service relies on, and the cookie [water-abstraction-ui](https://github.com/DEFRA/water-abstraction-ui) will pass through. One of the nifty things in it was the use of [server.dependency()](https://hapi.dev/api/?v=21.3.2#-serverdependencydependencies-after). Currently, we rely on plugins being registered in a particular order to prevent catastrophe. What this PR tried to demonstrate was that using `server.dependency()` we could break the dependence on the order they are registered. We're now ready to enable authentication by default but when we tried with `server.auth.default('session')` we kept getting an error. Hapi kept telling us it didn't recognise that strategy. No matter where we made the call we got the error. When we removed the call to `server.dependency()` and re-ordered the plugins in `server.js` the error went away and default auth on our routes started working. Reading posts like [Handling plugin dependencies](https://hapipal.com/best-practices/handling-plugin-dependencies) highlights there is a lot to think about when it comes to remove the dependence on plugin registration order. If we were maintainers of a plugin, we would need to nail this. But as we are just registering our own for use solely in our own project it looks like considerable overhead and complexity we don't really need. If we screw up the order it becomes obvious pretty quickly something is broken. So, in this change we're going back to being not-clever with our plugins! 😁 On the second point, a re-read of the plugin and the associated service highlighted that these enable both authentication and authorisation in Hapi for our routes. Because of this we're going to rename everything to `auth` so if folks in the future are looking for authorisation related code they don't overlook the plugin and service.