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

4.0.0 Release Notes #62

Closed
kanongil opened this issue May 9, 2016 · 0 comments
Closed

4.0.0 Release Notes #62

kanongil opened this issue May 9, 2016 · 0 comments
Assignees
Milestone

Comments

@kanongil
Copy link
Member

@kanongil kanongil commented May 9, 2016

Summary

The 4.0.0 release is a breaking change, mainly due to updated code syntax that relies on ES6 features that aren't supported in node v0.10.

This release also introduces a new security feature that is intended to prevent accidentally exposing private files on your server. The previous releases allowed any file to be served, which when combined with a non-sanitized path to reply.file(), can potentially return any file on the server.

  • Upgrade time: low to medium - no code changes required for many cases.
  • Complexity: medium - non-standard path usage can have new runtime behavior.
  • Risk: moderate - some files might not be served as expected.
  • Dependencies: none

Breaking Changes

  • Node v0.10 is no longer supported.
  • Directly serving files outside the files.relativeTo path returns a 403 response instead of the file contents.

New Features

  • New confine security option to control file system access restrictions.

Updated Dependencies

  • ammo from 1.x to 2.x
  • boom from 2.x to 3.x
  • hoek from 2.x to 4.x
  • items from 1.x to 2.x
  • joi from 6.7.x to 8.x
  • lru-cache from 2.7.x to 4.0.x

Migration

Files that would previously be returned successfully can now respond with a Boom.forbidden / 403 code instead of served outside the files.relativeTo directory. To fix this for the file handler and reply.file() method:

  • Ensure that the path being served is within the files.relativeTo directory.
  • Alternatively, specify the confine option with a suitable base path.
  • As a last resort, you can use the confine: false option to disable this security feature.

For the directory handler, no changes are necessary unless you rely on serving files outside the directory pointed to by the path option. In this case you need to reconsider the security implications of what you are doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.