-
Notifications
You must be signed in to change notification settings - Fork 69
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
Trailing slash map backtracking #207
Comments
This comment has been minimized.
This comment has been minimized.
Thanks, yes, corrected. |
To clarify: are all of the following imports to be rejected in the example above? Or should only the last one be rejected?
(I assumed the former, because |
Yes exactly, all the cases there would be rejected. In Node.js, we do the full URL resolution, then just have a secondary check that the resolved URL is contained within the resolved target subpath and fail then if it isn't. We do also have added protections there aren't URI-encoded |
Closes #207. Also changes the error message suggestion for a nearby case to be more helpful and accurate.
Closes #207. Also changes the error message suggestion for a nearby case to be more helpful and accurate.
As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1
As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1
Reflecting WICG/import-maps#229 Bug: 848607, WICG/import-maps#207 Change-Id: Id056b3fd27489ecdfe45456220fd1d8c01dc8d3f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2570012 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#833945}
As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#835824}
As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#835824}
As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#835824}
…aracters, a=testonly Automatic update from web-platform-tests [Import Maps] Add tests for non-ASCII characters As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#835824} -- wpt-commits: 2a8e0914a294d617a10f2987b8927d92e1b918a4 wpt-pr: 26753
…aracters, a=testonly Automatic update from web-platform-tests [Import Maps] Add tests for non-ASCII characters As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshigechromium.org> Reviewed-by: Kouhei Ueno <kouheichromium.org> Reviewed-by: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/master{#835824} -- wpt-commits: 2a8e0914a294d617a10f2987b8927d92e1b918a4 wpt-pr: 26753 UltraBlame original commit: a6b88a2c38696af65658c05170df52f6179cc6e9
…aracters, a=testonly Automatic update from web-platform-tests [Import Maps] Add tests for non-ASCII characters As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshigechromium.org> Reviewed-by: Kouhei Ueno <kouheichromium.org> Reviewed-by: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/master{#835824} -- wpt-commits: 2a8e0914a294d617a10f2987b8927d92e1b918a4 wpt-pr: 26753 UltraBlame original commit: a6b88a2c38696af65658c05170df52f6179cc6e9
…aracters, a=testonly Automatic update from web-platform-tests [Import Maps] Add tests for non-ASCII characters As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshigechromium.org> Reviewed-by: Kouhei Ueno <kouheichromium.org> Reviewed-by: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/master{#835824} -- wpt-commits: 2a8e0914a294d617a10f2987b8927d92e1b918a4 wpt-pr: 26753 UltraBlame original commit: a6b88a2c38696af65658c05170df52f6179cc6e9
…aracters, a=testonly Automatic update from web-platform-tests [Import Maps] Add tests for non-ASCII characters As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#835824} -- wpt-commits: 2a8e0914a294d617a10f2987b8927d92e1b918a4 wpt-pr: 26753
Reflecting WICG/import-maps#229 Bug: 848607, WICG/import-maps#207 Change-Id: Id056b3fd27489ecdfe45456220fd1d8c01dc8d3f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2570012 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#833945} GitOrigin-RevId: 916cc2354cae22a6e8280f2a2b7ac66b30b99e67
As the non-bare keys and resolution results of specifier maps are normalized (i.e. serialized URLs), raw and percent-encoded non-ASCII strings are considered equal (as both of them are percent-encoded after serialization). This CL tests that raw and percent-encoded versions of non-ASCII characters are: - Considered equal in non-bare specifier keys, - Considered equal in checking backtracking, and - Not considered equal in bare specifier keys. For consistency, this CL also adds some backtracking tests that don't involve non-ASCII characters but use the same patterns of added non-ASCII tests. Bug: 848607, WICG/import-maps#207 Change-Id: I6c8ae478da2fcbe0f6df03a608dabdad60644ea1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2573422 Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Cr-Commit-Position: refs/heads/master@{#835824} GitOrigin-RevId: 4c3b260eb060addaca84e6b325c673f834e7be4c
In the Node.js modules group work on exports, which in many ways shares similiarities with import maps resolution, we've explicitly added some validation to ensure that mappings cannot be back tracked - effectively that
import 'mapped/path/../../../backtrack'
will throw when backtracking below the target mapping's trailing slash base path.For the example case:
the validation step is basically just to check that any resolution using this imports, after applying the full URL resolution also goes through a check that
resolved.startsWith(targetPathWithTrailingSlash)
, and if not to throw a validation error.For Node.js package isolation can be still worked around using absolute URLs, but providing this level of encapsulation makes it more obvious to users that private modules should be private.
Whether that same level of encapsulation encouragement is important to import maps is a question worth considering though, so I thought I would bring it up at least.
The text was updated successfully, but these errors were encountered: