I appreciate the discussion.  I did find the text file that records the downloaded IDs and the date, which is what led me to investigate what it meant.  I looked at how bandamp had done it, hoping to find some clever inspiration or something, but when I discovered what it was doing and how, I made a note here about an area for improvement.

I just want to make sure that it's understood: I'm asking things on this thread when I work on them in the new code, which means that I've already got LOTS that I've done.  This thread is dedicated to revealing what I'm doing about each of the problems (and I state the problems so that people can appreciate what's going on).  I will be moving the current code to the demo server sometime later this week, I suspect.



As for the actual topic of proxied media access:

I think that both database blobs and proxied access have something in common: heavy memory use.  Apache is sophisticated enough to allow "streaming file downloads" according to user bandwidth, serving the file in chunks at a time.  Any other solution is likely to be less effective, unless we had professional-quality media caching servers (!)

I have a project for my day job right now which suffers from database access lockup, and an entire CPU core gets stuck at 100% usage for several seconds while the database is working, which hurts other online users.  Especially since this server has only 2 CPU cores, I wouldn't want to introduce that problem to bandamp...

I've got another idea for how to sidestep the problem, which would be something like this:

- Store all audio files in a non-public directory; none of them are accessible to the Apache server
- When a user asks for a file (streaming or download), the site's code receives the request
- Site code checks your permissions, and if you're allowed to get the file, then the site creates a symlink in a place where Apache can get to it.  The symlink would be a randomly generated hash, so that it's not guessable.
- Redirect the browser to the new symlink; user starts their streaming/download
- Delete the symlink after user is done with it

I like this strategy because it lets Apache still do the heavy lifting, but the site itself is the only thing that grants permission for a person to access a file.  What do you think?  It might be a lot of symlink creation and deletion, but we could find ways to optimize it for common downloads (or just public files).

well I'm not quite happy with this idea of symlinks. Already the best way is to use the (download) proxy which manages permissions maybe via session id (md5?). Perhaps in combination with htaccess.....

In case of troubles with broken lines, for example the user's internet connection is down just at the moment the symlink was created, how can you ensure this symlink is resetted/deleted correctly? And think about bots could get access due to "open" symlinks which are not resetted properly.

I like this proxy idea very much. But that's only MY humble opinion. Where are the programmers out there to post a statement to this topic?

Well, the proxy solution is already implemented in the new code, I just wish it wasn't so heavy on memory.

A bot couldn't actually guess the download link, though-- it would be heavily random for every user.  It could be one-time-use.  There is certainly a problem with aborted access and leaving symlinks behind, so it would have to be able to clean up after itself.

I think we can completely avoid htaccess, because the site code is doing authentication and serving the file.  Besides, Apache's official stance is that htaccess files should be completely avoided if you have access to Apache's httpd.conf file.

I won't worry about the symlink thing for now.

My laptop actually died on me last night, and it won't start up.  I use an online backup service, so I don't think I've lost anything.  I'm getting it looked at today.  Hopefully I'll be back in business later this afternoon.

Just wanted to officially say that there was no data loss from my computer dying.  All is recovered and I've got the project files running again.

Online backup is great.

Login duration, anyone?

One of the things BandAMP does is guess at who is online based on your login cookies.  If you close your browser, your cookies are still good for another 30 minutes or so, and BandAMP will think you're online until those 30 minutes go by.

We've all been bitten by the 30 minute timeout, but if I make it longer, then BandAMP will be less accurate at guessing who is currently online.  I can make absolutely sure that anyone using the logout link isn't accidentally counted, so this is for the sake of those who don't use that link.

In the end, I'd like users to have the ability to set how long their session lasts (default 30 minutes, but other options for days, weeks, or a whole month, or until they close their browser). 

Any thoughts?

I think the simple answer to that last one is to stop using the cookie to determine the on-line status. The cookie is about authorisation, the on-line status is about recent usage. For instance, you could store a "last access" timestamp by user instead. I would suggest you then set a shorter period for the on-line marker. From other contexts I would think 5-10 mins is about right.

That allows you to give the user full control over when their session cookie expires. I'm all for that.

Yeah, that's probably about what needs to happen.  Any other way we come at it, the guess won't be very good, or will restrict how much control the user can have over their login duration.