Ahhh..I actually read that, but thought this contribution was more on the conceptual level :-)
Thanks loads, I ll give it a try then Michael On 16 Feb., 13:55, "Sergio Cambra .:: entreCables S.L. ::." <[email protected]> wrote: > On Martes, 16 de Febrero de 2010 11:05:32 Atastor escribió: > > > Hi Sergio, > > > from what I gathered from various threads your security branch seems > > to have some authorization features I could really use for my rather > > involved (role and authorization-wise involved that is) application. > > Is there any doc or readme or whatever available or hidden in the > > tree? > > > Thanks > > Michael > > No, but I commented about that branch in this mailing list. Here is again: > > 1. authorized_for? called in a model should look for security methods at > class, instead of looking for instance methods in a new instance. This change > can be backwards incompatible. Code which returns true for new records won't > be affected, but code which hide links returning false for new records would > need to add class methods. Maybe I could add a method to restore current > behaviour globally. > > To be clearer, if you have authorized_for_action? methods like this > def authorized_for_create? > return true if new_record? > owner == current_user > end > Then it will work without changes, although you can remove the first line. > > If you have code with check permissions even in new records, you will have to > split the method in a class method and a instance method. > def authorized_for_update? > if new_record? > current_user.allowed_to_update? self.class.name > else > owner == current_user > end > end > This method would hide edit links to users which can't edit any model, and > show it to users with edit permission, enabling the link only for records > which user owns. It should be changed into: > def self.authorized_for_update? > current_user.allowed_to_update? self.name > end > def authorized_for_update? > owner == current_user > end > > Some bug reports due to current confusing behaviour will be avoided with this > change. And some strange problems with authorized_for_read? and links for > associations will be avoided too. > > 2. Using crud type to enable or disable an action link is not enough for > custom action links. I would look for security methods with action name and > crud_type. > > For example it will look for authorized_for_update? and authorized_for_edit? > for edit action link. > > If I want to add an action link to approve an order, I would set crud type to > update. Currently it would check permissions with authorized_for_update?. I > can't disable editing but enable approving with current schema. In security > branch I can enable approving with authorized_for_approve? and disable editing > with authorized_for_update? > > authorized_for_action? has higher priority than authorized_for_crud_type?, and > column_authorized_for_crud_type has the higher priority. > > -- > Sergio Cambra .:: entreCables S.L. ::. > Mariana Pineda 23, 50.018 Zaragoza > T) 902 021 404 F) 976 52 98 07 E) [email protected] -- You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" 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/activescaffold?hl=en.
