Filing this for documentation rather than because it's currently causing visible breakage — we found it while investigating the pathEvaluator 404 (#1781), and it's been masked by that. It may surface for a wider audience once the 404 is resolved.
In resources/lib/services/nfsession/session/http_requests.py, _prepare_request_properties():
pythonif endpoint_conf['add_auth_url'] == 'to_data':
auth_data = f'authURL={self.auth_url}'
data_converted += f'&{auth_data}' if data_converted else auth_data
The token is concatenated raw into a body sent with Content-Type: application/x-www-form-urlencoded. authURL values are base64-flavoured and routinely contain /, +, and =. Under form-urlencoded semantics + decodes to a space, and = is a key/value separator — so tokens containing those characters can be misparsed server-side.
Observed live token, sent unencoded by the add-on:
authURL=c1.1783613302031.AgiMlOvcAxIgfrhrIu74ixG9/j4al9j5omq6W5qEhw9FabWmYnOG840YAg==
The web client percent-encodes it:
authURL=c1.1783613302031.AgiMlOvcAxIgfrhrIu74ixG9%2Fj4al9j5omq6W5qEhw9FabWmYnOG840YAg%3D%3D
Because it depends on which characters a given token happens to contain, and tokens rotate, any resulting failures would be intermittent and hard to reproduce — the sort of thing that looks like a flaky network.
Suggested fix:
pythonfrom urllib.parse import quote
...
auth_data = 'authURL=' + quote(self.auth_url, safe='')
The to_params branch is unaffected — requests encodes params itself.
We have not observed a confirmed failure attributable to this; the 404 in #1781 fails first. Documenting it in case it matters later.
Environment: 1.23.5+matrix.1, LibreELEC, Kodi 21.
Filing this for documentation rather than because it's currently causing visible breakage — we found it while investigating the pathEvaluator 404 (#1781), and it's been masked by that. It may surface for a wider audience once the 404 is resolved.
In resources/lib/services/nfsession/session/http_requests.py, _prepare_request_properties():
pythonif endpoint_conf['add_auth_url'] == 'to_data':
auth_data = f'authURL={self.auth_url}'
data_converted += f'&{auth_data}' if data_converted else auth_data
The token is concatenated raw into a body sent with Content-Type: application/x-www-form-urlencoded. authURL values are base64-flavoured and routinely contain /, +, and =. Under form-urlencoded semantics + decodes to a space, and = is a key/value separator — so tokens containing those characters can be misparsed server-side.
Observed live token, sent unencoded by the add-on:
authURL=c1.1783613302031.AgiMlOvcAxIgfrhrIu74ixG9/j4al9j5omq6W5qEhw9FabWmYnOG840YAg==
The web client percent-encodes it:
authURL=c1.1783613302031.AgiMlOvcAxIgfrhrIu74ixG9%2Fj4al9j5omq6W5qEhw9FabWmYnOG840YAg%3D%3D
Because it depends on which characters a given token happens to contain, and tokens rotate, any resulting failures would be intermittent and hard to reproduce — the sort of thing that looks like a flaky network.
Suggested fix:
pythonfrom urllib.parse import quote
...
auth_data = 'authURL=' + quote(self.auth_url, safe='')
The to_params branch is unaffected — requests encodes params itself.
We have not observed a confirmed failure attributable to this; the 404 in #1781 fails first. Documenting it in case it matters later.
Environment: 1.23.5+matrix.1, LibreELEC, Kodi 21.