[rspec-users] [rails] An authorization question

Chris Flipse cflipse at gmail.com
Sat Feb 28 13:51:56 EST 2009


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, 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090228/f1cb6ee3/attachment-0001.html>


More information about the rspec-users mailing list