Cannot reliably test against different IP addresses #26166
Comments
|
cc @web-platform-tests/wpt-core-team |
These tests might not live very long, depending on the outcome of the related issue: #26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd
These tests might not live very long, depending on the outcome of the related issue: #26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444}
These tests might not live very long, depending on the outcome of the related issue: #26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444}
These tests might not live very long, depending on the outcome of the related issue: web-platform-tests/wpt#26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444}
|
With some rare exceptions (e.g. mobile testing), tests are almost always served from localhost in an automated system (wpt.live is for manual testing only). To support private and public addresses from the infra side, we could bind additional IPs to a loopback device, which of course requires root permissions. I think we can do this on Taskcluster and Azure Pipelines, but not sure whether it's possible in each browser vendor's CI. There's also a slight complication here regarding the public IP -- we'd probably need to buy one to make sure it's never used for anything real. To redirect IP addresses to localhost from the browser side, we'd need to change each browser. In short, I think both approaches require an RFC to coordinate with browser vendors. |
|
Forgive my networking ignorance, but are the domains we bind to in If someone were to set a URL as those (via server-side substitution, e.g. using |
|
@stephenmcgruer: Yes. Anything bound to loopback (127.0.0.0/8) is considered to be a "local" endpoint, regardless of name. We look at the IP address associated with the socket, not at the domain. @Hexcles: An alternative could be to teach the test driver some new tricks to classify some IP addresses as local and others as public. That would put the burden on the browsers to do the categorization in some reasonable way, but it wouldn't be out of the question. |
|
I would personally lean towards a webdriver extension, since 'buying a public IP address' seems future-brittle, but in either case @Hexcles is correct and the next step is likely an RFC. Please feel free to pick your favorite solution to the problem and write up a short RFC with summary/details/risk sections, then browser vendors/etc can chime in :) |
|
Alright, thanks! I'll read up on webdriver and how we could leverage that, and come back with an RFC in hand :) |
…Platform Tests., a=testonly Automatic update from web-platform-tests [CORS-RFC1918] Initial addressSpace Web Platform Tests. These tests might not live very long, depending on the outcome of the related issue: web-platform-tests/wpt#26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444} -- wpt-commits: 6c6f4decce0e9dc5c526ac95d084380bb6f1133d wpt-pr: 26135
…Platform Tests., a=testonly Automatic update from web-platform-tests [CORS-RFC1918] Initial addressSpace Web Platform Tests. These tests might not live very long, depending on the outcome of the related issue: web-platform-tests/wpt#26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444} -- wpt-commits: 6c6f4decce0e9dc5c526ac95d084380bb6f1133d wpt-pr: 26135
Addresses issue web-platform-tests/wpt#26166.
Addresses issue web-platform-tests/wpt#26166.
Addresses issue web-platform-tests/wpt#26166.
Addresses issue web-platform-tests/wpt#26166.
|
#72 was merged, considering this fixed. |
These tests might not live very long, depending on the outcome of the related issue: web-platform-tests/wpt#26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444} GitOrigin-RevId: 92dddd32ed64130c7a5ddfa3bdf4aba28d06a034
These tests might not live very long, depending on the outcome of the related issue: web-platform-tests/wpt#26166. In the meantime, they serve to document the existing spec intent, and hopefully undergird discussions around address space inheritance. Bug: chromium:1138905, chromium:1138906, chromium:1134601 Change-Id: I7d8d0e7cf8e70cfdf3bdc044e748ee384f3418dd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2475875 Commit-Queue: Titouan Rigoudy <titouan@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#818444} Former-commit-id: 92dddd32ed64130c7a5ddfa3bdf4aba28d06a034
Hi there, I believe this issue deserves the
type:untestabletag but I am not empowered to tag it myself.CORS-RFC1918 is a spec aiming to prevent malicious public websites (e.g.
http://evil.com) from attacking users' devices on the local network (e.g. smart fridge) or companies' intranet services.It does so by partitioning IP addresses into 3 address spaces, ordered from most to least private:
See #26135 for an initial pass at introducing tests for this spec. As @mikewest pointed out in the review, it is currently impossible for tests to assert the address space from which they are loaded: on my machine they are served from localhost, but that is certainly not the case for https://wpt.live.
In full generality, testing this spec properly would require being able to load a web page from the local, private or public address spaces at will. This could be achieved by wptserve actually serving the data from localhost, a private or a public IP, or by fooling the test browser into believing that somehow.
The text was updated successfully, but these errors were encountered: