Add defra-user-id header to legacy requests #796
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/WATER-4375 > Part of a series of changes related to replacing the create bill run journey to incorporate changes for two-part tariff If we are to take over the create bill run journey it means _we_ are now responsible for triggering legacy bill runs rather than vice versa. That means we need to trigger the [water-abstraction-service](https://github.com/DEFRA/water-abstraction-service) `POST /water/1.0/billing/batches` endpoint. Simple, we thought! We already have `LegacyRequestLib` that adds support for talking to the other services from our project. That was until we kept getting `403` errors. After some digging we found the cause. Just like in our project and [water-abstraction-ui](https://github.com/DEFRA/water-abstraction-ui) some of the internal legacy services also have an authorization strategy that applies [scope](https://hapi.dev/api/?v=21.3.3#-routeoptionsauthaccessscope) to their routes. We authenticate with them using the shared JWT token the previous team left behind. But that is not enough for those routes which have, for example, 'billing' configured as their authorization scope. They expect the legacy UI to also let them know who the user is behind the request being made so they can confirm they have authorization to do that 'thing'. As this has already been checked by the UI it is pointless and wasteful. But it is what it is! **water-abstraction-service** for example appears to have a couple of strategies; decoding the user email from the JWT token being one of them. But we suspect this was abandoned in favour of adding the user's `userId` as a header in the request. If the header exists, the downstream service will extract the ID from it, make a call to [water-abstraction-tactical-idm](https://github.com/DEFRA/water-abstraction-tactical-idm) and then confirm the user and their scope. If they match the request is accepted. All this means we need to update our `LegacyRequestLib` to support adding the `defra-internal-user-id` header to requests that need it.
Cruikshanks
added a commit
that referenced
this pull request
Mar 26, 2024
https://eaflood.atlassian.net/browse/WATER-4375 Recently we extended the functionality of our code that manages sending requests to the legacy services to [Add defra-user-id header to legacy requests](#796). This is in preparation of us managing the setup bill run process as part of changes we're doing to support two-part tariff. Some of the legacy endpoints expect the header and use it to authorize the request being made. When we did this we overlooked the requests being made in `app/services/health/info.service.js`. The calls it was making told our logic to send the requests to the base domains for each legacy service, for example, `http://localhost:8001`. But because of the new param and a change in their order, this was being received as the user ID arg. So, we broke a number of the requests. 🤦 This change fixes the requests being made in `InfoService`.
Cruikshanks
added a commit
that referenced
this pull request
Mar 26, 2024
https://eaflood.atlassian.net/browse/WATER-4375 Recently we extended the functionality of our code that manages sending requests to the legacy services to [Add defra-user-id header to legacy requests](#796). This is in preparation for us managing the setup bill run process as part of changes we're doing to support two-part tariff. Some of the legacy endpoints expect the header and use it to authorize the request being made. When we did this we overlooked the requests being made in `app/services/health/info.service.js`. The calls it was making told our logic to send the requests to the base domains for each legacy service, for example, `http://localhost:8001`. But because of the new param and a change in their order, this was being received as the user ID arg. So, we broke a number of the requests. 🤦 This change fixes the requests being made in `InfoService`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-4375
If we are to take over the create bill run journey it means we are now responsible for triggering legacy bill runs rather than vice versa. That means we need to trigger the water-abstraction-service
POST /water/1.0/billing/batchesendpoint.Simple, we thought! We already have
LegacyRequestLibthat adds support for talking to the other services from our project. That was until we kept getting403errors. After some digging, we found the cause.Just like in our project and water-abstraction-ui some of the internal legacy services also have an authorization strategy that applies scope to their routes. We authenticate with them using the shared JWT token the previous team left behind. But that is not enough for those routes which have, for example, 'billing' configured as their authorization scope.
They expect the legacy UI to also let them know who the user is behind the request being made so they can confirm they have authorization to do that 'thing'. As this has already been checked by the UI it is pointless and wasteful. But it is what it is!
water-abstraction-service for example appears to have a couple of strategies; decoding the user email from the JWT token being one of them. But we suspect this was abandoned in favour of adding the user's
userIdas a header in the request.If the header exists, the downstream service will extract the ID from it, make a call to water-abstraction-tactical-idm and then confirm the user and their scope. If they match the request is accepted.
All this means we need to update our
LegacyRequestLibto support adding thedefra-internal-user-idheader to requests that need it.