Authorization permissions corner cases
Sai Emrys
(How) can I capture these three permissions w/ authorization?
1. permit only guests (not signed in users), e.g. for the signup
page
2. permit only the user who has the identity relationship (e.g.
only user 2, or an admin, is allowed to access Users#show 2)
3. permit anonymous people depending on per-record setting - e.g.
some wiki pages can be anon-edited, some not (equivalent to
anon_user.has_role 'editor', bar_wiki, except there is no actual user
there)
Thanks,
Sai
Sai Emrys
read through the plugin code.
I decided that it simply doesn't do what I wanted.
... so, I hacked it to do so.
Enjoy:
https://github.com/saizai/rails-authorization-plugin/tree
http://saizai.livejournal.com/929444.html
- Sai
Glenn Rempe
Thanks for the patches. Since this appears to be a pretty massive set
of changes, can you report on how the test cases are working with your
new code?
http://github.com/grempe/rails-authorization-plugin-test/tree/master
If you can ensure that all of the existing tests are passing, and add
tests for the new API, I think you'll have a much better chance of
getting this merged quickly.
And of course, the group should take a look at Sai's hard work and
comment.
Thanks!
Glenn
Tim
I'm glad to see one more person adding features to the plugin :)
Just a couple questions after skimming the changes.
The change to process_role to special case handling of any role named
"guest" seems to affect any apps that would have a "guest" role for
user accounts. Was the :allow_guests option for
ControllerClassMethods#permit() insufficient for what you were trying
to do?
I'm not sure if I fully understand what AnonUser is trying to
accomplish. Is this a way to specify permissions for users that have
not logged in? If so, what are the advantages of this approach,
versus creating an AnonUser at the authentication (vs. rails-
authorization) plugin level? If you use the latter approach, you can
override your authentication plugin's current_user method to return an
AnonUser instance. I see two benefits to this:
1. You would avoid introducing the AnonUser checks to rails-
authorization.
2. Any non-roles logic that you want AnonUsers to have (such as
profile information or allowing them to post messages that show up
with the "Anonymous" author) could be added on the same user instance
as the roles stuff.
Thanks,
Tim
Sai Emrys
> I'm glad to see one more person adding features to the plugin :)
Scratchin' my own itch, as they say. ;-)
> The change to process_role to special case handling of any role named
> "guest" seems to affect any apps that would have a "guest" role for
> user accounts.
It shouldn't. My patch is in process_role, which happens *after*
process_role_of_model gets substituted in. Therefore 'guest' is only
special in the global case.
> Was the :allow_guests option for
> ControllerClassMethods#permit() insufficient for what you were trying
> to do?
The allow_guests option is nearly worthless, as far as I can tell. The
only thing it allows is the "not some_role" situation. This is
extremely rare, as it's generally a stupid idea to say that some of
your users can't do X but the others can and anonymous users can too.
After all, they can just log out, unless you're somehow fingerprinting
them well enough to force log them in.
Mine allows you to:
a) explicitly permit only guests, without adding any role to 100% of users
b) give guests arbitrary permissions, e.g. to let them edit certain
pages and not others
Neither of these are possible w/ the old version.
FWIW: in the fixed roles case, permit 'something' =~ /guest/ is the
same as allow_guest (i.e. it at least will get eval'd). However, the
regexp is weak, as I didn't try to figure out how to make it get
detected as a word proper; that could be improved. As is it can false
match on e.g. "permit guestacular" or something. I think that's
unlikely though, so I didn't bother.
If you use object roles, allow_guest is completely deprecated by my change.
> I'm not sure if I fully understand what AnonUser is trying to
> accomplish. Is this a way to specify permissions for users that have
> not logged in? If so, what are the advantages of this approach,
> versus creating an AnonUser at the authentication (vs. rails-
> authorization) plugin level?
Doing so at authentication means that, in order to support it, you
have to have anonymous users actually be logged in as a real user.
That's a bad thing, IMO; it breaks the whole notion of what anonymity
is. Anonymity is having *no* user, not having a *shared* user with all
other anonymous people.
Also, AnonUser is not an authentication. It's not a user. It's
explicitly the *lack* of authentication, and that is the correct
behavior IMO for the authentication system.
Consider simply: what user_id should an anonymous user's comment have?
To me the only sensible answer is 'nil'.
Anon users do not *have* a name or a profile or preferences or any of
that; how you choose to display that fact is of course overridable (I
sometimes use e.g. 'user.name rescue 'Anonymous'', sometimes leave it
be nil). You could also monkey patch AnonUser to add a def self.name;
'Anonymous'; end.
IMO the only thing anonymous users have, as a coherent class, is
whatever you attach to a session and whatever you permit them to do.
They share none of the other privileges of real users (e.g. do
anonymous users have a 'mailbox' or 'friends'? surely not, unless
you're actually talking about *psuedo*nymous or nonce users, which is
very different).
> 2. Any non-roles logic that you want AnonUsers to have (such as
> profile information or allowing them to post messages that show up
> with the "Anonymous" author) could be added on the same user instance
> as the roles stuff.
My patch already allows this, without a user instance that isn't
actually a user and therefore would need to be hardcoded as a special
case psuedouser.
> On May 3, 9:52 pm, Glenn Rempe <gl...@rempe.us> wrote:
> Thanks for the patches. Since this appears to be a pretty massive set
> of changes, can you report on how the test cases are working with your
> new code?
>
> http://github.com/grempe/rails-authorization-plugin-test/tree/master
>
> If you can ensure that all of the existing tests are passing, and add
> tests for the new API, I think you'll have a much better chance of
> getting this merged quickly.
I'm running the tests under rails 2.3.2. I had to make a couple
changes to support that:
* mv application.rb application_controller.rb
* class ActiveSupport::TestCase / ActionController::TestCase on all
the test classes
Done, fixed, and pushed; see below.
I'm not familiar enough w/ the testing framework to write good tests
for the anon user, so I'd suggest you do that.
One thing to note: the anon user does *not* (and cannot) have the
feature of having roles that haven't been saved yet (since there is no
user model to save).
Thanks,
- Sai
rake test
(in /Users/saizai/Dropbox/workspace/rails-authorization-plugin-test)
/usr/local/bin/ruby
-I"/Users/saizai/Dropbox/workspace/rails-authorization-plugin-test/lib"
-I"/Users/saizai/Dropbox/workspace/rails-authorization-plugin-test/test"
"/usr/local/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/rake_test_loader.rb"
"test/unit/group_test.rb" "test/unit/meeting_test.rb"
"test/unit/role_test.rb" "test/unit/user_test.rb"
Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/rake_test_loader
Started
.....................
Finished in 4.566783 seconds.
21 tests, 147 assertions, 0 failures, 0 errors
/usr/local/bin/ruby
-I"/Users/saizai/Dropbox/workspace/rails-authorization-plugin-test/lib"
-I"/Users/saizai/Dropbox/workspace/rails-authorization-plugin-test/test"
"/usr/local/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/rake_test_loader.rb"
"test/functional/account_controller_test.rb"
"test/functional/object_roles_controler_test.rb"
"test/functional/really_secure_controller_test.rb"
"test/functional/rest_controller_test.rb"
"test/functional/secure_controller_test.rb"
Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/rake_test_loader
Started
........
Finished in 0.609423 seconds.
8 tests, 16 assertions, 0 failures, 0 errors
/usr/local/bin/ruby
-I"/Users/saizai/Dropbox/workspace/rails-authorization-plugin-test/lib"
-I"/Users/saizai/Dropbox/workspace/rails-authorization-plugin-test/test"
"/usr/local/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/rake_test_loader.rb"
"test/integration/stories_test.rb"
Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/rake_test_loader
Started
.........
Finished in 5.036916 seconds.
9 tests, 122 assertions, 0 failures, 0 errors
Sai Emrys
I've added a couple extra convenience things since this; documented in
the readme, so just diff it vs main to see 'em. They shouldn't affect
extant API.
Like I said, all current tests pass, and this is major extra
functionality that addresses a real use case.
- Sai