Playback is not working due to 401 error

[izderadicka]

Hi Chris,
I've updated demo site https://audioserve.zderadicka.eu (shared secret is mypass) with latest development version of audioserve (from branch position-db).
Connects fine, can browse collection, however cannot play files - due to 401 error - request for audio file (and related image) does not contain Authorization header -

[izderadicka]

Forgot to mention - was using hosted version - https://audioserve.coderior.com/ - is it up to date?

[KodeStar]

Hi Ivan, I'm just heading out to a wedding, but I'll take a look when I get back. My guess is it's because I'm just passing the url that's returned from the api directly to the audio context, so the Authorization header won't be attached to that.

[KodeStar]

Ok, I think there are 3 options for this.

1. The server allows the token to be sent as part of the url so ?trans=m&token=whateverthetokenis
2. I do a fetch request on the url, download the entire file first then glob it and do a URL.createObjectURL(glob)
3. I do a fetch request on the url and work out how to stream the chunks

I'll look more into it though. My test server doesn't have a password because it's on the LAN so I didn't need it, so hadn't come across this yet.

[izderadicka]

If you control the fetch then I guess you can add Authorization header?
What about using Service Workers to intercept fetch - this is what they are designed for - caching and network requests modification.
Current web client is using cookies, which work automatically for audio element, even for other origin.
Re: Option 1. - Could be done, but having authentication in header is preferred.

[KodeStar]

It’s not fetch request, it’s currently just setting the audio src to the path returned by the api. Interceptors would work if I was using fetch, and I might try implementing them anyway as I’m doing a lot of fetch requests for things like the description and cover.

Using cookies would be good, unfortunately because it’s an api call samesite lax doesn’t work, it would need to be samesite none. It works on your web client because they are both served from the exact same domain.

If I have to use fetch, it’s a lot more complicated, downloading the whole file first wouldn’t be a good user experience, so I would have to work out how to stream chunked responses.

[izderadicka]

It works on your web client because they are both served from the exact same domain.

Not exactly - in development I'm I'm servings from two locations - client in served from webpack dev server - port 8080 and API from port 3000 - browser consider this as two different locations - that's why CORS was introduced in first place.

[KodeStar]

iirc localhost is accepted, but other domains aren't

[KodeStar]

Potentially you could get round it by putting them on subdomains of the same main domain, so host the client at https://client.audiosilo.app and the server on https://audioserve.audiosilo.app, then I think they would both be classed as being on the same site. I could set up some kind of dyndns service where https://somekindofhash.audiosilo.app points to the persons IP, it might even work for LAN addresses, I'm not 100% sure on that one (so https://098f6bcd4621d373cade4e832627b4f6.audiosilo.app points to 192.168.10.15 for example), if that worked (again, not sure it would) then there would be no need to reverse proxy for people who just want access within the lan. Otherwise you could point at the WAN address and they would have to port forward or reverse proxy.

[izderadicka]

I have done some tests, you right localhost is handled differently. Proper way to handle it is per this specification https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite - if cookie is SameSite=None; Secure then it works cross site. SameSite is rather new thing, introduced in last few years I think, so it was source of some confusion. I open issue for this izderadicka/audioserve#64

[KodeStar]

Awesome, thanks Ivan.

[izderadicka]

I've have updated https://audioserve.zderadicka.eu with new code with cross origin cookies - and playback works.
These is still one place with 401 - image fetch from JS, which is missing the Authorization header:

Is there latest version of your code on https://audioserve.coderior.com? So does it make sense to report things that are not working for me? Most notable was that playback did not continue on next chapter after finishing current one.

Also downloading files to cache is having 401 - again Authorization header is missing:

[KodeStar]

Awesome! :D yeah https://audioserve.coderior.com is built from master on each push, so it's always up to date with master (bugs and all), when I'm closer to it being finished, I'll probably start pushing to a dev branch instead and have master as the current release.

I should be able to get those bugs fixed now the cookie is working, I pushed a change earlier which added it for the audio player, which is likely why that worked straight away, I haven't done it for the other urls yet though, should just be a case of adding with credentials to them, rather than passing the bearer.

Edit
Nope, I hadn't uploaded that code, so I can only guess it was cached? Maybe from playing it with the built in web client?

[KodeStar]

Hmm, I'm still not able to play from https://audioserve.zderadicka.eu from localhost? I wonder if that one file was somehow cached, which is why it didn't play the next file?

[KodeStar]

The cookie still seems to being added with SameSite Lax

I've tried it both from localhost and from https://audioserve.coderior.com/

[izderadicka]

Hmm,
it was false success on my side, sorry, matter is even more complicated.
This is how it works based on my experiments:

Scenario 1)

• Opening page in https://audioserve.coderior.com/ and logging in
• Browser sends POST to https://audioserve.zderadicka.eu/authenticate
• Back is sent set-cookie with params SameSite=None, Secure
• Browser sets cookie for location audioserve.coderior.com with SameSite as Lax
• This cookie is not send to requests to https://audioserve.zderadicka.eu as it is different location

Scenario 2) (Why I initially thought it now works)

• Opening page https://audioserve.zderadicka.eu and authenticating there
• Back is send set-cookie with params SameSite=None, Secure
• Browser sets cookie as secure and with SameSite None for location audioserve.zderadicka.eu
• Now I go to https://audioserve.coderior.com/
• And playback works - the cookie is send with request

So in short - cookie can be set only as result of user interaction on that site, setting cookie for other site in request initiated from javascript did not work. It is probably due to some privacy limitations. It's getting so fucking complicated with cookies.

I'll be looking around still, but se per now I think there are two options:

1. token as URL query parameter
2. For login redirect to audioserve site and then redirect back - but it'll require some special page for this "federated" login