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 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.
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.
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
that’s how you’ll get a single use URL
please till me if there is any hole in my logic
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.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
