[rspec-users] [rails] An authorization question

Ben Mabey ben at benmabey.com
Sat Feb 28 15:42:40 EST 2009


Chris Flipse wrote:
> 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.

If you are seeing state from one scenario bleed over to the next I would 
suggest something like this in your env.rb:

After do
 User.reset_current
end
>
> 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.

I generally have a current_user method defined of my controller to 
return the logged in user.  Assuming that your app is only using 
User.current in your controllers you could try to move towards something 
like that... If you have models accessing User.current then it truly is 
being used as a global. :/  The user will then have some permissions 
methods that may take other objects or symbols.  The method will simply 
return a boolean telling if the user is authorized or not.  That logic 
usually is based on the role(s) of that user or relationship with the 
passed in object.  Having this logic in the user could be viewed as a 
responsibility issue- should the user really be responsible for telling 
if it is authorized for everything?  In general I do this for most 
simple cases.  Only when it starts to get complex do I move it out into 
a Manager-like object.

HTH,
Ben

>
>
>
> On Sat, Feb 28, 2009 at 2:16 PM, David Chelimsky <dchelimsky at gmail.com 
> <mailto:dchelimsky at gmail.com>> wrote:
>
>     On Sat, Feb 28, 2009 at 12:51 PM, Chris Flipse <cflipse at gmail.com
>     <mailto:cflipse at gmail.com>> wrote:
>     >
>     >
>     > On Sat, Feb 28, 2009 at 1:38 PM, David Chelimsky
>     <dchelimsky at gmail.com <mailto:dchelimsky at gmail.com>>
>     > wrote:
>     >>
>     >> On Sat, Feb 28, 2009 at 11:52 AM, Chris Flipse
>     <cflipse at gmail.com <mailto: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 <mailto:rspec-users at rubyforge.org>
>     >> > http://rubyforge.org/mailman/listinfo/rspec-users
>     >> >
>     >> _______________________________________________
>     >> rspec-users mailing list
>     >> rspec-users at rubyforge.org <mailto: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 <mailto:rspec-users at rubyforge.org>
>     > http://rubyforge.org/mailman/listinfo/rspec-users
>     >
>     _______________________________________________
>     rspec-users mailing list
>     rspec-users at rubyforge.org <mailto: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



More information about the rspec-users mailing list