Docker compose volumes for persistent data

[Daniel Hammer]

Hi bonob gurus,

I'm a bit puzzled, as the BNB_SECRET description states

secret used for encrypting credentials

This hints that some data is persisted inside the container.

But the docker-compose example doesn't contain volumes for the bonob service.

Which path(s) should be mapped, in-order to maintain state across upgrades and enabling backup of the bonob state to persistent storage ? 🤓

[Simon J]

There is no state that needs to be maintained.

BNB_SECRET is used for hte json web token that is encrypted and passed around between the sonos device and bonob.

If you set BNB_SUBSONIC_ARTIST_IMAGE_CACHE then you will need to mount a volume to be used for the cache, however there is nothing to maintain in here between upgrades.

[Daniel Hammer]

Hi @simojenki,

Thanks for taking the time to reply.

Regarding

BNB_SECRET is used for hte json web token that is encrypted and passed around between the sonos device and bonob.

Just trying to understand the distribution of responsibility.

That JWT is dynamically generated by bonob (based on the BNB_SECRET) and used in the request/response with the Sonos device ?

So when a user is registering the "subsonic clone credentials", these credentials are persisted in the Sonos device ?

🤓

[Simon J]

That JWT is dynamically generated by bonob (based on the BNB_SECRET) and used in the request/response with the Sonos device ?

Yes, the JWT is used so that your credentials are encrypted when sent back and forth between the sonos device and bonob, and then onto *sonic

Yes they are persisted in the Sonos device, though as you choose the secret with which they are encrypted they should be safe. Their expiry is controlled with BNB_AUTH_TIMEOUT

It would be better if *sonic API supported API tokens or some such, however it doesn't.

[Daniel Hammer]

Hi @simojenki,

Thanks for taking the time to elaborate.
I've created #146, in an attempt to capture your insights 🤓