[rspec-users] [rails] An authorization question
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>
> >> > 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
> >> > in
> >> > a mature Rails app, that's lived and migrated from 1.1 through to
> >> > 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
> >> > 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
> > 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
> > 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
> >> > 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
> >> > --
> >> > but the hidden dependancy isn't really clean.
> >> >
> >> > So, does anyone have any suggestions of how to easily manage model
> >> > 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
// anything worth taking seriously is worth making fun of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users