advplyr / audiobookshelf

Self-hosted audiobook and podcast server
https://audiobookshelf.org
GNU General Public License v3.0
5.74k stars 395 forks source link

[Bug]: missing crossorigin="use-credentials" property #2525

Open prof729 opened 5 months ago

prof729 commented 5 months ago

Describe the issue

When using ADB that is behind traefik + authelia (that is used as identity provider) in the console there is error regarding fetching manifest file. image

This is caused as manifest was expected to be json file but was returned as HTML and can't be parsed. And it's returned as HTML as authelia that is checking the requests didn't see any cookies in the request fetching manifest.json file. And this is cased as currently manifest link is missing crossorigin="use-credentials" property (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#crossorigin). Without this property browser does not send a cookies with request for manifest file and then authelia can not see if user is logged.

As far as I've check it should be added probably somewhere here https://github.com/advplyr/audiobookshelf/blob/v2.7.2/client/nuxt.config.js#L103 in the config file:

manifest: {
    crossorigin: 'use-credentials'
}

After edditing manually compiled js file and adding this attribute it works correctly. Thanks

Steps to reproduce the issue

  1. Install audiobookshelf
  2. Put it behind traefik with authelia as identity provider
  3. Login to audiobookshelf via authelia
  4. Check console in dev tools

Audiobookshelf version

v2.7.2

How are you running audiobookshelf?

Docker

advplyr commented 4 months ago

Have you tested adding that crossorigin without going through traefik? Some users may not be using Abs that way

prof729 commented 4 months ago

Yes, thats exactlly what I've done :)

So I've found in which js file there is this manifest defined (currently in 1c1d57b.js for version 2.7.2): Zrzut ekranu 2024-02-16 213755

Modified it manually to have also "crossorigin":"use-credentials": 2

and the error is gone in the browser and it's working corrently.

I just don't want to do it every time ABS updates 😄 (find the file and correct it 😉).

Here is how it looks like in more details on browser side:

Without this property when the browser sends a request for manifest it does not include Cookie header (as per specification): 3

but the cookie have the information to authenticate a request that I'm logged in for Authelia. And when it's missing then the Authelia can not confirm that I'm logged in. And it will issue 302 redirect to login page triggering the error about "Manifest syntax error" as the manifest is expected by the browser to be a json file not HTML document with login page.

Here is how it looks like after adding "crossorigin":"use-credentials" (Cookie header is present): 4

Hope it explains it better. Thanks

advplyr commented 4 months ago

Thanks, I understood that part. What I'm wondering about is the users that are not using traefik. How will they be impacted by this update?

See:

If the server does not give credentials to the origin site (through Access-Control-Allow-Credentials HTTP header), the resource will be tainted and its usage restricted.

prof729 commented 4 months ago

No idea how to understand that part in regard to manifest file. Maybe it's just general statement for all link elements that can potentially direct outside your domain/application?

On another page https://developer.mozilla.org/en-US/docs/Web/Manifest#deploying_a_manifest I've found only this statement:

If the manifest requires credentials to fetch, the crossorigin attribute must be set to use-credentials, even if the manifest file is in the same origin as the current page.

There is also this old discussion https://github.com/w3c/manifest/issues/535 with this comment https://github.com/w3c/manifest/issues/535#issuecomment-435739223 that tries to explain it a bit more.

So for more streight forward setup of running ABS I think this will just add this header Cookie that will be send to ABS node and it will just be ignored there. As there is no logic to check if js/img/style etc files can be served to not logged in users, right?