audio download possible without access rights

Just wondering (I haven't tried it) if setting downloads to PRIVATE under ADMIN->SETTINGS will help?

Dub

a users permissions are cheched when they access audio/play... could you provide steps to reproduce it

well, i really don't think there's much you can do about that. if you poke around a bit you'll notice that the flash player actually downloads the complete mp3 to their temp directory. see http://drupal.org/node/35885 for more.

i do want to point to the warning on the audio edit form:

If checked, a link will be displayed allowing visitors to download this audio file on to their own computer.WARNING: even if you leave this unchecked, clever users will be able to find a way to download the file. This just makes them work a little harder to find the link.

i think we need to create a readme file that describes some of the known problems like this one.

The problem is that the flash player does not actually stream. It uses progressive downloading to start playing the mp3 file even before it has finished downloading. While it gives the impression of streaming, it is actually downloading the file to a temporary directory. You'll notice this is different than "real streaming" where your computer sets up a small buffer, probably some sort of circular buffer that begins overwriting itself after a period of time (this is a guess). I haven't looked into this too much, but perhaps researching open source streaming technologies would be time well spent. Not even sure if such a thing exists...

keep in mind that even without viewing source etc users can copy the playing audio using various freely available audio recording apps as it plays...

they just press play on the player and record on the other app... even easier for non-technical types to do...

but i have a solution that should be really cool...

how about this:

the audio module make 2 versions of the mp3... 1 is a streaming play version... that is it converts the 192thingy mp3 file to a lower quality file, say 128 or 64 or something... perhaps the admin can choose? or just make it simple and have it drop down to 128?

anyway, the file lives in a seperate directory... so even if someone wants to record the "stream" or view source or whatever to find the file on server they will only get the crap mp3... but if they pay to download the mp3 they get the higher quality one... or of they register or whatever...

its not perfect... but at least it creates some reason for actually buying your mp3 or registering on your site or whatever...

and if someone wants to be devious and steal your mp3 they get the crap quality version....

Right. If someone wants to download the audio, they'll figure out a way to download it. It might be easier, as was mentioned, to create a lower quality MP3 using LAME mp3 encoder/decoder but that would require installing it on the remote server. This is what MusicForAmerica.org uses. Would be best suited as an add-on module to the existing audio base, I think due to potential for complexity.

Another idea would be to truncate the file to 30 seconds. Maybe LAME wouldn't even be needed for that and we could figure out some way to pull out the headers we need and then arbitrary audio from the middle.

yeah, a "streaming" sample would be cool for a band web site too... even cool if you could set the sample length... or even fancier would be start and end point and fade in and fade out... heh heh... but that is getting a bit crazy...

if one uses a 3rd party site for handling the sale and transaction (for example, payloadz.com) you can then put a sample on your site using the audio module as it is...

that is what i have setup, although i have the whole song on my site as well...

@zirafa: Another idea would be to truncate the file to 30 seconds. Maybe LAME wouldn't even be needed for that and we could figure out some way to pull out the headers we need and then arbitrary audio from the middle.

This reminds me of something that happened by accident a few months ago (with 4.6). Since I couldn't upload large files via the node form, I created short, dummy mp3s to upload in the node form and then FTP'd the real files to the /files/audio directory. I didn't realize that the smaller filesize and and shorter duration were stored in the database tables, and somehow this led to drupal only delivering the beginning of the mp3.

I don't know if I can reproduce that accident in 4.7, but I suspect it was the combination of the Download Method being set to "Private - files are transferred by Drupal" (admin>>settings>>file system) plus the shorter filesize in the "files" table and/or the shorter playtime_seconds in the "audio_node_metadata" table (in 4.6).

scott, that's a clever idea. just have file_transfer send only the first X number of bytes to the client. the only problem is that more of a lower quality file would be sent than the same high quality file. not a bad idea for those who want to limit the files though...

hey that sounds cool guys...

you could even have a little note with something like:
192bla-blah mp3 - 30 secounds = "x" amount of data
128blah blahmp3 - 30 secounds = "y" amount of data

or something like that... even just a simple little blurb about this would be cool for rough estimates...

rawk on dudes!

Guys, let's stay on focus. Described bug of this issue is that anyone is able to play or download an audio file, even if the user role 'anonymous' does not have access rights for playing or downloading audio files. This issue should concentrate on user access rights and not on copy protection.

So what we have to do is clear: Audio files have to be provided by a file handler/streaming script. It seems like audio/play/# was thought to do the trick. For obvious reasons this is not working:

1. Play and Download paths shouldn't be cached (btw: admin paths, too).
2. To make our life easier, we should change play and download paths to audio/#/play and audio/#/download, i.e. we get the same behaviour and extensibility like nodes in general. This also has an effect on /audio/user/#/feed.
3. Access rights defined by audio_perm() were not used in audio_menu()...

Attached patch fixes audio file access bugs.

the choice of requiring 'administer site configuration' to access admin/settings/audio rather than 'administer audio' was intentional.

the big problem with the patch is that it'll break everyone's existing urls. and it's not clear to me what this is actually fixing...

Assigning this issue to me.

Although I don't understand why, I've reverted administer site configuration permissions. May you explain?

I've created backwards compatibility paths for audio/play/#, audio/download/# and audio/feed/user. However, I have not seen backwards compatibility in another module yet.

This patch fixes access rights for audio nodes and adjusts paths of audio.module to be more similar to other modules, f.e. node. That is interesting for someone who does not want that f.e. anonymous users have access to audio files. If someone wants to develop access rights to another level (like me), f.e. to set up a audio selling site (see http://drupal.org/node/69678), this is the basic work which has to be done here.

Is there a chance to commit this?

after replying to #69678 i'd started a reply to this but it got chomped by my browser. sun, you should look at implementing hook_audio() like the ecommerce media product does. it allows other modules to allow or deny access to the play and download features. the documentation for the hook is in
the comments for audio_invoke_audioapi().

This patch just adds proper access rights to audio module menu paths and I think we'll be on the right track if we'd commit this. People who want to have only private or member access to audio files should have the ability to use the access rights which are provided in Drupal access control.

Otherwise we should remove the available access permissions to a) create no confusion and b) close this issue.

Regarding #69678, I've tested audio.module and revised audio.module (with this patch) altogether with ec_media.module and there seems to be no effect.

Please let me know your concerns.

sun, i still haven't seen a step by step explanation of what this fixes or improves. what can't you do now that that will allow? or, conversly, what can you do now that you should not be able to do?

Hm. After installing a shiny new Drupal sandbox with audio module I'm not able to reproduce the described behaviour. Access to /audio/download/# and /audio/play/# isn't allowed if a user does not has the according access permissions.

The only thing what we could do right now is to update the audio_menu() hook to decrease confusion for developers regarding access permissions used by audio module.
Never change a running system?

i think this has been resolved.