Skip to content
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

Adjustments to livereload to stop (timeout) in prod #216

Merged
merged 2 commits into from
Nov 10, 2020

Conversation

binarymist
Copy link
Collaborator

livereload causes timeout in Zap tests (and cypress by the sound of it) which causes tests to fail.

Most of the noise in this commit is from npm run precommit, but the important changes means we can add any environmental scripts (script tags) to the environment specific files only (see config/env/all.js for example). In the production environment file I've simply left the environmentalScripts array empty. Possibly we could do like wise in the test environment file as well, that would fix #207

These changes are essential (or at least no livereload) for purpleteam testing NodeGoat.

@lirantal
Copy link
Collaborator

@binarymist due to the code style changes (prettier) it's hard to find what are the actual updates here.
can you point them out?

@binarymist
Copy link
Collaborator Author

binarymist commented Oct 28, 2020

Hi @lirantal

Configuration

The livereload script tags scattered through the views have been moved into one place... now living in an array of environmentalScripts (currently the livereload is the only one) in the configuration. The environmentalScripts array in all.js contains the livereload script tag. In the future others can be added if required.
The production.js config specified an empty array of environmentalScripts, which means there are currently no environmental scripts to load if running in prod. This solves the livereload problem @rcowsill and myself have been having in a tidy way.

Routes

The routes simply pass the environmentalScripts as an object property through to their views and/or layouts. If you look at all the changes and do a [ctrl]+[f] environmentalScripts The only non prettyified changes are those that contain environmentalScripts, the res.render that applies them to the views and/or layours and the swapping of the script tags in the views and layouts for placeholders.

Views

Views and their owning layouts now contain a place holder for any environmental scripts.

  • No other logic has changed in this PR
  • I've tested all modified code paths in development and production and it does as expected
  • It's being used in production in anger as SUT for purpleteam

Thanks.

@binarymist
Copy link
Collaborator Author

How are we looking @lirantal, any other thoughts?

@lirantal
Copy link
Collaborator

lirantal commented Nov 3, 2020

Okie, happy to RSLGTM it - just a note in the future it would be easier and quicker to review with just the functional changes and code styles left out of it.

Copy link
Collaborator

@lirantal lirantal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RSLGTM based on Kim and Rob's input

@ckarande
Copy link
Member

ckarande commented Nov 4, 2020

@binarymist thanks for the PR. It is great that the PR solves challenges you and rob are facing.
I agree with @lirantal that it would be easier to review if code styling changes were kept separate.
Otherwise, changes look good to me. I am running the PR branch locally once for sanity test and I will merge it shortly.

@@ -13,5 +13,6 @@ module.exports = {
cookieSecret: "session_cookie_secret_key_here",
cryptoKey: "a_secure_key_for_crypto_here",
cryptoAlgo: "aes256",
hostName: "localhost"
hostName: "localhost",
environmentalScripts: ["<script src='//localhost:35729/livereload.js'></script>"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously the host name in script tag was derived as location.host || "localhost". I believe this was done to support development on cloud based IDEs where hostname is not localhost. Do you see any issues if we retain the same logic, instead of hardcoding it to localhost?

Copy link
Collaborator Author

@binarymist binarymist Nov 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any suggestions on how to defer the evaluation of location until it hits the browser?

Copy link
Collaborator Author

@binarymist binarymist Nov 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could have the environmentalScripts as an array that looks something like the following:

[{
  scriptTag: '<script src="//\`{{script.substitutions.loc}}\`:35729/livereload.js"></script>',
  substitutions: { loc: '${location.host || "localhost"}' } // No backticks so no eval.
}, {
  // Future scripts
}]

I'm not quite sure on the best way to get the environmentalScripts into the view yet, would need to play and see what's possible with the current templating lib. Ultimatly the script.substitutions.loc needs to slot into the scriptTag.

It's quite a bit of extra work, but what ever needs to be done.

Plausable @ckarande ?

Copy link
Contributor

@rcowsill rcowsill Nov 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use the same trick as the original livereload script block, ie make the environmentalScripts line:

environmentalScripts: [`<script>document.write("<script src='http://" + (location.host || "localhost").split(":")[0] + ":35729/livereload.js'></" + "script>");</script>`]

The document.write happens in the browser, injecting a script tag with the correct livereload.js URL.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yip, good thinking @rcowsill, I was over thinking it. Are you happy with Rob's suggestion @ckarande ? If so I'll make that tweak.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. perfect.

@binarymist
Copy link
Collaborator Author

binarymist commented Nov 5, 2020

Just thinking @ckarande and @lirantal, do you think it's worth updating the contributing guide?
In the past @ckarande has been quite insistant that any files involved in a PR must be linted before submitting. The contributing guide is also quite clear that this needs to be done up-front:

If sending PR, once code is ready to commit, run:

npm run precommit

Please resolve all jsHint errors before committing the code.

Based on these two points, I was fairly sure it needed to be done before committing. Updating the contributing guide would help to make sure this doesn't happen again.

@rcowsill
Copy link
Contributor

rcowsill commented Nov 5, 2020

@binarymist thanks for the PR. It is great that the PR solves challenges you and rob are facing.

I think this is a good change to make as it stops heroku deploys from including livereload by default. When this change is merged it'll do the same for production docker builds too.

Regarding #207, this is a partial fix as it only applies to production environment. As Kim mentioned, we'd also need to remove the livereload script from the test environment to cover Cypress runs in Travis. I still want to update the Cypress config to block requests to port 35729, as I don't think it makes sense to handle live reload during a test run.

@binarymist
Copy link
Collaborator Author

binarymist commented Nov 6, 2020

When this change is merged it'll do the same for production docker builds too.

I've been using a docker-composer.override.yml for that, but #215 would be a welcome change. It'd be one less line in my override.

Regarding #207, this is a partial fix as it only applies to production environment. As Kim mentioned, we'd also need to remove the livereload script from the test environment to cover Cypress runs in Travis.

If we simply add the following (taken directly from production.js) to the test.js config then it will resolve #207... yes @rcowsill ?

module.exports = {
   environmentalScripts: []
};

We could of course flip the script and have the livereload script only in the development.js config and have the empty environmentalScripts in all.js, which to me makes sense. What does everyone think? @ckarande @rcowsill @lirantal

@rcowsill
Copy link
Contributor

rcowsill commented Nov 6, 2020

We could of course flip the script and have the livereload script only in the development.js config and have the empty environmentalScripts in all.js, which to me makes sense.

That sounds good to me, livereload seems like a development-only feature.

@binarymist
Copy link
Collaborator Author

Everyone (@rcowsill, @ckarande @lirantal) happy?

@ckarande
Copy link
Member

ckarande commented Nov 10, 2020

@binarymist LGTM. Thanks for the solution and your patience :)

@lirantal @rcowsill Great feedback. As you both are already onboard with the changes, I am merging the PR.

@ckarande ckarande merged commit dcd2a1d into OWASP:master Nov 10, 2020
@binarymist binarymist deleted the livereload-refactor branch November 11, 2020 00:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

livereload.js making tests run slower
4 participants