When is it okay to use multiple devise models?
I have 3 types of users - users, vendors and admin. Vendors have a bunch more fields than users so I want to have separate tables for them. Users can sign up and sign in using facebook (vendors cannot). And users and vendors share the same sign-in page/form.
I started with multiple devise models, got confused how to handle a single sign-in page, and then read a lot here about using polymorphic associations and STI instead of discrete models. I'm still confused as to when each approach should be used and what would work better here... i know its a little vague, any advise would be great though, or any good links..
Users also fill out a bunch of extra fields when they sign up - even through facebook. How can I keep track of those fields for an omniauth login? (and should I use devise for this or something like omniauth identity..?)
Thanks for looking at this! I'm a rails newbie setting up authentication first time, really appreciate the help
Depending on the case it is recommended to separate or use a single model. The alternatives:
Use separate models, override the controllers, so firstly you check if the record match in User, and if it doesn't match try with Vendor
Use a single model for storing User and Vendor, use a boolean (a string if it is a polymorphic association) to check the kind of user, and add related models in order to store the additional fields
I think option #1 is easier but bigger, and option #2 is a little bit difficult but shorter.
Also, it would be a good idea to separate the models because User connects to FB and Vendor no, it represents a lot of differences.
In another way, the searches will be faster using option #2, because it will be only 1 query, and the table will be light because it will not contain the specific fields for users and vendors; you also have to consider this in order to make a decision.
For Admin you can follow a similar criteria.
Check this out: https://github.com/mkdynamic/omniauth-facebook
Related
I am trying to implement a feature to my project (kind of like a social media site) that could be either basic or complex and I am not sure if I am going to take forever reinventing the wheel or just go on a crazy tangent that won't work. I just need to "check in" so to say.
I am going to use Facebook terminology as an example to simplify the concept but implement similar features with different names. In Facebook you have Pages and Groups, which are similar yet have slight differences (from now, I will call the collection of these DataSets). Both of these can have multiple admins or followers, which are all User roles, and each User can have roles for multiple Groups and multiple Pages (one role per Group or Page). Then for example, you can click a drop down to change your account to post as a Page you are an admin for.
Essentially, the concept I am describing is where a single User can have a role for multiple different types of DataSets. For example, a single User could follow 30 different Pages and 10 different Groups, and be an admin for one Group and two Pages. Does the concept I am describing belong to a particular concept or software design pattern? I am finding it really hard to describe this feature without using Facebook examples.
I have a strategy to implement this type of functionality in Rails, but I feel like using this strategy would be making the problem harder than it is and there is a fancy rails way of doing it, or a Gem, but I just don't know how to research it due to lack of terminology to describe my problem.
Current strategy is:
I have a Users table from Devise. Pages and Groups are each individual models and have their own tables. I have matching database tables to make the many-to-many relationships between Pages and Users, along with Groups and Users (e.g. 3 column design, column for the user_id, column for the page_id and the type of relationship such as admin or follower). Let's call these Group_User and Page_User. I am being flexible at the moment as I may add more DataSets similar to Page and Group.
Then for the Devise User table, I have an extra two columns to track the DataSet that the User is an admin for and currently posting as. One column is for the DataSet type and the other for the id for this instance (e.g. [Group,1] is stored in these two columns to represent Group with group_id:1 and [Page,3] is used to represent Page with page_id:3). These two columns can be checked when displaying options relevant for admins in that Group/Page and a simple drop down at the top of the site changes the values in these columns to any of the Pages/Groups the logged in User is an admin for. This way, one User login can take on many admin roles and change between these easily as needed.
Is there a better way to do this in Rails, such as a gem or specific design pattern? Or am I on track to implement these features myself? I think I understand the problem but my solution just seems simple/raw and possibly might have unintended consequences later down the track (e.g. it seems database intensive).
One way I was thinking of doing this was making a concern that includes methods to build the relationships and pass in the name of the DataSet as an argument, just so I am not rewriting the same methods for Pages, then Groups, then whatever comes next.
I looked at other solutions such as polymorphic typing (which I think is good for if each user only had one role or only managed relationships for one group or one page) and Single Table Inheritance (but I think my Pages and Groups might be too different for this to work). I thought about using inheritance as well (e.g. a parent for both Group and Page) but I am not sure this helps much.
I am just a guy that studied too much computer science and not enough software engineering. Any tips on how to simplify this problem or just a simple "yeah that will work" would be really helpful!
I think you are going great in the database design. Once participated in a social media application like yours which had similar type of design. Your design seems much better than the one I worked with. In my opinion this type of applications are supposed to be database extensive.
There are several design patterns used in RoR. One I heavily use is Service Object Pattern to maintain thin controller and models. Also it helps me to write reusable class.
Another one I like is the Presenter Pattern to simplify views.
You can have a details look at this blog post for more design pattern ideas.
I'm fairly new to rails. I'm having problem on designing the model classes. So this app will be used by 5 different users(Students, Teachers, Head and Coordinator). They each are different users to login into the website and have different functionality (example: Head makes an event. Students register for an event. Coordinator sets who can be head etc). I have created all four models with USERNAME and PASSWORD on each models.I don't have user model right now because the users in this app are these 4 models. Now, while making login page, i'm having hard time on implementing the best way to authenticate the users. For example, If a Head puts its login credentials, the app should identify that user that logged in is Head. What approach will be best to encounter this?
Also, after not figuring out the way to approach this. I was thinking of using devise and CanCanCan gem. But the same promblem comes in even if i use this gems.(i maybe wrong)
Do not create multiple models for different kinds of users. This is almost always not what you want. Instead add a column called role of the type enum which contains all of the kinds of roles you want to add like Sergio pointed out. Your comment about having too many attributes on one model is a non issue compared to the one you are planning to create with 5 user models.
It sounds like you are possible putting too much data on the user model if that is your concern
and have different functionality (example: Head makes an event. Students register for an event.
For this you want a permissions system such as cancancan where you can specify which features of the website each role has access to.
I have seen regular debates about the way to manage the different class of users.
Usually, it seems that developers prefer a role based approach (e.g. user, admin,...) with gems like Cancancan
But I'm wondering if it's applicable for an appointment booking app (appointment for doctors, teachers,... or even bookings). Indeed in this case, the 2 types of users have access to totally different pages. In its documentation about associations, Ruby on Rails guide takes the example of a medical appointment booking app with 1 table for doctors and 1 table for patients.
For this kind of app, I'm a little bit lost regarding the most efficient solution!
Thanks!
You can use a tool like Cancanan to break out the different roles and abilities, then restrict access to certain parts of the system based on those rules.
Additionally you can display only the relevant navigation or pages when the user's accessing the system so they might not even be aware of what they're not seeing.
If I want to build a Rails app that has two different types of users, let's say one type is called players and the other one is owners, what is the best and most efficient approach to modeling the app?
Things to take into account:
There should only be one Login, but different Registration forms that Owners/Players can use.
Owners can have access to a control panel but Players cannot.
Owners cannot share any of Players capabilities, but both need to be able to perform Login/Registration.
I am not using Devise, so please do not suggest it.
Different Approaches I've considered:
Using cancancan gem, but it does not really seem to meet my needs in the sense that I am not looking to create a user/admin hierarchical approach but rather a if you're a Player, then you can see these pages and perform these actions but Owners cannot and vice versa. Almost like splitting the app in two. cancancan seems that it would treat Owners as "Players with extra privileges", not different privileges entirely.
Creating separate models with separate login and registration forms, which seems like a disaster waiting to happen. One small mixup between a Players table and the Owners table, especially with the primary keys, and that will be a world of trouble where people could end up logging in to the wrong accounts.
Creating a polymorphic or has_one relation toward an Account model, which so far, seems like the best way to probably go about it. If I created a polymorphic Account model, I can store different types of Players/Owners, but how could I compare login credentials against all types?
I had been trying to find something on this matter regarding how to map this out and was surprised to not find an information on how to do this without using Devise. If anyone has any good links they can point me to that also address this matter (without Devise), please leave them in your answer! Thanks.
I'd suggest one User class with a type attribute that determines whether the user is a Player or an Owner (single table inheritance). This way you keep the registration logic in one place but can customize the forms depending on the user's class.
There must be alternatives to cancancan that help with what you want to do, or you can implement helpers yourself:
def can_access_control_panel?
current_user.is_a?(Owner)
end
You have to have a way to separate one user from another. One way is to add an attribute to the User table so you can call current_user.role and it will return "owner" or return "player".
I have used Pundit gem in the past. It lets you define which controller actions the current user is allowed to access. So as you create resources for your application, you can add a policy that specifies who is allowed to that given resource. This is the repo to the application.
This answer might help you.
I am working on an app right now where I have Individuals, Athletes and Coaches. A coach has many athletes and they create athletes as well. Whereas individuals can just come to the site and use a different set of tools. So for functionality and logic reasons I prefer to keep the individual model separate from the athlete model.
When users come to the site I want them to login but it would be confusing to have 3 logins (coach, individual and athlete). Users coming to the site will get confused whether or not they are an individual or an athlete. I was thinking of putting a login link which would have an ajax menu with all three choices, which will look nicer but I still have the multiple login issue.
Does anyone have an idea on how I can make ideally 1 login form for individuals and athletes. I am using authlogic for authentication. I am not looking for code, I can go in and mess around, just wondering if there is a trick to this (making it easier for the user).
Thanks!
You might want to look at the devise gem (http://github.com/plataformatec/devise), this supports using multiple models for authentication.
Why not have the Individual, Athlete and Coach models be subclasses of your User model.
Then you can put all the authentication guff into User and it's available to all three - all through the same login form.
You want to assign Roles to Users. You don't need separate subclasses for each user type, model it so a user has_many :roles.
Have a look at this blog post for a detailed explanation - roles can be very simple if this is all you need.