The Rails way according to dhh is "don't do that". I agree. Neither
approach makes any sense as the main vector for MySQL vulnerabilities
is an injection attack. Making the framework less general is both
dumb and counterproductive and provides no additional security.
I'd argue that we should just use finder methods and named_scopes in
the AR models rather than reinvent the wheel.
Tony
On Nov 5, 1:42 pm, Jeff Shrager <[EMAIL PROTECTED]> wrote:
> I got some more on this from the engineer who developed the other
>
> approach. He writes:
>
> ---
> The proposed method supports multi-tenancy with the explicit
> requirement for role-based permissions for all data views. On the one
> hand, the intellectual property of an individual or organization must
> be guaranteed. On the other hand, it must be possible to share
> information with an arbitrary granularity. All of this must be
> accomplished with reasonable database performance. Our model now
> assumes that some role is always current.
>
> Enforcing read permission cannot be accomplished as a post-query
> filtering operation. Not only would such a solution not scale, but it
> would potentially result in incorrect results being returned because
> of inappropriate intermediate results being incorporated as part of a
> join. Thus, for both efficiency and semantic correctness, we have
> engineered a role-based view as part of the data model, affecting
> nearly every query. This is most conveniently addressed in the Rails
> framework by appending a WHERE clause to the ActiveRecord :find
> operator (using the :conditions hook).
>
> To designate the classes under access control, I define an
> acts_as_access_controlled mixin based on a plugin downloaded from
> RubyForge. This has the advantage of being declarative, making it
> obvious which classes are under access control. At run time, a
> UserContext (we could call it something different) is dynamically
> discovered and used to bind parameters in the prepared SQL statement.
> This causes access control to be on by default, which I consider to be
> desirable because it is now part of the data model and should be
> routinely incorporated into queries during development and testing. An
> all-seeing ('root') mode is also supported.
>
> Tonyhas proposed an alternate mechanism to inject the same methods
> (or perhaps methods with an SQL string not requiring parameter
> binding)
> into the models from the application controller. [See above forTony's
> claims of the superiority of his method.]
> ---
>
> Opinions?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
