Prohibit file downloads in audio player.

jayrope · 2022-04-15 17:08:20

I am working on an audio player, that draws its files from uploaded mp3 of a particular category.

<txp:file_download_list category="recent" sort="rand()" limit="1" status="live">
  <audio id="radioplayer" autoplay muted>
    <source id="mp3_src" src="<txp:file_download_link />" type="audio/mpeg">
      Your browser does not support html5 audio.
  </audio>
</txp:file_download_list>

How can i suppress the direct link to a possible file download from showing up in the source code? smd_access_keys seems to overcomplicate the issue (corrections welcome). It seems, a simple obfuscation would do. But how?

Any hints appreciated and thank you in advance.

jakob · 2022-04-15 21:10:31

I’m not sure you can in regular players unless they use some kind of signing but would gladly be proved wrong.

What you might want to try is to provide your audio as a stream. That transforms your mp3 into many chunks that are provided just ahead of listening and are not useful on their own to download. It won’t prevent people recording their computer audio or from using services that convert streams to audio, but would hinder the show source and download file method.

I haven’t tried this with audio, only with video using MUX and a corresponding player that supports HLS and it worked brilliantly. MUX says they also do audio but I’ve not tried it. There are probably similar services like that for audio. Otherwise, ask MUX directly – they were super helpful and informative. You don’t have to use their programmatic API, their back-end allows you to add assets manually. I used their open-source media-chrome player (audio example here) and it was quick and straightforward to configure and freely stylable using css variables.

EDIT: MUX is not free but if your expected volume is low and charges come under 5$/month, they don’t bill. They have a calculator for video and according to the blog post, audio costs 1/10 of that (audio-only prices shown in the “what’s included” section lower down).

jayrope · 2022-04-16 12:05:56

jakob wrote #333115:

I’m not sure you can in regular players unless they use some kind of signing but would gladly be proved wrong.

What you might want to try is to provide your audio as a stream. […]
I haven’t tried this with audio, only with video using MUX and a corresponding player […]
EDIT: MUX is not free […]).

Thank you Jakob, interesting suggestions.

I am running on a shared host w/o full access to the server intestines, past extra software installs have proven to be tedious or impossible. Among those attempts was a streaming server, i could ultimatly not achieve this without upgrading my account to sthg full control – it already costs too much.

So before i solve that (yes, you recommended all-inkl.com before) i thought to try a more simple way – several possible methods outlined here
This could envolve base64 encoding/decoding of the source file link or using a PHP-driven black box, probably similar to what TXP does with file links anyhow. In fact it would already be enough to take the ID out of the TXP generated link, that is visible in the source code, but have it ready, when the player is actually playing.

I’v asked here, because i just wantd to see, if somebody touched this issue in conjunction with TXP before.

Last edited by jayrope (2022-04-16 12:06:32)

Dragondz · 2022-04-16 12:53:19

Hi
I am not sure if i understand correctly but is enabling the htacces of the file directory isn’t sufficient to block direct link?
Cheers.

jakob · 2022-04-16 13:00:24

jayrope wrote #333119:

I am running on a shared host w/o full access to the server intestines, past extra software installs have proven to be tedious or impossible. Among those attempts was a streaming server, i could ultimately not achieve this without upgrading my account to sthg full control – it already costs too much.

MUX is in effect an online streaming service so there’s nothing to install and you wouldn’t have to change anything about your own server. This site I used it with runs on a typical sub 5€/month shared server in Austria.

In my case, the site has a collection of 30-60 second video clips and one longer full-page background video on the homepage. I only investigated streaming because I wanted the background video to start as quickly as possible without visitors having to download too much data before seeing anything.
Using MUX’s calculator I estimated there would have to be about 6800 video views before any costs would be billed. In ten days of intensive testing by myself, designer and client – e.g. testing on multiple devices, troubleshooting errors, experimenting with styling, leaving it running on loop – I racked up 74cents of costs. I suspect the site will see less traffic in actual use. Given that audio costs 1/10 of video, you could expect to stream many more plays before any costs are incurred, and even then it is pay-as-you-go, so you’re not suddenly bumped to an expensive plan, you just pay for the seconds that are played (and buffered).

The (manual) process is as follows:

Upload mp4 originals via the Content › Files panel
Visit MUX admin panel › Create Asset › Enter the video’s online URL.
A JSON response is provided instantly (just like the demo on their homepage). Encoding of the (admittedly short) videos happened with seconds.
Copy playback ID to Textpattern article’s custom field.

I used the custom field to construct the stream URL and poster thumbnail image for the media player. All a visitor sees is an .m3u8 url in the player. The browser console shows no mp3 files, just the first series of .ts data chunks of the stream.

For a smallish number of files, the manual approach is fine. If you have hundreds of audio files, you probably want to construct a small script to run through the list of files and POST to the API and retrieve the playback ID programmatically.

Someone could make a nice little plugin to do all this automatically as the MUX API provides all the necessary create, edit and delete functions you’d expect.

jayrope · 2022-04-16 13:58:34

Dragondz wrote #333120:

Hi
I am not sure if i understand correctly but is enabling the htacces of the file directory isn’t sufficient to block direct link?
Cheers.

Direct file download from source code or frontnd page works, otherwise one couldn’t have downloads from file tags on a frontend page either.
However, direct access to the files directory wouldn’t list any files contained therein and show a white page instead. If i am not mistaken, that is TXP standard behaviour.

peterj · 2022-04-25 03:41:19

We’ve been fiddling around with ways to protect font files (and still are). You might try some of these if you can’t get htaccess to do what you need it to:

- changing permissions of a protected content folder from 755 to 700 (maybe not if you’re using TXP file manager for legit downloads)
- add the Cross-Origin-Resource-Policy: same-origin security header to only allow the fonts to load in the local site

htaccess hot link protection can be file-type specific, which may help? ref

Textpattern CMS

Textpattern CMS support forum

#1 2022-04-15 17:08:20