How to make Azure Blob Storage for MP3 Assets to work with iOS Mobile Browsers

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ x ] Bug report
  • [ ] Performance issue
  • [ x ] Documentation issue or request

Current behavior

When the Azure Blob Storage container Access Level is set to:
Private (no anonymous access)
–> Assets works on android and microsoft browsers, but not on iOS browsers.

When the Azure Blob Storage container Access Level is set to:
Blob (anonymous read access for blobs only)
–> Assets works on android, microsoft and iOS browsers.

So iOS browsers (chrome, safari, firefox) are not able to stream audio content when Access level is set to private. Problem get solved when access level is set to Blob but obviously we cannot use that access level if we want Squidex protected assets functionality to work.

Expected behavior

iOS browsers should work with mp3 files with keeping Azure blob storage Access level as private.

Minimal reproduction of the problem

Change Access Level of Container to see the difference on iOS mobile browser. Mp3 files are not working when access level of container is private. There might be 10 minutes delay after changes taking effects when changing azure blob storage access level.

Environment

App Name:

  • [ x ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: [VERSION]

Browser:

  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [X] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [X] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Others:

I am not sure if I understand. Do you stream the asset from Squidex or from Azure? If you stream from Squidex, there should be no difference whether your blob storage is private or public.

Perhaps there are some headers that are not respected by squidex or something that prevents the streaming. But I have no idea what that would be. Perhaps a sample mp3 file would help.

I stream it from Squidex baseurl using this kind of path structure:
…/api/assets/{appname}/{assetid}

I was surprised also that somehow there is difference where the blob storage is private or public.

It happens with every mp3 song (you can upload test for example from here https://pixabay.com/music/).

You can replicate it by creating Squidex instance connected to azure blob storage with access level: private. Just try to upload it to Squidex assets using Squidex admin area and try that link Squidex provides you.

I have tested all other scenarios and the issue is only related to that Access Level switch on Azure. I think headers are similar regardless of Access level.

I don’t have an iPhone at hand, so I am not sure if I can help with that.