Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Covers from Sonos Devices not shown - wrong HTTP-Port #487

Open
kptkip opened this issue Jan 12, 2024 · 5 comments
Open

Covers from Sonos Devices not shown - wrong HTTP-Port #487

kptkip opened this issue Jan 12, 2024 · 5 comments

Comments

@kptkip
Copy link

kptkip commented Jan 12, 2024

Describe the bug
When using a Sonos Device as etity for a media-Player, the corect URL-String is fetched from the data point.
But the wrong HTTP-Port is used.
It is used the Port from the lovelace-Webserver (in my case 8091) but the cover-Image is distributed by the IOBroker-Webserver (in my case 8082)

To Reproduce
Steps to reproduce the behavior:

  1. Adapter Sonos with one device
  2. Add Mediaplayer-card an d choose the Sonos device as entity
  3. Code looks like this http://IPADDRESS:8091/sonos/coverImage/192_168_34_233.png
Bildschirmfoto 2024-01-13 um 00 13 20

Expected behavior
While changing this in developer view in Chrome into: http://IPADDRESS:8082/sonos/coverImage/192_168_34_233.png
Bildschirmfoto 2024-01-13 um 00 13 42

Screenshots & Logfiles
If applicable, add screenshots and logfiles to help explain your problem.

Versions:

  • Adapter version: 4.1.1
  • JS-Controller version: 5.0.17
  • Node version: v18.17.1
  • Operating system: Docker

Additional context
Add any other context about the problem here.

@Garfonso
Copy link
Collaborator

What is the content of the state with the cover?

@kptkip
Copy link
Author

kptkip commented Jan 13, 2024

The relative URL to the image with leading "/"

@Garfonso
Copy link
Collaborator

So in the example it would be /sonos/coverImage/192_168_34_233.png?

I'm a bit confused. I did not write that part, but for some reason there is support for URLs starting with /adapter, see here:

this._app.use('/adapter/', async (req, res) => {

Not sure if the URL in Sonos should start with the string "adapter".

@kptkip
Copy link
Author

kptkip commented Jan 13, 2024

So in the example it would be /sonos/coverImage/192_168_34_233.png?

correct.

I'm a bit confused. I did not write that part, but for some reason there is support for URLs starting with /adapter, see here:

this._app.use('/adapter/', async (req, res) => {

Not sure if the URL in Sonos should start with the string "adapter".

As I understand the mentioned code right, it is only rewriting relative URL-parts (i.e. "/adapter/...") to something else.

I have the assumption, that all URLs for frontend data (html, images, js and css) the adapter intended to be delivered by the web-server of the lovelace instance. And this is addressed by the given port in the preferences of the adapter (here: 8091).

So, the parts, where data are fetched from the ioBroker itself (i.e. images for media-player) the assumption, that the lovelace-webserver delivers them is wrong and should be corrected to work correctly.

@Garfonso
Copy link
Collaborator

So, the parts, where data are fetched from the ioBroker itself (i.e. images for media-player) the assumption, that the lovelace-webserver delivers them is wrong and should be corrected to work correctly.

That would be one, very hacky, way with a lot of issues. You'd need access to both servers, the server of the web instance might ask for a password, which would break lovelace, if one of both is https and the other one is not, a lot of other issues will happen.

So that is why the code above reads the file from the iobroker filesystem and delivers it from the lovelace webserver.

Did you try to add "/adapter/" in front of the URL? That would really help.

Garfonso added a commit that referenced this issue Apr 25, 2024
fixes sonos cover image issue #487

Might solve a security (?) issue with auth enabled users would have read access to all adapter.admin files, because it did never check user before.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants