So, when we create a Mean.js app using the yo generator, there's a User module by default, that manages authentication, sign up, sign in, profile settings, etc.
We also have the option to add roles to the users in the users model, admin and user roles are set by default.
Users can self register to the app by default, now let's say I want to use the admin user to do CRUD ops on Users (create, read, update, delete new users, and make queries such as list users) and disable the sign up option for common users so only the admin can register new users.
I thought about two options:
create a CRUD module with yeoman (but this would cause trouble with the existing User module, that manages all this auth stuff)
do everything from scratch, like adding all the controlers, routes, and all the stuff needed (but this would take a lot of time and it could create lots of bugs cause I may forget something)
What would you suggest?
Mean.js 0.4.0 is the most recent version and it will have an admin module incorporated in a near future. I implemented one in my app similar to the one in this pull request. Take a look and see if it works for you.
Related
I'm building a website, where vendors can have their own separate website on. There is vendors and normal users.
The goal is to have a closed profile page w. login for both, where a vendor can edit his website, check out stats and more. A normal user is also able to login to mark different vendor's websites as favourites and check out newest post on the forum. So what is important here is: They booth need to be on my Discourse forum, but I'd like to avoid a Vendor to have a login both for vendor and for a user (Signing up twice).
http://www.discourse.org/ has SSO ability for devise, but im not sure if it allows for two different devise models.
Should I:
Create one devise-model for both, called Users? (And have a boolean or integer if User is a vendor/has vendor-access?)
Or:
Separate them: One for Users and one for Vendors?
I haven't tested out if Discourse allows for two devise-models, since Discourse is the easiest to set up in production-mode. But I need your advice: Can I use Single sign-on for devise with two different devise models? Is it the preferable way? Or is there other ways than this I haven't noticed? Like adding a user to a vendor, or something?
Using rails 5
We can achieve this by managing role field. We can make entry on the time of sign_up in role field that user is normal user or vendor. After create this we check user_role can in after_sign_up_path and redirect to path accordingly.
for this refer gem rolify
please correct me if getting any thing wrong.
In my project i have three different categories of users:
Guest
Registered
Admin
If a Registered user is logged in, I want to show them (if they click on a button) their orders.
The Admin instead can see the orders of all the users. I can use OrdersController to show things to the Registered user.
Is it necessary to create a new controller for the Admin , or I can use a if the user is a admin do this clause in the same controller(say OrdersController) that I use for the Registered users?
There's no single right answer to this question, it really depends a lot on your code, your app, your use cases, and a whole bunch of other detail that you haven't provided (and that this is not the best forum for).
So, generally the administration tasks are so distinct from the regular users that people create new controllers for them, usually under their own Admin:: namespace.
I am creating dashboard appliaction on Rails4. I have created model Partner with some data. I also have created a lot of models with views that will be associated to this Partner.
I can edit data of all models without any restrictions. Now I want to create Admin, that will login to my app and will manage data. Admins will be added via console and it does not need registration.
Also I want to make Partners to login/register too. Partners can only open pages that are connected to their data and edit them.
Here my questions depending on this situation:
How to remove registration element from Admins not affecting to Partners?
How to restrict Partners to only their own pages while Admins can be everywhere?
Is it good approach to make Admins and Partners to edit data on same dashboard, or I need to create different controllers with different views for Admins and Partners separately?
You should be able to do everything you're discussing by using a gem for handling authorization ( authority ) and one for roles ( rolify )
https://github.com/nathanl/authority
https://github.com/RolifyCommunity/rolify
You shouldn't have to create distinct views/controllers, however, depending on how divergent they are it may be appropriate. You should be able to do most of that logic by using logic to switch based on the permissions you set up.
current_user.can_edit?(page)
within the Authorization setup, you would have to determine who can edit/view/create/etc. There's a good writeup for doing this in the authority wiki.
I am working on a job portal. I am confused on how I should create and manage users. For example: there will be 3 types of users(which may expand later) in my application: Company, Consultancy, and Candidates. Each of them will have a completely different role and access to the admin(i.e. account) panel/console, or you can say they will have a completely different views for managing their account. So, if a user logs in with a company account, he/she should be able to create jobs and update company profile, if a user logs in as a consultant then he/ she should be able post jobs on behalf of other companies(who may or may not be registered on the website/app) and should also be to surf/ search the jobs from companies and should be able to post applications(i.e. apply for a job) of candidates on candidates(who may or may not be registered yet on the website/app) behalf. And, if a user logs in as a candidate then he/she should be able to create their resumes/ cvs, search jobs, and apply for jobs posted by companies.
Here is what I'd thought: Create a User model and then have STI(Single table inheritance) for Company, Consultancy, and Candidate. But, STI gets complicated sooner than later. Later, I thought of creating different models for each, but then code will be repeated for login/ signups and other similar activities, which means no DRY.
I would like to follow the best approach possible. So, would like to know how experts will go about solving such a scenario? Thanks.
Some suggestions:
Look at the CanCan gem for user roles.
Look at devise for a login system where you can login users.
You can use active admin gem to create an administration backend ( crud, create remove update delete ) users. Or build an admin backend yourself
Also checkout railscasts.com ( theres a cast on cancan and devise also!) for general ruby on rails tips and tricks. http://railscasts.com/episodes/192-authorization-with-cancan
Checkout "micheal hartl ruby on rails course " for some general understanding of how models, controllers and views all relate to each other.
I am new to rails and am wanting to make a training scheduling app. I need a user management system and am sure one exists as a gem but I cannot seem to find one with all of these needed features.
Multiple access levels (User, Trainer, Manager, Admin)
No user signup (Trainer, Manager, Admin will create accounts and the information will be emailed to users)
User groups (User, Trainer, Manager) belong to groups and can only manage users in those groups. Admin can manage anyone in any group.
Users can change details on their account and change their passwords.
Admins can determine how users will login (custom field, username, email)
Can use a mysql database
Is there any current gems out there with all this functionality or will a custom one need to be created?
You're combining two concepts here, user authentication and role-based access control. Consider using devise for authentication as it's quite configurable (you can disable the sign_up route and only allow sign_in, for example), and something like cancan for rbac.
Also, do you really need to allow admins to determine how users will login? Consider just settling on one method to start with, and adding this functionality later if it's a real priority.