hi...
i am using two devises in rails 4 application,i need the routes for
those devises.
rails 4 is new feature for routes
--
Posted via http://www.ruby-forum.com/.
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/ba836a4fbd2f9b18a805072f86267dd0%40ruby-forum.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Monday, July 8, 2013 4:05:36 AM UTC-4, Ruby-Forum.com User wrote:> > hi... > i am using two devises in rails 4 application,i need the routes for > those devises. > rails 4 is new feature for routes > > -- > Posted via http://www.ruby-forum.com/. >I''m having trouble understanding the question. Devise automatically generates its own routes. Type "rake routes" on the command line (without the quotes) to see them. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b205a565-75ae-402c-b907-c643178b9718%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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,if i enter user sign then it will go to user dashboard,if i enter admin sign then it will go to admin dashboard,if there is not sign in then common dashboard body message is please sign in to access.i need routes for the two devises authentication,if if no devise authentication then route to common dashboard. thank you. -- Posted via http://www.ruby-forum.com/. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b953a1630bbc775bf38bf1f2c853a8c1%40ruby-forum.com. For more options, visit https://groups.google.com/groups/opt_out.
On 9 July 2013 06:42, mack gille <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAL%3D0gLsVXgRVuPUT1qzd-HuH0o5xOQ8QcGzzorStMGyKCTwwXQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
On Tuesday, July 9, 2013 4:18:23 PM UTC-4, Colin Law wrote:> > On 9 July 2013 06:42, mack gille <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org <javascript:>> > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org 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.