Yes Hobo permissions system does help but it does not automatically protect you from everything. The permission system does not kick in unless you use the hobo specific ways for modifying objects. For example creating objects through regular create does not use create_permitted. It took me a while to realize this and probably the documentation should have something about this. Of course security is such a thing that unless you are not intimately aware of the issues surrounding the framework you are using you will likely have holes somewhere (unless the application is trivial). The current system is a good step towards the right direction but maybe we would be able to cover the traditional rails code paths by default in the future too (that would be sweet).
On Sep 23, 7:38 pm, Matt Jones <[email protected]> wrote: > http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the... > > The first two are even more interesting when read in the light of Hobo's > internal permissions system, and the way it interacts with the view layer. In > particular, the second bug (mass updating the encryption key) is likely to be > stopped as a side-effect of not wanting that field to appear in autogenerated > views; you'd typically write: > > def update_permitted > (current_user.administrator? || ... ) && none_changed?(:serialized_key, ...) > end > > just to get the field to vanish, and get security as a bonus. :) > > --Matt Jones -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
