I'm writing a Ruby on Rails application which allows a user to upload an
mp3 file, then play it back. I have it working to the point where a user
can do those things, BUT there is an issue when seeking through the
song. If a user seeks ahead (or lets it play) to a spot in the song,
usually about 2/3 or 3/4 the way through the song, then attempts to seek
back to the beginning (for example 0:20), the play timer will go to
0:20, like it should but the actual audio will start over again as if
the user seeked to 0:00.
Right now I'm simply attempting to get the song to play in chrome's
basic html5 mp3 player that it uses when passed an mp3 file. This is the
code I'm using to serve up the file, hopefully with all the correct
headers:
I think it has something to do with send_file not accepting the range
header, maybe it's just the way I'm setting it? I'd appreciate any
insight into this problem. I feel like I'm so close because it pretty
much all works, except for seeking near the beginning causing a new
request.
I'm writing a Ruby on Rails application which allows a user to upload an
mp3 file, then play it back. I have it working to the point where a user
can do those things, BUT there is an issue when seeking through the
song. If a user seeks ahead (or lets it play) to a spot in the song,
usually about 2/3 or 3/4 the way through the song, then attempts to seek
back to the beginning (for example 0:20), the play timer will go to
0:20, like it should but the actual audio will start over again as if
the user seeked to 0:00.
Right now I'm simply attempting to get the song to play in chrome's
basic html5 mp3 player that it uses when passed an mp3 file. This is the
code I'm using to serve up the file, hopefully with all the correct
headers:
I think it has something to do with send_file not accepting the range
header, maybe it's just the way I'm setting it? I'd appreciate any
insight into this problem. I feel like I'm so close because it pretty
much all works, except for seeking near the beginning causing a new
request.
Can you just pass the URL to the file, and not pass it through send_file? I've used
def download
if cannot?( :download, Title )
raise CanCan::AccessDenied
else
redirect_to @asset.source.expiring_url(10)
end
end
from Paperclip to handle a link to a protected file on S3. Works like a charm, and it's just a file download from S3, so it's up to the browser to handle that.
I think I like what you're saying, but the only problem I have with it
is controlling access to the paperclip url. This may mean I just don't
understand how the paperclip urls work. But I'm also trying to ensure
that only the user who uploaded it, can access it. I wasn't sure if I
would be able to control this once a url for an audio file was exposed.
if you are asking about how to restrict access to a file -in your case MP3 file-
i just made a solution couple monthes ago with PHP that you may re implement
create a table with fields ( path , token)
for every request of a file create a token for it with that path in that table
create a controller that get the token as parameter and download the file
when user access the url through that controller you’ll delete the record
make the controller show 404 if the token wasn’t in the table
you can add a column for user id in case the file is available for multiple user
I think I like what you're saying, but the only problem I have with it
is controlling access to the paperclip url. This may mean I just don't
understand how the paperclip urls work. But I'm also trying to ensure
that only the user who uploaded it, can access it. I wasn't sure if I
would be able to control this once a url for an audio file was exposed.
That's the beauty of how this works. When you save the file to S3, you have two basic options. Usually, you want these to be world-readable, so you pass
:s3_permissions => :public
in your has_attached_file call.
But if you pass :private instead, then the file can only be accessed through your S3 credentials. Okay, now only your app can read it. But that's what the expiring_url method is for. That gins up a one-time token that expires in N minutes, and allows one download during that window, after which it simply won't work at all. Your keys are used to create this token, but it's a one-way hash so you don't have any leakage possible of your actual credentials.
But if you pass :private instead, then the file can only be accessed
through your S3 credentials. Okay, now only your app can read it. But
that's what the expiring_url method is for. That gins up a one-time
token that expires in N minutes, and allows one download during that
window, after which it simply won't work at all. Your keys are used to
create this token, but it's a one-way hash so you don't have any leakage
possible of your actual credentials.
Walter
I think the only problem I have left is that I was hoping to not use S3
and be able to store the files on my own server.
Thanks for the response, I actually have the restricted access part working. My problem is getting Send_file to use the content range header so that when someone seeks to a location in the song that causes a new request it doesn’t just restart the song from the beginning, but from the actual location what was ‘seeked’ to.
