Skip to content
Commits on Apr 6, 2011
  1. @jyurek

    Version 2.3.10

    jyurek committed Apr 6, 2011
  2. @jyurek
  3. @jyurek

    Version 2.3.9

    jyurek committed Apr 6, 2011
  4. @jyurek
  5. @jyurek

    Appraisal gemfile changes.

    jyurek committed Apr 6, 2011
  6. @jhawthorn @jyurek
  7. @jhawthorn @jyurek
  8. @geemus @jyurek

    WIP fog integration

    geemus committed with jyurek Nov 28, 2010
Commits on Mar 9, 2011
  1. @alindeman @jyurek
  2. @jyurek
  3. @jyurek
  4. @jyurek

    selectively reprocessing attachment styles

    yar committed with jyurek Mar 7, 2011
  5. @jhawthorn @jyurek
  6. @jhawthorn @jyurek
  7. @jmileham @jyurek
Commits on Feb 16, 2011
  1. @jyurek

    Merge pull request #407 from reenhanced/paperclip

    ---
    
    When an attachment has an uppercase extension and a default style, the to_s and url methods do not match when a size is not passed in. This contains the test and fix for this issue.
    jyurek committed Feb 16, 2011
  2. @jyurek

    Merge pull request #411 from francocatena/paperclip

    ---
    
    I added lambda support to the size and content type validator, so now you can do something like:
    
    <code>validates_attachment_size :avatar, :less_than => 2.megabytes, :message => lambda { I18n.t(invalid_image_size) }</code>
    
    This is consistent with Rails validators, wich receive either a String or a Proc.
    
    Regards.
    jyurek committed Feb 16, 2011
  3. @jyurek

    Merge pull request #416 from jmileham/paperclip

    ---
    
    Hi there,
    
    Im building a site that needs to securely obfuscate attachments in a public S3 bucket.  The solution I arrived at seems like it might be useful to the community as a general-purpose tool that remains customizable enough to allow developers with different requirements to implement it differently without having to hack into Paperclip core.  It is a set of storage-agnostic extensions to Attachment and Interpolations and supporting tests.
    
    It features:
    
      * No extra data model required
      * Choice of HMAC digest algorithm on a per-attachment basis via openssl (modeled after ActiveSupport::MessageVerifier, default algo is SHA1)
      * Choice of fields to include in the hash on a per-attachment basis, which permits many developer-selected tradeoffs between security and flexibility -- some examples:
        * `:hash_data => ":class/:attachment/:id"` - Unique per asset, long-lived filename with deducible style URLs (e.g. you want a 3rd party site to be able to generate style URLs from a single URL trunk that you provide once and always get the latest attachment)
        * `:hash_data => ":class/:attachment/:id/:style"` - Adds non-deducible style URLs (e.g. you want to store uncompressed :originals but dont want end users to be able to find them and kill your bandwidth bill)
        * `:hash_data => ":class/:attachment/:id/:style/:updated_at"` - Adds non-deducible versions (e.g. if a users private profile photo URL makes it out into the wild via a malicious friend, they can unfriend, upload a new photo and the leak is plugged) -- this is the default
    
    Since the hashes are extremely unlikely to collide, you can also remove other elements of the `:path` that were previously required for global uniqueness (like `:id`), which can give your users plausible deniability of ownership, or even completely obliterate the directory structure (`:path => ":hash"` -- or less controversially `:path => ":hash.:extension"`) such that an attacker cant even prove what kind of attachment he/she has gained access to.  Paired with a large `:hash_secret` and HTTPS, your users are left with a similar security guarantee to the analog hole -- attackers would need an authorized-user mole, or would need to compromise either your server-side secret or an authorized users machine in order to gain access to protected attachments, and then would be able to freely distribute them (sadly, using your hosting infrastructure as an accomplice).
    
    ### The `:timestamp` bug
    
    While building this, I ran across what I think is a bug: The `:timestamp` interpolation is non-deterministic in the presence of per-thread time_zones, e.g. displaying time zones per user location, which would affect any such site that uses `:timestamp` in an attachment :path or :url (or if I had used `:timestamp` in `:hash`).  While using `:timestamp` in paths and URLs is probably a little-used feature given the general wordiness of `Time#to_s`, and the intersection of sites that attempt to use it as well as implement per-user time zones is a vanishingly small slice of Paperclip users, I think its worth taking a look at.
    
    I took a stab at dealing with it by adding a new attachment config parameter `:use_default_time_zone` (defaulted to true) that explicitly churns out :timestamp interpolations in the server-wide default time zone.  This is not perfect, because its possible that a site owner would want to change the default time zone via `config.time_zone=`, which would in turn invalidate all of their existing attachment URLs.  One option available to such an implementor would be to redefine my new method `Attachment#time_zone` explicitly to meet their requirements.  Or I could add a `:time_zone` option on `Attachment`, defaulted to null, and falling through to the present `Attachment#time_zone` implementation.  Such an option could even optionally take a block a la `options[:url]` and `options[:path]`.
    
    While the ideal path for `:timestamp` is unclear to me as Im not deeply familiar with the design philosophy behind Paperclip or the direction it wants to head in (aggressively fixing holes like this or supporting users who may rely on legacy behavior?), it seemed natural to me to expose the integer `Attachment#updated_at` value as an interpolation as an alternative to `:timestamp`.  Epoch seconds dont carry any time zone information and are therefor immune to this issue, plus theyre presumably faster to convert to than text, and fewer characters to hash to boot.
    
    So my present implementation has a provisionally "improved" behavior for :timestamp (which should be backward compatible for everybody who didnt run into the bug personally), and a new `:updated_at` interpolation that merely exposes the existing `Attachment` instance method.  Id be eager for feedback on what if anything should be done with that stuff.
    
    The caveats:
    
      * Im pretty new to testing, and this was definitely my first time writing tests using shoulda and test/unit.  Feel free to slap me for transgressions in style and abuse of mocks/stubs/fakes/dummies.
      * I tried to follow house style to the extent I could derive it, but Im sure I got it wrong in places.
      * Im not sure what went on with the appraisal gemfile.locks reverting to an earlier version dependency on Rails -- perhaps this is expected?  Again, never used appraisal before either.  Tips would be more than welcome.
    
    Id be very excited if you see some or all of these changes as valuable to the Paperclip mainstream, and am happy to iterate this into something worthy of pulling.
    
    Thanks a lot!
    
    -john
    jyurek committed Feb 16, 2011
  4. @jyurek

    Merge pull request #418 from sleeplessgeek/paperclip

    ---
    
    Updated README to make this requirement more noticeable and to explain how to make sure Paperclip has access to its utilities.
    jyurek committed Feb 16, 2011
