bcc-code / bmm-web

[BMM] The BMM website and desktop app to listen to the content from BMM.
https://bmm.bcc.media/
GNU Affero General Public License v3.0
16 stars 8 forks source link

Player: 403 error when trying to resume player after long break (Signed Cloudfront url expires) #193

Closed andreasgangso closed 7 months ago

andreasgangso commented 1 year ago

The network request for the mp3 failed after trying to resume after leaving the website tab in the background. I forgot to log more details like the access token etc before I closed the tab. If I can make it happen again I'll post more details. Here's all I have. Chromium-based edge on mac.

Repro steps as far as I know:

  1. Play something on web (I used chromium-based edge)
  2. Pause the thing and leave it in the background for a while
  3. Come back a long time later (the tab was also sleeping
  4. Try resuming

Error somethingsomething.mp3

Failed to load resource: the server responded with a status of 403 ()
andreasgangso commented 1 year ago

I reproduced it now with the steps above and it tried to load a track with &Expires=1692624483 (13:28 UTC, i.e. it expired almost an hour ago)

SimonSimCity commented 1 year ago

This will be handled by #153. I just removed the mentioning of electron in the title. Thanks for reporting, I'll close it as duplicate. Feel free to fix #153.

SimonSimCity commented 1 year ago

Sorry, but had to reopen 😅 if this is for playing and continue playing, we'd need to replace the token while continuing to play from the same URI.

Please help us getting a better understanding here: does this apply to continuing content or also playing other content when the website has remained open in the background? Does either one work? I know some systems use aggressive prefetching, where the first would not be testable...

Be aware that these technically are two very different cases, which might not be that apparent for a user 😅

andreasgangso commented 1 year ago

This is for resuming the same content. But this isnt the access token expiring, its the signed file url which expires after a time, so you’d need to fetch a new url from the api or something

SimonSimCity commented 7 months ago

@kkuepper would be good to know how this is tackled in the app. The mp3-link in a track is just valid for about 60 minutes...

kkuepper commented 7 months ago

If I remember correctly, we're watching for errors during playback. If an error happens we reset the player, leading to rebuilding the url with a potentially updated access token.

(Another thing that could cause problems on BMM-Web: When loading the mp3, the first request goes to the Api. The Api then redirects to Cloudfront, with a url that's valid for 60? minutes. If the redirect is cached by the browser that would lead to using an expired link. My guess is that it's not cached, but I wanted to verify.)

SimonSimCity commented 7 months ago

Setting https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#preload could help debugging...

@kkuepper this means, this is just for the currently playing track, right? If we rebuild the audio interface on the current position, it should work? I can create a POC on this based on PR #342 I had to this topic.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/error_event I think I have enough info now. I'll create a new PR based on the mentioned one where the audio will rebuild on error. The media should resume on error, right?