[rspec-users] [rails] An authorization question

Chris Flipse cflipse at gmail.com
Sat Feb 28 14:54:48 EST 2009


I've actually been okay with it at the unit testing / rspec level -- I've
had it stubbed as you describe for a while.

The pain point came in as I was trying to setup data for Cucumber ... Which,
listening to my tests, tells me that the current structure is bad.  I was
more curious to see how others are handling that sort of situation.

I want to get *away* from the global variable, I'm just not entirely sure
what the target should be.  There doesn't seem to be a whole lot of talk
about actual implementation specifics around model level authorization.



On Sat, Feb 28, 2009 at 2:16 PM, David Chelimsky <dchelimsky at gmail.com>wrote:

> 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>
> > wrote:
> >>
> >> 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))
>
> or
>
>  User.stub!(:current).and_return(mock_model(User, :authorized? => false))
>
> etc.
>
> 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.
>
> HTH,
> David
>
> >>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
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >
> >
> >
> > --
> > // 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
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
// anything worth taking seriously is worth making fun of
// http://blog.devcaffeine.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090228/f8122624/attachment.html>


More information about the rspec-users mailing list