[rspec-users] [rails] An authorization question
dchelimsky at gmail.com
Sat Feb 28 14:16:36 EST 2009
On Sat, Feb 28, 2009 at 12:51 PM, Chris Flipse <cflipse at gmail.com> wrote:
> On Sat, Feb 28, 2009 at 1:38 PM, David Chelimsky <dchelimsky at gmail.com>
>> On Sat, Feb 28, 2009 at 11:52 AM, Chris Flipse <cflipse at gmail.com> wrote:
>> > I've been going back over some legacy code, backfilling tests, and I'm
>> > encountering something that is causing no small amount of pain. This is
>> > in
>> > a mature Rails app, that's lived and migrated from 1.1 through to 2.1,
>> > so
>> > there's a lot of ancient cruft built up in the corners that I've been
>> > trying
>> > to clean up.
>> > My question/pain point revolves around authorization. In at least two
>> > different models in the system -- areas that are core to the
>> > functionality
>> > -- there are models that run through a state transition. Only certain
>> > users
>> > are allowed to make those transitions, however. You're basic "only an
>> > admin
>> > can publish an article" kind of restrictions.
>> > These models show up across most of the app -- several different
>> > controllers. As such, long, long ago, someone patched updated the site
>> > authentication code to assign a User.current singleton inside the
>> > login_required filter.
>> Unless I'm missing something, this seems like the problem is wider
>> than testability.
>> Let's say I log in. Right now I am User.current. Now you log in, and
>> become User.current. Now I got to view some resource that I am not
>> permitted to see, but I get to see it because you are permitted and
>> YOU are the User.current.
>> Am I missing something?
> The login filter is called at the beginning of every request, from
> application controller. It resets the value, nilling it out if you're not
> logged in, at the start of each request. So long as Rails remains single
> threaded, the scenario you describe isn't possible. One process, one
> request at a time. No bleed there.
> Of course, they're supposedly working on making it not-so single threaded,
> so that may eventually become a problem. All the more reason to find
> something that doesn't suck.
>> > This is then used by several models, sometimes to
>> > populate an updated_by stamp, sometimes it's actually used within a
>> > models
>> > validations(!), and it's definately used within some of the
>> > state-transition
>> > guards.
>> > Now, this is really just a global variable by another name, and it's
>> > pretty
>> > well embedded after two years. I've come upon a whole bunch of
>> > different
>> > pain points in trying to setup data (real data) within the cucumber
>> > steps
>> > I've been backfilling. Lacking any support of injection, I end up doing
>> > a
>> > lot of juggling of the User.current value
You can stub this in your code examples:
User.stub!(:current).and_return(mock_model(User, :authorized? => true))
User.stub!(:current).and_return(mock_model(User, :authorized? => false))
Replace "authorized? => true/false" with whatever is necessary for the
authorization to pass or fail as needed in each example.
Stubs are cleared out after each example, so you don't have to use any
additional injection techniques.
>>just to get some test data
>> > built
>> > and in the right set of states ... and while I can bury the temporary
>> > reassignments necessary inside a block, it still feels like it's an
>> > intractable mess.
>> > I know *why* this was originally done -- to avoid having to pass User
>> > objects around all the time, and it does _appear_ to keep the API clean
>> > --
>> > but the hidden dependancy isn't really clean.
>> > So, does anyone have any suggestions of how to easily manage model level
>> > user authorization?
>> > --
>> > // anything worth taking seriously is worth making fun of
>> > // http://blog.devcaffeine.com/
>> > _______________________________________________
>> > rspec-users mailing list
>> > rspec-users at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>> rspec-users mailing list
>> rspec-users at rubyforge.org
> // anything worth taking seriously is worth making fun of
> // http://blog.devcaffeine.com/
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users