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.
Related
I am rebuilding a standard app in Rails (backend + rendering) and looking into creating API-only Rails backend and Node/React frontent.
I'm a little bit riddled on best practices here.
In my old app I had 2 devise models - User and Admin (admin was a separate namespace, so User would not have access to its controllers).
How would you recommend to implement sets of different controllers for admins and users?
Thanks
It always depends in the use case. If the admin has completely other tasks, it's better to create it's own namespace for them. If the admin does the same things as a normal user but with a bit more rights, I would handle the different authorization for both.
For example a user is only authorized to delete his own posts and a admin is allowed to delete all posts.
Currently I'm working on system, that uses ZendFramework2 Acl implementation for managing user roles and permissions for various parts of it. Till this moment it works as is supposed to do - giving or rejecting users based on their role. Recently we got a new feature request - implement functionality that allows permission management per user, regardless the role he or she has. Here comes the tricky part - Zend implementation of Acl doesn't met the requirements out of the box (if it supposed to do so at al). Just to note - system is already tightly integrated with the current model, so it will be pain of heart to use another kind permission management model.
So far the best solution I could think of was to represent individual users as roles in Acl and grant them appropriate privileges, so it is possible to dynamically create or delete resources and privileges for users, without impacting overall role permissions (which still apply).
Could I get some suggestions please? Is this the "right way" or there better approach to the problem? Thanks in advance :)
If an user by the fact to be himself has some privilegies, then you have to create a new role for that user.
I have just developed an ACL module that allows you to manage access to each route only creating a new key in each route called 'roles'. You do not have to configure the ACL creating allow rules manually, this module creates the rules automatically for you reading the routes.
You can have a look: https://github.com/itrascastro/TrascastroACL
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.
I am building a project management app and I am not sure which is the best/correct authorization model to implement given I am new to Rails (and programming in general). Here is what I am trying to do.
I want to be able to add a "client" to the application and then multiple projects to a client. I would like to be able to add users (that are essentially representatives of the client) to view that clients multiple projects but not other clients. I intend on having controllers for time tracking, notes, comments and images all to be associated with both clients and project of that client.
In addition, I would like to set up the account to control who is able to have one. I don't need the user to establish an account on their own.
Does that make sense?
I believe what you are mentioning is called Authorization not Authentication, anyway:
I would suggest acl9 for authorization and authlogic for authentication.
These (free) Railscasts should give you some food for thought. There are lots of great RubyGems/plugins out there for this sort of thing.
The Ruby Toolbox gives you an overview of tools and their popularity in the rails community (rated by watchers and forkers on GitHub). As you can see there, the suggested plugins restful_authentication and authlogic are almost on the same level.
Restful Authentication is still the golden standard for user authentication in ruby on rails.
I have used Authorization plug-in in the past and like it because it gives some nice meta methods such as:
user.is_eligible_for_what --> returns array of authorizable objects for which user has role "eligible"
user.is_moderator_of? group --> returns true/false
user.is_moderator_of group --> sets user to have role "moderator" for object group.
user.is_administrator --> sets user to have role "administrator" not really tied to any object.
There's also a brand new RailsCast on CanCan.
I'd use AuthLogic for authentication (logging in users and making sure they are who they claim to be) and declarative_authorization for authorization (making sure they have access to resources). See Ryan Bates' excellent Railscasts on AuthLogic and restful_authentication for more info.
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.