Commits on Feb 11, 2011
  1. Made the ImageMagick requirement more prominent

    Nathan Long committed Feb 11, 2011
Commits on Feb 10, 2011
  1. @jmileham

    Adds secure :hash interpolation and fixes time zone brittleness in :t…

    …imestamp interpolation
    jmileham committed Feb 10, 2011
Commits on Feb 4, 2011
  1. @francocatena
Commits on Feb 1, 2011
  1. @armyofgnomes
Commits on Jan 31, 2011
  1. fix <attachment> markup in events section

    Chad Pytel committed Jan 31, 2011
  2. Revert "fix the <attachment> stuff for markdown"

    This reverts commit 1cdabfc.
    Chad Pytel committed Jan 31, 2011
  3. fix the <attachment> stuff for markdown

    Chad Pytel committed Jan 31, 2011
Commits on Jan 19, 2011
  1. @mjankowski

    thank the contributors

    mjankowski committed Jan 19, 2011
  2. fix the link to rdoc

    Chad Pytel committed Jan 19, 2011
Commits on Jan 14, 2011
  1. @jyurek
  2. @tilsammans
  3. @tilsammans
Commits on Jan 2, 2011
  1. @croaky
Commits on Dec 30, 2010
  1. @jyurek
Something went wrong with that request. Please try again.