| Auto-Submit | +1 |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool _isAllowedHost(String hostHeader, DartRuntimeService frontend) {nit: Could some of this be made shareable with `isAllowedOrigin`?
uri.host == '::1') {Is this vs the other impl of `_isAllowedOrigin` accepted - or are they equivalent? I'm not too familiar with the '::1' shorthand syntax.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
bool _isAllowedHost(String hostHeader, DartRuntimeService frontend) {nit: Could some of this be made shareable with `isAllowedOrigin`?
Done
Is this vs the other impl of `_isAllowedOrigin` accepted - or are they equivalent? I'm not too familiar with the '::1' shorthand syntax.
These are equivalent. `::1` is the IPv6 equivalent of `127.0.0.1` 😊
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool _isAllowedHost(String hostHeader, DartRuntimeService frontend) {Needs a doc comment. What formatting is expected in this String?
uri = Uri.parse('http://$hostHeader');Is adding the scheme here needed? It isn't used in any way right?
/// Shelf middleware to validate Host and Origin headers to prevent
/// DNS-rebinding and CSRF attacks.This isn't a well formed doc comment. It should read more like a description of what it does with the inputs and what is returned.
// No origin sent. This is a non-browser client or a same-origin request.
// Since we already validated the Host header, we know it's a legitimate
// local same-origin request (or a local non-browser tool).nit: line length
// scheme (http:// or https://), and we prepend one when validating Host headers.nit: line length
// Host header might not have a scheme, so prepend http:// to parse it as an origin.nit: line length
{
final request = await client.getUrl(serverUri.resolve('api/ping'));
final response = await request.close();
expect(response.statusCode, HttpStatus.ok);
await response.drain();
}Is this block pattern common? I haven't really seen it much. Is it just ensuring various bits don't leak between expectations? Should these actually be seperate test cases?
// Bad Host Header (should be ALLOWED -> 200 OK because checks are disabled)nit: line length
// Bad Origin Header to /api/sse (should be ALLOWED -> not 403, though it might fail with 400/404 because of invalid SSE handshake)nit: line length
// 1. Legitimate GET request to DDS-handled path (should return 404 Not Found, but NOT 403)nit: line length
{
final request = await client.getUrl(dds.uri!.resolve('devtools'));
final response = await request.close();
expect(response.statusCode, HttpStatus.notFound);
await response.drain();
}ditto for these blocks too.
// Bad Host Header (should be ALLOWED -> 404 because DevTools not served, but not 403)nit: line length
final securityTests = <IsolateTest>[Is this a list of one test? Should we separate them too?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
bool _isAllowedHost(String hostHeader, DartRuntimeService frontend) {Needs a doc comment. What formatting is expected in this String?
Done
uri = Uri.parse('http://$hostHeader');Is adding the scheme here needed? It isn't used in any way right?
It's needed so `localhost:8080` doesn't result in `localhost` being interpreted as the scheme for the URI.
/// Shelf middleware to validate Host and Origin headers to prevent
/// DNS-rebinding and CSRF attacks.This isn't a well formed doc comment. It should read more like a description of what it does with the inputs and what is returned.
Done
// No origin sent. This is a non-browser client or a same-origin request.
// Since we already validated the Host header, we know it's a legitimate
// local same-origin request (or a local non-browser tool).Ben Konyinit: line length
Done
// scheme (http:// or https://), and we prepend one when validating Host headers.Ben Konyinit: line length
Done
// Host header might not have a scheme, so prepend http:// to parse it as an origin.Ben Konyinit: line length
Done
final request = await client.getUrl(serverUri.resolve('api/ping'));
final response = await request.close();
expect(response.statusCode, HttpStatus.ok);
await response.drain();
}Is this block pattern common? I haven't really seen it much. Is it just ensuring various bits don't leak between expectations? Should these actually be seperate test cases?
Yeah, these should be separate test cases. Done.
// Bad Host Header (should be ALLOWED -> 200 OK because checks are disabled)Ben Konyinit: line length
Done
// Bad Origin Header to /api/sse (should be ALLOWED -> not 403, though it might fail with 400/404 because of invalid SSE handshake)Ben Konyinit: line length
Done
// 1. Legitimate GET request to DDS-handled path (should return 404 Not Found, but NOT 403)Ben Konyinit: line length
Done
final request = await client.getUrl(dds.uri!.resolve('devtools'));
final response = await request.close();
expect(response.statusCode, HttpStatus.notFound);
await response.drain();
}ditto for these blocks too.
Done
// Bad Host Header (should be ALLOWED -> 404 because DevTools not served, but not 403)Ben Konyinit: line length
Done
Is this a list of one test? Should we separate them too?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |