Rework UrlUtil handle to avoid crashes while converting URI to URL #6031
Conversation
| // assertEquals("https://example.com:8123/https:/example.com/path", result.toString()) | ||
| assertEquals("https://example.com:8123/path", result.toString()) |
There was a problem hiding this comment.
@jpelgrom could you check this test in particular? The comments are from Claude and I didn't want to apply his suggestion until we discuss it. Which are to test the isAbsolute onto the normalizedInput instead of the input.
There was a problem hiding this comment.
Nice find, I suppose.
It is supposed to be a custom URI scheme specifically to be used for creating a URL relative to your Home Assistant server, which is needed because your base URL may change (internal/external). Always treating it as relative therefore makes the most sense to me.
The current check does that, indirectly (homeassistant protocol != http(s), so not absolute). After thinking about it, I'd probably keep it as it is right now because:
- changing it to check the normalized input does mean that weird input like here can end up being treated like a absolute url, which is explicitly not intended
- we have a custom scheme so can simply say it's not supported (and HA doesn't have paths like this)
- checking it as absolute may also makes it easier to have a redirect attack (external app opens LinkActivity with
homeassistant://navigate/a; currently you end up on your server, and we have checks to get out of the WebViewActivity if the host is different, but why risk it?)
There was a problem hiding this comment.
I've updated the test to remove the comments and make the title more explicit.
Test Results 92 files 1 errors 91 suites 10m 38s ⏱️ For more details on these parsing errors, see this check. Results for commit 381c316. ♻️ This comment has been updated with latest results. |
|
Test reporting are failing because the XML contains all the logs when the tests are running and it's too big for the tool we use to proceed. |
Summary
While looking at Sentry crashes I found out that there was a case not handled by the
handlefunction inUrlUtil, where a string likehttp://h:8123Nonecan be parsed as a URI but then.toURLwould crash withNumberFormatException.To fix this I've asked Claude to first generate a set of tests, to be able to reproduce the issue (it was not trivial to found a case that triggers the issue from the crash only).
Then once identified I took the liberty to change the implementation with more details.
Checklist