Protecting Files

You can try setting the "prevent local caching" option when generating the HTML for your site from the Customizer tool... Once you've set this option, try various permission settings on your files. (i.e. 600, -rwx---- read-write-execute-owner only).

THis is not guaranteed to work with all web sites, but is worth a try. The reason that this may work is because the "prevent local caching" option causes wimpy.php to retrieve and output the file, hence, you may also want to check that PHP is an owner or part of the grouped that has permissions.

Be sure to empty your browsers cache after making changes to the HTML on your site so that your browser knows to retrieve the latest version of the files.


Pretty Good Protection

The issues with trying to prevent direct downloading can be summed up with: "Where there's a will, there's a way." Even with the most sophisticated techniques, there is no 100% fool-proof way to prevent material that is accessible over HTTP (e.g. any area of your web site that can be accessed with a web browser) from being accessed directly.

There are a number of options available to safe-guard your audio. Take a look at the following options available in the Customizer tool for the Wimpy MP3 Player:

In the Wimpy Script Configuration section:
- Startup Folder **
- Download a wimpyConfigs.xml file

In the Advanced Options section:
- Encrypt HTML
- Prevent files from caching **

If you are using XML playlists, these options will not be available. These options are only available when running Wimpy "off of" PHP, ASP or ColdFusion because only these "server-side scripting" environments can offer the kind of functionality required to control the server.

When running Wimpy off of an XML playlist the "Wimpy Script" (wimpyApp) option is set to an XML file.  Which means that some special server-side functionality will be lost because Wimpy does not have access to the wimpy.php/asp/cfm files which are normally defined through "wimpyApp."

XML files can control the server. Therefore, the following options are not available when running Wimpy off of an XML playlist:

- Force download
- Prevent files from caching
- Display ID3 tags
- Hide Folders
- Hide Files
- Startup folder

If you are using the JavaScript Kit to play tracks, you may have some luck configuring wimpy.js to use a "wimpyConfigs.xml" file and setting <wimpyApp> within the wimpyConfigs.xml file to a URL to wimpy.php/asp/cfm... WARNING: Attempting to use the options defined above with the JavaScript Kit have not been tested. They should work "in theory" but there are many variables that will contribute to successfully implementing these options when using the JavaScript Kit. When using the JavaScript Kit, URLs to each file are sent in manually. Hence, there may be a disconnect between where the wimpy.php file is located and the URL to the MP3 file that you are sending in (i.e. file system path to UR conversions), which can cause the player to fail when configured using the options listed above.



The most reliable method:

Perhaps the most reliable method is to take advantage of "file permissions." If you use the "Prevent local caching" option, you can prevent files from being accessed directly by changing the permissions of your MP3 files. For example, if the "Prevent local caching" option is set, and you change the permissions of your MP3 files to:

read-write-owner only

This will only allow your files to be accessed through Wimpy. The reason for this is because the "Prevent local caching" option uses PHP, ASP or ColdFusion to serve the MP3 file, rather than using the standard Web Server (Apache, IIS, etc). And since PHP is traditionally granted "owner" privileges (or is a part of the "owner" group, PHP will be able to server the file. However, if someone attempts to access the file directly with a web browser, they will be denied access, because they are not a part of the "owner" group.

You may need to test out various permission settings, such as 200, 400, 622, etc. Also, you may need to contact your server administrator to have them add PHP, ASP or ColdFusion to the "owner group" so that PHP, ASP or ColdFusion will have the proper permissions to access the MP3 files.

This method is not guaranteed to work with all web sites because the "prevent local caching" option causes wimpy.php to retrieve and output the file, and depending on the way that the web server and or PHP, ASP or ColdFusion is set up, the Prevent local caching options may not work. So it is best to ensure that the "Prevent local caching" option works before fiddling with permissions.

Other options

You may also want to take a look at setting up Wimpy SQL, which uses a unique method to playback the files -- where direct URLs to files are not visible -- making it a little more difficult for potential thieves to wade through the code. With Wimpy SQL you can set up customizable playlists rather easily. Click here for more information about Wimpy SQL.

Again, there are no fool-proof methods, the options available are "pretty good protection."

Only Wimpy MP3 Player offers these safe-guard methods, the other Wimpy products do not offer these safe-guards.


Alternate methods:

Neil Gertenberg (notesandtones at gmail dot com) points out:

1) Place the mp3 files for each playlist (ID3 tagged) in separate audio subfolders (mp3s/randomnames/) with a copy of wimpy.php and the getID3 files. The wimpy.swf stays in the mp3s/ folder

2) Use getID3 option, prevent caching and encrypt HTML options in configuration tool - no playlists, no XML. Set the path to the audio folder (mp3s/randomname/) for only the wimpy.php path. Leave the others to the mp3s/ folder, and skins to wherever skins are.

3) Create custom wimpy html file for each audio subfolder/playlist, and add a blank index.html to prevent browsing.
4) Manually edit (carefully) wimpyhtml files so that the paths to wimpyWrite.js point to the mp3s/ folder and NOT the subfolder (mp3s/randomname).






  ©Copyright Plaino LLC. All rights reserved.