I have been looking at the LoginGenerator gem. Looks great and can be easily modified. However in my app I have two places where people can login, one is for in my case "employees" the other is for "users". They are seperate tables in my database and have many different fields. I have an admin area located at ./sysadmin/ where only "employees" can login, they will have roles of things like "engineer", "admin", "development" etc which alters what they can do. The other area is for "users" these users also have roles (like client_admin) different to the "employees" roles. Logging in here is only for our clients. So on the surface it seems like I need to have the functionality of the logingenerator as two seperate instances running from two tables inside the same app. Can''t work out the best way to do it. Have you done anything similar? (I had thought about using STI, but have decided against that for a number of reasons). -- Posted via http://www.ruby-forum.com/.
I''m wrestling with the exact same issues today. My first thought is to define two before filters. One would be :user_login_required and the other would be :employee_login_required. Then I just duplicate the login_required method in the login_system.rb and adjust models accordingly. Perhaps someone has a better idea? -Derrick Spell On Feb 20, 2006, at 3:09 PM, James Whittaker wrote:> I have been looking at the LoginGenerator gem. Looks great and can be > easily modified. However in my app I have two places where people can > login, one is for in my case "employees" the other is for "users". > They > are seperate tables in my database and have many different fields. > > I have an admin area located at ./sysadmin/ where only "employees" can > login, they will have roles of things like "engineer", "admin", > "development" etc which alters what they can do. > > The other area is for "users" these users also have roles (like > client_admin) different to the "employees" roles. Logging in here is > only for our clients. > > So on the surface it seems like I need to have the functionality of > the > logingenerator as two seperate instances running from two tables > inside > the same app. > > Can''t work out the best way to do it. Have you done anything similar? > > (I had thought about using STI, but have decided against that for a > number of reasons). > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Derrick Spell wrote:> I''m wrestling with the exact same issues today. My first thought is > to define two before filters. One would be :user_login_required and > the other would be :employee_login_required. Then I just duplicate > the login_required method in the login_system.rb and adjust models > accordingly. > > Perhaps someone has a better idea? > > -Derrick SpellYes I see what you mean, that could be a way. So that would mean duplicating the "user" model as well. I suppose you could create a base model and the inherit it changing the required references to "user" to the other model. I''m all new to this so other suggestion are very welcome in the mean time lets experiment! -- Posted via http://www.ruby-forum.com/.
James Whittaker wrote:> Derrick Spell wrote: >> I''m wrestling with the exact same issues today. My first thought is >> to define two before filters. One would be :user_login_required and >> the other would be :employee_login_required. Then I just duplicate >> the login_required method in the login_system.rb and adjust models >> accordingly. >> >> Perhaps someone has a better idea? >> >> -Derrick Spell > > > Yes I see what you mean, that could be a way. So that would mean > duplicating the "user" model as well. I suppose you could create a base > model and the inherit it changing the required references to "user" to > the other model. > > I''m all new to this so other suggestion are very welcome in the mean > time lets experiment!No i''m being stupid I cannot inherit the model as they are very different and thats back to the SingleTableInheritance that I don''y want to use. -- Posted via http://www.ruby-forum.com/.
On 2/20/06, James Whittaker <jmwhittaker@gmail.com> wrote:> I have been looking at the LoginGenerator gem. Looks great and can be > easily modified. However in my app I have two places where people can > login, one is for in my case "employees" the other is for "users". They > are seperate tables in my database and have many different fields. > > I have an admin area located at ./sysadmin/ where only "employees" can > login, they will have roles of things like "engineer", "admin", > "development" etc which alters what they can do. > > The other area is for "users" these users also have roles (like > client_admin) different to the "employees" roles. Logging in here is > only for our clients. >You may want to look at the user engine (or user generator if there is one). http://www.rails-engines.org/user_engine I''m still a newbie, but as I understand it the login engine and/or generator allows people to login. To get different roles for different people you can add the user engine to your setup. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
On Feb 20, 2006, at 12:09 PM, James Whittaker wrote:> I have been looking at the LoginGenerator gem. Looks great and can be > easily modified. However in my app I have two places where people can > login, one is for in my case "employees" the other is for "users". > They > are seperate tables in my database and have many different fields. > > I have an admin area located at ./sysadmin/ where only "employees" can > login, they will have roles of things like "engineer", "admin", > "development" etc which alters what they can do. > > The other area is for "users" these users also have roles (like > client_admin) different to the "employees" roles. Logging in here is > only for our clients. > > So on the surface it seems like I need to have the functionality of > the > logingenerator as two seperate instances running from two tables > inside > the same app. > > Can''t work out the best way to do it. Have you done anything similar? > > (I had thought about using STI, but have decided against that for a > number of reasons). > > -- >James- You might want to take a look at my new plugin acl_system. Its an add on for the different login generaotrs that adds permissions and roles to the whole deal. Its an acl/role type system that can sit on top of the acts_as_authenticated login system or any login system that implements a few requirements. First lets see the candy ;-). This is what my post controller looks like in my sample app to demonstrate this plugin: class PostController < ApplicationController before_filter :login_required, :except => [:list, :index] access_control(:new => ''(admin | user | moderator) & !blacklist'', :create => ''admin & !blacklist'', :edit => ''(admin | moderator) & !blacklist'', :update => ''(admin | moderator) & !blacklist'', :delete => ''admin & (!moderator | !blacklist)'' ) There is also a helper method that can be used in the view or controller. In the view its handy for conditional menus or stuff like that. <% if permit?("(admin | moderator) & !blacklist", current_user) %> <%= link_to "Admin & Moderator only link", :action =>''foo'' %> <% end %> Here is the link: http://brainspl.at/articles/2006/02/20/new-plugin-acl_system I reccomend that you use the acts_as_authenticated plugin instead of the login generator, its similar but much better. Cheers- -Ezra Zygmuntowicz WebMaster Yakima Herald-Republic Newspaper ezra@yakima-herald.com 509-577-7732 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060220/d247b90f/attachment.html
Ezra, Many thanks again. I had looked at the engines bt decided against using them as it still does not address the issue I have which is I don''t just have one "users" table & model to set permissions/logins against, I also have another model & table with "employees" that needs seperate permissions, logins. I have decided, probably wrongly, to duplicate the login_required method in login_system so that I have "employee_login_required" and "user_login_required". This means that I now have duplicate information in my models that is against DRY principles. -- Posted via http://www.ruby-forum.com/.