I would like to use CanCan on top of a Mongoid based Rails 3 application. I would like to introduce general models for user, role and privilege. Essentially the authorization system shall authorize at a per action base. Therefore we want to store action x roles privilege objects.
Now when it comes to the ability DSL we could generate the abilities dynamically as an after_save hook in the proivilege model. But this results in a problem in production mode, cause these runtime changes only affect the server process where the privilege changes were made.
On the other hand one could reevaluate all (the users) abilities as before_filter in every controller. But that slowed down every request.
Just now, we are undecided how to solve this problem. I am thankful for every suggestion.
Regards
Felix
CanCan uses a simple authorization system based on a role column on the User model.
Here are some good links:
Abilities
Role Based Authorization
Why do you need to dynamically set up privileges? Unless you have a compelling reason to do so you are just introducing unnecessary complexity. Just define the roles you need to with the correct abilities (you can do this on a controller/action basis with cancan) and then assign those roles upon creation/update.
Related
I'm building an API management apps where every user able to find their own token for making an API request. Every end user will have to manage their own API access, they should also have access to many other custom endpoint.
At the moment, the Rails Admin is being used for the internal administration. Such as CRUD of "AdminUser", "Payment", and other internal system management.
The question is: Should I use Rails Admin's feature for this functionality (as in exposing admin control to every regular user)? Or should I just create a separate admin section for the general user with a standard form?
I'm not very experienced in Rails Admin implementation. So, I wonder if I should use it too for the end user.
Thanks for your time & help!
Update
Some of my basic concern about using Rails Admin to me is that: Rails Admin is for developer or internal adminstration. There will be some risk of giving a wrong permission to the end user
Rails Admin is a quick and easy way to access all the data in your app. It can be customised to restrict access to certain models or fields, however you will have to use the Rails Admin DSL for that, and it kind of defeats the purpose of using Rails Admin if you need to do lots of customising.
A danger is also that if you did not set it up properly, the default is to expose all data to the users.
Since the functions you want to expose to the user doesn't sound too complex, it wouldn't be too much effort to write your own.
I'm quite new to rails and I'm trying to setup an authorization system that allows me to control which attributes of a model can be modified by a user.
I use declarative_authorization for a role based authorization. This already provides me quite a lot of functionality: restrict what the user can see in the view depending on his roles, which actions he can perform in the controllers and basically also which actions he is allowed to do on the model.
However, I just can't find an answer on how to restrict the actions on specific attributes of a model depending on the role.
Example:
A user that has a :guest role is allowed to update certain attributes of a user-account: When he tries to log in with a wrong password, I want to update a specific field of a user-account that will make this account inactive. The :guest role should however never be able to change the nickname of this user account.
I therefore use the "using_access_control" method in my user-model, but this either gives "update" privileges on an account for all attributes or no "update" privilege at all depending on the role.
I understand that "strong_parameters" is a gem that would basically make such functionality available but I have no clue on how to fit both "declarative_authorization" and "strong_parameters" together or how to do it simply with "declarative_authorization".
Can somebody point me to the solution?
Many thanks!
Authorization::Maintenance::without_access_control do
# do something
end
I hope this was helpful.
I'm working with a Rails 2.3 app that is already using declarative_authorization to handle user permissions. Each user belongs to one group (no fancy roles) with permissions on certain models, mostly the regular CRUD actions, but with a few special ones. This all works fine with declarative_authorization in it's usual out of the box mode.
We now want to allow admins to set permissions on particular groups of users with regards to model types. For example, we create a new group Foo, assign some users to it, and then decide with checkboxes if users in group Foo can c/r/u/d objects of model Bar.
I've used acl9 before, and I think I see how I could make that work. I've been a fan of CanCan lately, but I don't see how do it easily with that. If declarative_authorization can do this, I'll stick with it, but I'm prepared to bite the bullet and switch.
What plugin would be the best way to accomplish this? Is there a way to get declarative_authorization to do the job? An elegant way to use CanCan? Are there any gotchas I should watch for, e.g. database performance?
I could be convinced to upgrade the app to Rails 3.1, but I'd prefer to find a 2.3-compatible solution.
I've seen some similar questions, but no satisfactory answers
Rails Dynamic Role-Based Authorization plugin?
and this, for cancan
https://github.com/ryanb/cancan/wiki/Role-Based-Authorization
I'm a fan of the StoneWall gem - authorization checks are in the form of a Ruby block, so in that block you could look up records and see if the user in question has authorization.
There's not a lot of documentation, but the idea is:
a_user_object.may_read?(object)
If object is a Todo instance, then Stonewall will look int the Todo model and execute the read block
# app/models/todo.rb
stonewall do |s|
s.action :read do |todo, user|
todo.owner == user # only the owner of a todo item may read the item
end
end
This approach makes two things easy:
read is just a Ruby block, so whatever you want to happen can happen
actions can be given arbitrary names, so if you want to check to see if a user has permission to comment on a todo item (for example), just create a s.action :comment and access it with a_user_object.may_comment?(object)
I'm looking for a plugin that provides a role based authorization mechanism for securing read/write access to attributes. I'm picturing something along the lines of declarative_authorization for white listing attributes of model objects. I've spent some time looking around but have come up short, does anyone know of anything?
EDIT: I'm using declarative_authorization to control which users have access to what actions in the controller, but I need something similar that provides access control to the attributes of each model object. I'm trying to prevent information leakage through the web API or users from crafting malicious posts. I can do this through the mass_assignment_authorizer but I was hoping some plugin did this already.
CanCan Branch 2.0
https://github.com/ryanb/cancan/tree/2.0
Edit:
The continuation of CanCan is called CanCanCan.
See https://github.com/bryanrite/cancancan
What about creating a model / controller pair for each controller, and then allowing each role only to access methods in its controller(s)? Then you can make a before_filter in each controller that makes sure each user has permission to use methods in that controller.
I think the answer is an admin login and then check if the user has an admin flag, but I also thought of some other related questions.
Is it better to have an admin flag (attr_protected) in the same user table as non admins? or should i have an admin users table?
Should I create a separate rails application for the admin users? This might be overkill since they will both have to access the same datbase (not to mention it might be a huge pain to set up).
Any other suggestions? Right now I just need to secure a page or two so I even looked into HTTP basic or digest authentication as a temporary measure (the protected content is actually not THAT private/important). But... I don't know how to implement HTTP auth for specific actions, I have only seen how to implement it to prevent directory access.
Any direction and discussion would be great. I am sure other Stack Overflow users will benefit from this discussion.
Thanks!
Ryan Bates has a great three part series of Railscasts on this topic which should give you some food for thought:
Part 1: Where Administration Goes
Part 2: Restricting Access
Part 3: Super Simple Authentication
There are also three Railscasts on different authentication techniques:
RESTful Authentication
HTTP Basic Authentication
Authlogic
I'm using restful_authentication plugin for this purpose. And it is very simple to restrict access to any controller or any method. On example in controller add this function:
private
def authorized?
user.admin?
end
or
private
def authorized?
user.admin? if update? || create?
end
I defined admin? method in my User model. I also created update? and create? methods that check which action was called. In restful_authentication authorized? method is always run when accessing controller.
I would put everything in one application and in one table (don't create users and admin table). You can secure admin flag in your users controller by allowing to set this value only for existing admin users.
I think it depends on the type of administration.
If the view your administrators will have of the site is the same as a normal user's, but with additional privileges, I would go with an admin flag. (Or, as your needs expand, a full-fledged roles table.) This is a situation where everybody sees the same stuff, but administrators have access to various actions (delete? edit? ban? etc.) that normal users do not.
If the view your administrators need is wildly different than the normal site, I would recommend a completely separate Rails app that accesses the same database. For example, if your "administrators" are really help desk employees that are going to answer phone calls or deal with billing questions, they may have completely different views of the database (and perhaps ways to edit the data) that aren't available in the regular application.
The disadvantage to having multiple sites is that it is possible to have models (validations, associations, etc.) get out of sync. The disadvantage to having a single site is that you may end up inserting all sorts of ugly "if-admin" code in previously easy-to-understand portions of your site. Which problem is easier to handle depends on your requirements.