Recently I disovered Jinzora> which allows you to keep a media library on your web server and stream songs to anywhere on the Internet. It's really cool with it's "slick" interface displaying album art, artist art as well as descriptions of artists, albums and even lyrics! I've moved my Media Collection over to using Jinzora. It's a PHP application using a MySQL backend and it's open source. Problem is it's a big app and it uses a lot of resources on my tiny server. I need a bigger server for sure!
Jinzora has capabilities for transcoding songs to other bitrates on the fly. While nice in theory I cannot afford yet more server bandwidth - my server is crawling at times as it is!
Jinzora also allows people to register for user accounts and for the administrator to configure the level of access per user classes. It also has the ability to stream music to several Flash based players as well as allow the user to use an external media player such as Windows Media Player or WinAmp, etc. For example, on Linux I use xmms. This helps because you can configure Jinzora to use a Flash based player and you don't have to worry about whether or not your end user has properly configured say Windows Media Player or that they have a mess of Windows Media Player, WinAmp, MusicMatch and Real Player all competing for their media files and none really configured correctly, which is often the case.
One thing that bugs me is that Jinzora is that it encodes links with parameter information that is encoded in base64. This is probably for security purposes but it really makes links that you may email or paste to an IM window ugly!. The following will turn this off but there's a problem where when you implement this hack logging in of users then fails to work! The following was gotten from the Jinzora Forums from thisbioart wrote:
Finally, a note on security: When I get my Jinzora site up and streaming I noticed even slower than normal response from my server and even got knocked off the net a few times. Scanning the logs it appears as if there are people again hitting my server and attempting to directly download my mp3 files or download them through Jinzora in an automated fashion that just swamps my tiny server. For example, college kids find a site with mp3 files then swamp it to steal your mp3's.
Jinzora has it's own directory where the PHP files and other data is stored. It also has media directories where media is pulled from. My Jinzora directory is at /web/jinzora2. My media directory is at /web/Music (which is shared via Samba over to my XP boxes). As /web is my DocumentRoot, this exposes /web/Music to the INternet. Thus you could access http://defaria.com/Music//.mp3 and utilize something like wget(1) to effectively steal mp3 files.
IOW you don't need to go through the Jinzora interface, thus be subject to Jinzora's user/password login to get to my mp3 files. My first attempt to secure this was to put a .htaccess file in /web/jinzora2. This secures Jinzora by making the web server perform basic authentication. But basic authentication is a pain to manage and it defeats the username/password accounts in Jinzora.
So I got to thinking "I just need to secure /web/Music. Jinzora will still be able to access those media files without the need to authenticate through the web server because it's basically a PHP app running on my server and just reading files through a path" and I moved .htaccess to /web/Music. Viola, I'm now secure!
Jinzora has capabilities for transcoding songs to other bitrates on the fly. While nice in theory I cannot afford yet more server bandwidth - my server is crawling at times as it is!
Jinzora also allows people to register for user accounts and for the administrator to configure the level of access per user classes. It also has the ability to stream music to several Flash based players as well as allow the user to use an external media player such as Windows Media Player or WinAmp, etc. For example, on Linux I use xmms. This helps because you can configure Jinzora to use a Flash based player and you don't have to worry about whether or not your end user has properly configured say Windows Media Player or that they have a mess of Windows Media Player, WinAmp, MusicMatch and Real Player all competing for their media files and none really configured correctly, which is often the case.
One thing that bugs me is that Jinzora is that it encodes links with parameter information that is encoded in base64. This is probably for security purposes but it really makes links that you may email or paste to an IM window ugly!. The following will turn this off but there's a problem where when you implement this hack logging in of users then fails to work! The following was gotten from the Jinzora Forums from thisbioart wrote:
Thanks for the offline comments... long story short, it appears like it was a minor incompatibility between the released J2 and Mandrake 10.1's php. I don't know how it will be fixed in the release, but the quick fix I got from Ben/Wim: (This fixes it, but it is not optimal, so only use it if you really need it).Again, currently, implementing this does indeed turn off the base64 encoding of URL parms but it breaks logging in and logging out.
Open /lib/general.lib and add this code to the scrable functions: "return $string ;". First: Search for this part:
change it in:function jz_encode($string, $key = false) { // Complex scheme.
Next : Search for this part:function jz_encode($string, $key = false) { return $string ; // Complex scheme.
change it in:function jz_decode($string, $key = false) { // Complex scheme.
function jz_decode($string, $key = false) { return $string ; // Complex scheme.
Finally, a note on security: When I get my Jinzora site up and streaming I noticed even slower than normal response from my server and even got knocked off the net a few times. Scanning the logs it appears as if there are people again hitting my server and attempting to directly download my mp3 files or download them through Jinzora in an automated fashion that just swamps my tiny server. For example, college kids find a site with mp3 files then swamp it to steal your mp3's.
Jinzora has it's own directory where the PHP files and other data is stored. It also has media directories where media is pulled from. My Jinzora directory is at /web/jinzora2. My media directory is at /web/Music (which is shared via Samba over to my XP boxes). As /web is my DocumentRoot, this exposes /web/Music to the INternet. Thus you could access http://defaria.com/Music/
IOW you don't need to go through the Jinzora interface, thus be subject to Jinzora's user/password login to get to my mp3 files. My first attempt to secure this was to put a .htaccess file in /web/jinzora2. This secures Jinzora by making the web server perform basic authentication. But basic authentication is a pain to manage and it defeats the username/password accounts in Jinzora.
So I got to thinking "I just need to secure /web/Music. Jinzora will still be able to access those media files without the need to authenticate through the web server because it's basically a PHP app running on my server and just reading files through a path" and I moved .htaccess to /web/Music. Viola, I'm now secure!
No comments:
Post a Comment