I'm writing a trading system and I have 3 models/roles: Buyers, Sellers and Administrators. I have generated the devise views for each of the models but I would like to use the same sign in, forgotten password pages etc. for them, rather than maintaining 3 sets of views, is there a way of doing this?
The buyer and seller have similar fields (forename, surname, email address, telephone etc.), is it possible to use STI with devise and is it fairly straightforward? At the moment I have 3 separate models with no inheritance.
You can simply have a single User model with a :role attribute and also implement a simple ACL via CanCan or decl_auth (gems). This way they will all sign in etc. via the same session. Devise and CanCan is quite a popular approach and well documented online and in their respective Github wiki's.
For administrators, you can modify your validations to skip on the extra attributes and leave them as blank in the DB.
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.
I am designing an app where the user signs up using the devise gem (email + password).
Then, i have a form to capture other personal information and since i am creating something like a social dating app i need to match users using this data.
My question is based on a design concern because I created a Model with devise and then I am using a different database to hold the data coming from the form after sign up.
Do you suggest having a mutual column between Model from Devise and the new Database, maybe Id or email since they are both unique
OR
Ask for this information in the sign up for by overwrite devise using a custom controller?
What is considered best practise? Keep in mind that I have two types of users, it is not males/females, it is something else, therefore Maybe two databases are helpful having another one from devise so in total 3.
I think the best way to go would be to keep the Devise model for the users and then create another model (for example "Profile"), where you can store all the more "personal" data for each user.
Then you can either ask for the user to fill that data through a new form, or you can create nested fields in the sign up form where the user can fill some information right away.
Consider an application, which needs to have two different types of user:
User as in standard client
Organization as an entity offering some services through the application
Requirements:
different standard controllers (sessions, registrations etc)
access to different parts of the application of course
This seems like a walk in the park by simply creating two separate models with devise, but I really wouldn't like to duplicate so much functionality for authentication.
I went with a polymorphic association, where Organization and User are different models, both with a 1-1 relation with Entity representing authentication. Entity only has devise attributes (like password etc), while others have type-specific ones. Unfortunately this solution comes with a lot of drawbacks, like having to define custom helpers, warden strategies and devise failure apps.
I'm wondering, is there a concise solution for this type of issue?
Ideally, something like having two devise models delegating everything regarding authentication to a separate entity.
Building a small reservation site. There are users (who login and work with the site) and there are guests who are being assigned to rooms. users can be (are?) guests but not all guests are also users.
My initial inclination was to set up a belongs_to / has_one relationship between user & guest but maybe STI would work here? Being as users & guests have first_name, last_name, email etc. does it make sense to set up the model such that, say, user and guest both inherit from person?
I will roll my own simplistic authentication so the only additional fields user is likely to have are password_digest, roles_mask and a icon_color.
Any suggestions? I only ask because things can get tricky around authentication, authorization & whatnot.
Appreciate any ideas/tips!
The simplest approach here would be to, as suggested, stick to STI. You can, for example, setup a single devise User model as well as apply ACL with CanCan and define roles for your users.
CanCan's ability spec will determine which resources are accessible and what are not. The advantage here is that users can be guests, and depending on how you setup your ACL, guests can be prevented from having admin like access.
However, Jesse's suggestion of going two separate Devise models is also a good idea as this ensures their sessions are separate. This is more straightforward to implement as you can then setup a User-specific ACL and Guest-specific ACL accordingly.
https://github.com/ryanb/cancan
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.