Closed taylorthurlow closed 6 years ago
Hi @taylorthurlow. I will attempt to replicate and then get back to you.
Hi @staturecrane, any chance that you've been able to take a look at this? Sorry to bother.
Alright, I did some poking around the source and I found the source of the issue. It's a problem with the filestack
gem, and I've opened an issue there and will be submitting a pull request shortly.
This issue is caused by passing a hash with string keys and not symbol keys. The documentation in the readme uses string keys:
config.filestack_rails.security = {'call' => %w[pick store read convert] }
If you are to try and include an 'expiry'
key, it will be ignored. Use :call
and :expiry
instead:
config.filestack_rails.security = {call: %w[pick store read convert], expiry: 123454321 }
Hi, I'm on Rails
4.2.1
, Ruby2.3.1
, and filestack-rails3.1.0
. I'm setting up inapplication.rb
as follows:As far as I can tell, this is exactly how to define your own expiry. According to this epoch converter, 4663446066 corresponds to 100 years from the current date. Despite this, the server is still using a one-hour expiry. This is evident in the fact that I can no longer delete files (all I'm using security for at the moment) after an hour, and also from a quick look at the policy it generates:
Plugging this policy into the helper form on filestack's developer portal, tells me that this policy code represents:
{"expiry":1508641608,"call":["pick","read","stat","write","writeUrl","store","convert","remove","exif"]}
Which is the expiry length for 1 hour. Am I doing something wrong?