tashfeen.ekram wrote: > hmmm. what you mention does make sense. perhaps i will roll my own. > > however, i would like to completely understand. so, ideally the > encryption should work such that all of the active record attributes > work as expected. when retrieving an attribute you would get the > expected object. > > i dont have any experience to do such a thing. any references of of > other gems doing anything remotely similar to this?
I don't know of any specific gems. I was just thinking conceptually as follows: 1. User enters, obviously, clear text into a form field. 2. User submits form over SSL to ensure encrypted transmission. 3. Rails stack processes data into the params hash. 4. Controller sends "save" message to ActiveRecord instance. 5. ActiveRecord/ActiveModel callback chain (e.g. before_validation, after_validation, before_save, after_save, etc.) all occur as normal. 6. Either inside or after validation, but before save, encryption occurs. One possibility would be for a gem to add a couple of new callback hooks to the chain. Maybe something like before_encryption and after_encryption. But, that's probably not even necessary in this case. If I were to implement something like this I would probably call my encryption routine from within after_validation. This should occur before the data actually gets saved to the database. If some problems occur during encryption then after_validation should return false having the effect of canceling the save. At that point "save" should also return false and you're controller should handle that in the normal way. You would also need some way to decrypt the data after a "find" operation. I don't think that Rails has any built-in hooks for this, but I could be wrong about that. I used to use a ORM called Enterprise Objects (EOF) that supported such a mechanism though use of the delegate pattern. There was a delegate method "awakeFromFetch()" that EOEnterpriseObject subclasses could override to perform initialization after fetch. This provided a nice place to "hook in" to perform these kinds of things. But, I can't think of any such convenience in Rails, but that's not a "show-stopper." P.S. Out of curiosity I looked at the stongbox gem. From a quick glance I don't think it would be something that would interest me. It uses public key technology, which I just don't see the benefit of using given it huge trade-off in performance. I really think a symmetric key system would make a lot more sense for most cases. I could certainly be missing some important point, however. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
