Subsonic credentials with extended characters failure

[dlehammer]

Hi bonob gurus,

Symptom

When using Subsonic credentials with extended characters (~ UTF-8) the Sonos authorization flow completes successfully, but subsequent requests fail ala:

{
   "message":{
      "level":"debug",
      "data":"<?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"  xmlns:tns=\"http://www.sonos.com/Services/1.1\"><soap:Body><soap:Fault><faultcode>Client.LoginUnauthorized</faultcode><faultstring>Failed to authenticate, try Re-Authorising your account in the sonos app</faultstring></soap:Fault></soap:Body></soap:Envelope>"
   },
   "level":"debug",
   "service":"bonob",
   "timestamp":"2023-02-05 13:19:16"
}

As the credentials also worked directly in Navidrome, it took a bit before I tried to explore the credentials characters :/

Utilizing simojenki/bonob:v0.6.2 and deluan/navidrome:0.49.3

Cause

Most-likely caused by insufficient handling of extended characters for credentials. (also mentioned in #134)

Known workaround

Limit Subsonic credentials to basic characters, ex. "bonobuser" / "bonobpw".

[simojenki]

This is a known issue, needs to be investigate. Lets leave this ticket open until it is resolved.

[dlehammer]

Hi @simojenki,

Based on this comment, a I thought a likely culprit might be the de-/serialization of the Subsonic credentials.
And I've looked at the asToken/parseToken methods, and the approach seems sensible IMHO.

On the other hand the "hex" usage in encryption.ts might be incompatible with extended characters 🤔
I suggest expanding the crypto-coverage with a UTF-8 String encryption/decryption test-case simulating a strongish password, ex. À&ې=wé, hopefully allowing you to tease out the root cause 🤓

EDIT: just realised the approach; convert credentials to JSON, then base64 encode and then I presume encrypt. ☺️
I'm still an advocate for additional UTF-8 coverage, if possible verifying the steps from clear text to encrypted and back again 🤓