Add credentials: "include" back to Radarr and Sonarr

[mcclurec]

Description

credentials: "include" was mistakenly removed from the Sonarr and Radarr components when migrating the API key from a header to a query param. This PR adds the fetch option back to support set ups with SSO providers like Authelia and others. Similar to PR-258

Fixes # (issue)
Possibly #251. That assumes they're running an SSO like Authelia, and the JSON parse data is because it's getting the login page HTML instead of the API JSON. Can't tell without more info on the Issue.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I've read & comply with the contributing guidelines
• I have tested my code for new features & regressions on both mobile & desktop devices, using the latest version of major browsers.
• I have made corresponding changes the documentation (README.md).
• I've checked my modifications for any breaking changes, especially in the config.yml file

[bastienwirtz]

Good catch @mcclurec, sorry about that. Thanks for fixing this.

[nicjay]

I think this reintroduced the CORS errors that were previously resolved. See #250

[Toneti10]

I think this reintroduced the CORS errors that were previously resolved. See #250

Yep! It worked for me until the last update :/

[bastienwirtz]

Damned, sorry for that.
@nicjay @Toneti10, do you use some kind of auth layer (like Authelia, vouch-proxy, oauth2-proxy, ...) or just a simple homer install ? Did you added some header on Sonarr or Radarr ? If yes which one(s) ?
Truth is, I didn't tested properly because I don't have a Sonarr or Radarr available, but I will do that properly this time and fix that one and for all.

[nicjay]

Damned, sorry for that. @nicjay @Toneti10, do you use some kind of auth layer (like Authelia, vouch-proxy, oauth2-proxy, ...) or just a simple homer install ? Did you added some header on Sonarr or Radarr ? If yes which one(s) ? Truth is, I didn't tested properly because I don't have a Sonarr or Radarr available, but I will do that properly this time and fix that one and for all.

I'm running Homer, Sonarr, Radarr in separate docker containers just on localhost, with their own assigned ports. i.e.

http://192.168.1.2:8001
http://192.168.1.2:8002
http://192.168.1.2:8003

No reverse proxy or auth layers for these services, no headers added to Sonarr/Radarr.

[mcclurec]

🤔 Could you guys paste some error messages you're getting in browser? Are you seeing something like Access-Control-Allow-Credentials header in the response is ''?

[mcclurec]

Sonarr doesn't specifically set that header, so that may be the root issue

https://github.com/Sonarr/Sonarr/blob/0a2b109a3fe101e260b623d0768240ef8b7a47ae/src/Sonarr.Http/Extensions/Pipelines/CorsPipeline.cs#L59-L79

[nicjay]

🤔 Could you guys paste some error messages you're getting in browser? Are you seeing something like Access-Control-Allow-Credentials header in the response is ''?

The error is:

Access to fetch at 'http://192.168.1.2:8002/api/queue' from origin 'http://192.168.1.2:8001' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

[mcclurec]

Thanks. I'm whipping up a PR to make the credentials: "include" block optional per service. CORS is always a fun one to work with. Turns out if we all have different networking stacks, it's hard to make universal decision that "just work". Sorry for the trouble.

[mcclurec]

@bastienwirtz Opened PR 301 to fix