-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial development tools #1097
Conversation
fbc67b2
to
600b511
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
600b511
to
fa52596
Compare
@@ -104,6 +104,8 @@ module.exports = { | |||
}, | |||
ENABLE_COMPONENTS_LIBRARY: | |||
IS_DEV || /true/i.test(process.env.ENABLE_COMPONENTS_LIBRARY), | |||
ENABLE_DEVELOPMENT_TOOLS: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way we could ensure that this could never be set on production. (ie. currently, a naughty person with access could add the env var to the k8s config and simply apply it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any environment variable is susceptible to that sort of manipulation.
Best option I can think of involves denying this path in the ingress configuration.
Only other two options I can think off are either not including this module in our production builds, which is not a great solution, because then what is staging actually representing. Alternatively, if this was a separate microservice stitched together at the Ingress layer we wouldn't need to worry about this - but that's effectively the same as denying it at that later anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did also toy with this but the reason I created the env was to actually potentially allow it on some "production-like" environments like Heroku or Staging.
I think some of the tools we may add to this will be useful in those environments, like pre-filling a PER.
However, you're right that this does potentially open up security concerns if things like permissions can be manipulated.
Maybe it is safer at this stage that it can only be done in development environments and we remove support for the environment variable altogether.
@merlinc's suggestion is also something we thought about with the original development only middleware. We could potentially add a npm task that cleans up after a deploy to remove such files?
@@ -104,6 +104,8 @@ module.exports = { | |||
}, | |||
ENABLE_COMPONENTS_LIBRARY: | |||
IS_DEV || /true/i.test(process.env.ENABLE_COMPONENTS_LIBRARY), | |||
ENABLE_DEVELOPMENT_TOOLS: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any environment variable is susceptible to that sort of manipulation.
Best option I can think of involves denying this path in the ingress configuration.
Only other two options I can think off are either not including this module in our production builds, which is not a great solution, because then what is staging actually representing. Alternatively, if this was a separate microservice stitched together at the Ingress layer we wouldn't need to worry about this - but that's effectively the same as denying it at that later anyway.
@@ -0,0 +1,27 @@ | |||
const { uniq } = require('lodash') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_development-tools
does not thrill me, however it does make it obvious that its a "non-functional requirement" module.
Only alternative to this I can think of is ripping this out as a separate npm module
and including it that way - but I think it's too early for us to know what that would look like just yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, it didn't thrill me either...I also toyed with ./dev
, ./development-only
, ./_tools
....the prefix sort of helped set it out above the rest of the "real" apps. But maybe that's not necessary as we don't do that with the component app which is only available in dev or on certain environments.
What about simple ./tools
?
config/nunjucks/globals.js
Outdated
FEEDBACK_URL, | ||
PERSON_ESCORT_RECORD_FEEDBACK_URL, | ||
SUPPORT_EMAIL, | ||
} = require('../') | ||
const { | ||
mountpath: toolsUrl, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a path, not a full url
}) | ||
} | ||
|
||
function updatePermissions(req, res) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future enhancement idea - supporting updating by both form and JSON.
We used this on session injection to give humans an easy form, but then used the JSON updating as a more reliable approach for automated browser tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that's a really nice idea! Nothing preventing us extending this to support a JSON body, or in fact just a POST
within the e2e tests?
@@ -39,7 +39,8 @@ | |||
| LOCATIONS_BATCH_SIZE | Maximum number of location IDs to send in one request when requesting moves for all locations | 40 | | |||
| FRAMEWORKS_VERSION | Current [Book a secure move frameworks](https://github.com/ministryofjustice/hmpps-book-secure-move-frameworks/releases) version that the frontend will use to create new Person Escort Records or any other frameworks being used | latest supported version (see `@hmpps-book-secure-move-frameworks` in package.json) | | |||
| LOG_LEVEL | Level of logs to output | production: `error`, development: `debug` | | |||
| ENABLE_COMPONENTS_LIBRARY | Whether to enable the component library and allowed it to be browsed on this environment | false | | |||
| ENABLE_COMPONENTS_LIBRARY | Whether to enable the component library and allow it to be browsed on this environment | false | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
📚 ❤️
This could help address #804 |
This adds an app that is only enabled in development or using a particular environment variable to aid with development and testing.
This adds another link item to the footer to access the permissions switcher.
fa52596
to
0534347
Compare
Code Climate has analyzed commit 0534347 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (90% is the threshold). This pull request will bring the total coverage in the repository to 98.0% (0.0% change). View more on Code Climate. |
Proposed changes
What changed
This adds a sup-app that is only available when in development or enabled using an environment variable.
Why did it change
The first tool within this app allows the permissions to be set based on the roles that exist within the frontend application.
Screenshots
Checklists
Testing
Automated testing
Manual testing
Has been tested in the following browsers:
Environment variables
Other considerations
Commit messages with a
fix
orfeat
type are automatically used to generate the changelog andGitHub release notes during the release task. Please make sure they will read well on their own in a
summary of changes and that the commit body gives a more detailed description of those changes if necessary.