Wednesday, July 10, 2013

Re: [Rails] Re: Devise routes



On Tuesday, July 9, 2013 4:18:23 PM UTC-4, Colin Law wrote:
On 9 July 2013 06:42, mack gille <li...@ruby-forum.com> wrote:
> yes mike,but when we need to authenticate the devise models,how to write
> the scope for two devises in routes.
> means if user and admin are two devise models,

I believe that it is generally best not to have separate models.  Just
have users, with admin users as a type of user.  This can be handled
by a simple boolean in the users table, using before_filter to allow
access to appropriate actions based on the user types.  Alternatively
have a look at the cancan gem to provide different roles for different
user types.  Your life will be much simpler with a single users table.

Colin

This topic seems exist in multiple threads so I'm going to respond to it hear and hope the readers from the other threads see it.

I agree with Colin, I believe the easiest and best way to do this is to use one user table (model).  For an admin user, the use of a simple boolean makes it very easy to implement before_actions (or before_fillters) to authorize.

However, if you, for whatever reason, need separate models, devise does support them.  routes are automatically generated for each model.  For example, if you generate a user model and an admin model, you will have a new_user_session_path and a new_admin_session_path generated by devise for login.  If you want one login page for all users, it's possible, but becomes complicated and I would refer you back to the original suggestion, use one model.  One of the complications, among others, with this approach is that if a user switches and now becomes an admin, you need to move the person from one table to another.  

There is another option.  Again, I much prefer to keep things simple, but it's an option.  If you have multiple types of users, such as employees and customers, that require a significant number of unique attributes for each type, you can use one user table, and create a separate customer model (for example) from a table that inherits from the user table using single table inheritance.  I have used single table inheritance, but not in this context so I can't say I have much experience with this option.  With STI, it's still one table so, in theory, you would be able to route all users to one login, but I'd have to test it.

If your needs for different user types revolve mostly around different authorizations, I, again, would agree with Colin's suggestion to use CanCan, or develop a table-based authorization separate from authentication.

 

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/29869fdd-a4a9-4776-a64c-db5d97d68bb3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate