I have been working on an app but ran into many problems when i was applying authentication and authorization. I want to have the following users with the given abilities. Admin: full control on the entire system, but apart from login , email and password it does not require any more attributes company owner: should be able to created the number of companies the admin approves, and have full control over all of its companies, i would like to send an invitation to this user type user: should have different roles and has couple more fields than the company owner. The super user roles can only have full control over its own company. user cant create companies and should belong to a company and cant create companies. owners or super users should be able to create them via a crud client: if approved by the admin a company is clients are allowed to log in to the system, they only have read access to their personal data and an internal email system. Have lots of fields, ca be affiliated to a company but the admin has access to all clients in the system. company owners only have access to their companies clients , and the users only to the clients that are affiliated to their company. the problem comes now, I have 4 models at the moment, i would like authentication an authorization systems to be common to all of them. I have 4 abilities with cancan, and 4 resources with devise, but keeping up with everything was very redundant, i have 4 login page 4 path to signout, etc. If i unify all users in a single model an manage everything with fields in the DB im a little confuse on how to handle the company users relation since companies belong to owners in the current design but a company has many users and clients. I have been thinking of a has many through association with resources called ownership, employ and affiliation and use boolean fields or a user type field to differentiate each type of user. I would need a lot of conditional validations of course. would STI be helpful or would it require 4 of everything anyway? i want to have one login page and one ability class. Anyone has a better solution? i would appreciate some comments on this. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
please help!! T_T -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
bump anyone? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 October 2010 01:33, radhames brito <rbritom-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I have been working on an app but ran into many problems when i was > applying authentication and authorization. > > I want to have the following users with the given abilities.Note your wording here, you want the following _users_. That is the clue to what follows.> > Admin: full control on the entire system, but apart from login , email > and password it does not require any more attributes > > company owner: should be able to created the number of companies the > admin approves, and have full control over all of its companies, i > would like to send an invitation to this user type > > user: should have different roles and has couple more fields than the > company owner. The super user roles can only have full control over > its own company. user cant create companies and should belong to a > company and cant create companies. owners or super users should be > able to create them via a crud > > client: if approved by the admin a company is clients are allowed to > log in to the system, they only have read access to their personal > data and an internal email system. Have lots of fields, ca be > affiliated to a company but the admin has access to all clients in the > system. company owners only have access to their companies clients , > and the users only to the clients that are affiliated to their > company. > > the problem comes now, I have 4 models at the moment, i would like > authentication an authorization systems to be common to all of them. I > have 4 abilities with cancan, and 4 resources with devise, but keeping > up with everything was very redundant, i have 4 login page 4 path to > signout, etc. If i unify all users in a single model an manage > everything with fields in the DB im a little confuse on how to handle > the company users relation since companies belong to owners in the > current design but a company has many users and clients.I presume that your models are Admin, Owner, User and Client (or similar names). The fact that you worded your initial requirement as I have pointed out above suggests that these are all Users with different roles. This rationalisation will mean they can all log on via the same page. Once logged in you can control the features available using the roles that a particular user has. There will likely be a roles table. User belongs_to role, Role has_many users and so on. The settings in the role will indicate what a user can do. Colin> > I have been thinking of a has many through association with resources > called ownership, employ and affiliation > and use boolean fields or a user type field to differentiate each type > of user. I would need a lot of conditional validations of course. > would STI be helpful or would it require 4 of everything anyway? i > want to have one login page and one ability class. > > Anyone has a better solution? i would appreciate some comments on > this. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
@colin Thanks, someone finally cared. I presume that your models are Admin, Owner, User and Client (or> similar names). >yes exactly, but i created separated models because there would be a lot of conditional validations if i didnt, for example owners can manage a companies but a user should belong to a company. The fact that you worded your initial requirement as> I have pointed out above suggests that these are all Users with > different roles. >yes but i would require different controllers and views for each roles/type of user, and what i call user, which is the company employee in this case, has many roles. User belongs_to role, Role has_many users> and so on. >im already think of making this a HBTM association, since , but only for the "user" role/type since is the one with many roles. I though about all this before, but the reason i have hesitated to do it this way is because of the validations, excess in attributes for the roles/types that dont require them and possible security issues. I see not way of avoiding the creation of a very fat user model, with lots of accesible attributes dynamically changing and lots of scopes. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 October 2010 17:24, radhames brito <rbritom-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > @colin > > Thanks, someone finally cared. > >> I presume that your models are Admin, Owner, User and Client (or >> similar names). > > yes exactly, but i created separated models because there would be a lot of > conditional validations if i didnt, > for example owners can manage a companies but a user should belong to a > company.I don''t see that as a problem.> >> The fact that you worded your initial requirement as >> I have pointed out above suggests that these are all Users with >> different roles. > > yes but i would require different controllers and views for each roles/type > of user, and what i call user, which is the > company employee in this case, has many roles.You have that already with the different models. You can either continue with separate controllers/views or merge them as seems most appropriate. Remember a controller does not need to map to a model.> >> User belongs_to role, Role has_many users >> and so on. > > im already think of making this a HBTM association, since , but only for the > "user" role/type since is the one with many roles. > > > I though about all this before, but the reason i have hesitated to do it > this way is because of the validations, excess in attributes > for the roles/types that dont require them and possible security issues. > > I see not way of avoiding the creation of a very fat user model, with lots > of accesible attributes dynamically changing and lots of scopes.Again that is not necessarily a problem, though it is all a matter of degree of course. If you really think that here you have different types of users rather than users with different roles you could look at STI as an alternative. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > Remember a controller does not need to map to a model. >Yes i know, thanks.> Again that is not necessarily a problem, though it is all a matter of > degree of course. > If you really think that here you have different types of users rather > than users with different roles you could look at STI as an > alternative. > >Well i know is not a problem, but i wanted to know if there is a better way to do all this. STI creates a problem when authenticating user and creating permissions, i would need an ability and a login per user type. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi, Your task is cannot be that complicated, but for first reading it seemed, and a bit long. Try to draw it first! First you have to find out: the user experience! It will make clear what datas you need, so what models, which kind of controllers you have to write with different actions. And from this writing a before filter will be easier. You haven''t wrote how you solved the user authentication - from scratch? In FireFox there is an excellent Add-on, called Pencil, with this you can make a sketch easily! Now I cannot spend more time with this, but write me in private more detailed, if you would like to, and in these days I will try to help. good luck gezope On okt. 7, 03:53, radhames brito <rbri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> please help!! T_TOn okt. 7, 18:01, radhames brito <rbri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Remember a controller does not need to map to a model. > > Yes i know, thanks. > > > Again that is not necessarily a problem, though it is all a matter of > > degree of course. > > If you really think that here you have different types of users rather > > than users with different roles you could look at STI as an > > alternative. > > Well i know is not a problem, but i wanted to know if there is a better way > to do all this. > STI creates a problem when authenticating user and creating permissions, i > would need an ability and a login per user type.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Just to make things a bit more clear, my app will be very similar to shopify. Im worrying about this first and later i will worry about the CMS part. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > Now I cannot spend more time with this, but write me in private more > detailed, if you would like to, and in these days I will try to help. > good luck > gezope >Thanks a lot. How can i get in contact with you? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 October 2010 18:40, gezope <gezope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > Your task is cannot be that complicated, but for first reading it > seemed, and a bit long. > > Try to draw it first! > First you have to find out: the user experience! It will make clear > what datas you need, so what models,I disagree here, the models required should not be based upon the user experience required but on the underlying objects in the real world - users, companies and so on in this particular case. Unless I misunderstand what is meant by ''user experience''. Colin> which kind of controllers you > have to write with different actions. And from this writing a before > filter will be easier. > You haven''t wrote how you solved the user authentication - from > scratch? > In FireFox there is an excellent Add-on, called Pencil, with this you > can make a sketch easily! > > Now I cannot spend more time with this, but write me in private more > detailed, if you would like to, and in these days I will try to help. > good luck > gezope > > On okt. 7, 03:53, radhames brito <rbri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> please help!! T_T > > On okt. 7, 18:01, radhames brito <rbri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> > Remember a controller does not need to map to a model. >> >> Yes i know, thanks. >> >> > Again that is not necessarily a problem, though it is all a matter of >> > degree of course. >> > If you really think that here you have different types of users rather >> > than users with different roles you could look at STI as an >> > alternative. >> >> Well i know is not a problem, but i wanted to know if there is a better way >> to do all this. >> STI creates a problem when authenticating user and creating permissions, i >> would need an ability and a login per user type. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote:> On 7 October 2010 18:40, gezope <gezope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> Hi, >> >> Your task is cannot be that complicated, but for first reading it >> seemed, and a bit long. >> >> Try to draw it first! >> First you have to find out: the user experience! It will make clear >> what datas you need, so what models, > > I disagree here, the models required should not be based upon the user > experience required but on the underlying objects in the real world - > users, companies and so on in this particular case. Unless I > misunderstand what is meant by ''user experience''.I agree with Zoltan -- and I suspect you do too -- in this sense: when I put together an application, I usually think first about how I want it to present itself to the user and what the user should be able to accomplish (and write Cucumber scenarios accordingly). Only as a result of making those scenarios reality do I write model classes or anything else. In other words: first define what you want the user to do, and only then figure out the code to make it happen.> > ColinBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 October 2010 21:21, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Colin Law wrote: >> On 7 October 2010 18:40, gezope <gezope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> Hi, >>> >>> Your task is cannot be that complicated, but for first reading it >>> seemed, and a bit long. >>> >>> Try to draw it first! >>> First you have to find out: the user experience! It will make clear >>> what datas you need, so what models, >> >> I disagree here, the models required should not be based upon the user >> experience required but on the underlying objects in the real world - >> users, companies and so on in this particular case. Unless I >> misunderstand what is meant by ''user experience''. > > I agree with Zoltan -- and I suspect you do too -- in this sense: when I > put together an application, I usually think first about how I want it > to present itself to the user and what the user should be able to > accomplish (and write Cucumber scenarios accordingly). Only as a result > of making those scenarios reality do I write model classes or anything > else. > > In other words: first define what you want the user to do, and only then > figure out the code to make it happen.I think my point is that the identification of models that are required should not be based on what is required in views or what the user experience is as he moves around the site. It is based on considering the underlying objects in the system. So in the OP''s case, whether he should have different models for user, owner and so on or have one model, user, with different roles is not principally to do with how the app should appear or behave, except in the very broadest sense that there is a requirement for such objects. The whole design process is iterative of course, but I think I would rephrase your suggestion as follows: First think (and preferably talk) about the underlying objects in the system so as to get a first stab at the models required (not the code, just what the models are likely to be), then define what you want the user to do, and then figure out the code to make it happen. Round and round ad nauseum. That is not to say that I think this is the one and only ''right'' way to do it. Different people''s minds work in different ways and others may find an alternative design process suits them better. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Radhames Brito wrote:> I have been working on an app but ran into many problems when i was > applying authentication and authorization. > > I want to have the following users with the given abilities. >Is there any reason that you cannot usefully employ existing authentication mechanisms like Auth_Logic or Devise? And what about Declarative_Authorization? Is there any reason why this does not suit your authorization needs? It seems to me to be a mis-application of effort to write from the ground up that which is already freely available and maintained for 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > I agree with Zoltan -- and I suspect you do too -- in this sense: when I > put together an application, I usually think first about how I want it > to present itself to the user and what the user should be able to > accomplish (and write Cucumber scenarios accordingly). Only as a result > of making those scenarios reality do I write model classes or anything > else. > > In other words: first define what you want the user to do, and only then > figure out the code to make it happen. > >This approach should be very beneficial, i always begin by thinking of entities and their relations, and only when i get to the presentation layer i start thinking about the user experience. I will definitively try going this way to see if everything come out faster. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> Is there any reason that you cannot usefully employ existing > authentication mechanisms like Auth_Logic or Devise? And what about > Declarative_Authorization? Is there any reason why this does not suit > your authorization needs? > > It seems to me to be a mis-application of effort to write from the > ground up that which is already freely available and maintained for you. > -- >creating a model for each user was the easiest way at first, but in that case i need a different login page for each and that detriments the user experience. Devise is awesome, but i have found it inflexible. I wanted to make an ajax login and it was harder than necessary. I tried to make all users login with one login page and i had to first learn how to use warden and hack devise quite a bit, in fact i did all that, but every change was like going against the concept devise was build for (easy of use , etc). Authlogic is more flexible but it wont allow one page login for all users easily. Cancan requires a different ability per model so there is a lot of redundancy when i need to define permissions for one type of user and almost the same for another type of user. Thats why i have been thinking of joining everything in one model, but first i wanted to ask to see if that was the best/only way to overcome all those obstacles. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote: [...]> The whole design process is iterative of course, but I think I would > rephrase your suggestion as follows: > First think (and preferably talk) about the underlying objects in the > system so as to get a first stab at the models required (not the code, > just what the models are likely to be), then define what you want the > user to do, and then figure out the code to make it happen.No, absolutely not. There is no point in thinking about the models involved before thinking about the desired functionality.> Round and > round ad nauseum. That is not to say that I think this is the one and > only ''right'' way to do it.No, of course there''s more than one right way. But I think yours is one of the many wrong ways: it is inappropriate to start considering implementation details before you know what the implementation should do for the end user. I''ll turn the question around: why would you want to consider implementation before functionality? What possible benefits could it produce? Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 October 2010 03:34, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Colin Law wrote: > [...] >> The whole design process is iterative of course, but I think I would >> rephrase your suggestion as follows: >> First think (and preferably talk) about the underlying objects in the >> system so as to get a first stab at the models required (not the code, >> just what the models are likely to be), then define what you want the >> user to do, and then figure out the code to make it happen. > > No, absolutely not. There is no point in thinking about the models > involved before thinking about the desired functionality. > >> Round and >> round ad nauseum. That is not to say that I think this is the one and >> only ''right'' way to do it. > > No, of course there''s more than one right way. But I think yours is one > of the many wrong ways: it is inappropriate to start considering > implementation details before you know what the implementation should do > for the end user. > > I''ll turn the question around: why would you want to consider > implementation before functionality? What possible benefits could it > produce?Well of course you need some idea of functionality before anything can be designed. If I can bring back a quote from your earlier post:> ... when I > put together an application, I usually think first about how I want it > to present itself to the user and what the user should be able to > accomplish (and write Cucumber scenarios accordingly). Only as a result > of making those scenarios reality do I write model classes or anything > else.I am suggesting that there is a phase before considering in detail how the application should present itself to the user. For example to take the ubiquitous shopping app, before considering how the logon page should operate there is the decision that there will be users and that there should be a page where the user can logon. Similarly before considering how precisely the user adds a product to his shopping cart there is the decision that there will be products and shopping carts. It is at this stage that initial stabs at what the models will be can be made (note that I am not suggesting writing any code here, merely thinking about what the models will be). It does not seem feasible that one can write a Cucumber scenario for user logon and then go from that to the idea that maybe one needs a user model. Is it not true that the concept of a User must exist before one can write the scenario? Note again that I am not suggesting writing any code at this time, just thinking about what the models should be. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote:> On 8 October 2010 03:34, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: >> involved before thinking about the desired functionality. >> I''ll turn the question around: why would you want to consider >> implementation before functionality? �What possible benefits could it >> produce? > > Well of course you need some idea of functionality before anything can > be designed. If I can bring back a quote from your earlier post: > >> ... when I >> put together an application, I usually think first about how I want it >> to present itself to the user and what the user should be able to >> accomplish (and write Cucumber scenarios accordingly). Only as a result >> of making those scenarios reality do I write model classes or anything >> else. > > I am suggesting that there is a phase before considering in detail how > the application should present itself to the user.There is the phase of deciding in very general terms what the broad goal of the application is -- in your case, something like "people should be able to order products from us".> For example to > take the ubiquitous shopping app, before considering how the logon > page should operate there is the decision that there will be users and > that there should be a page where the user can logon.Sort of. Out of the idea that users can order products comes the idea that we need a way to tell the system who''s ordering. From that idea may come the fact that we want user accounts and a login interface. That''s probably as far as I''d go down that particular path in initial requirements gathering with my client.> Similarly > before considering how precisely the user adds a product to his > shopping cart there is the decision that there will be products and > shopping carts.First step: Users should be able to order products. Second step: We want to present them a shopping cart interface to do so. Third step: Users should be able to do the following things from that interface. The domain concepts emerge from requirements gathering. They are not considered before it so much as simultaneously with it in my experience.> It is at this stage that initial stabs at what the > models will be can be made (note that I am not suggesting writing any > code here, merely thinking about what the models will be).No! It''s premature. The business domain objects are a good start for guessing what model classes you''ll need, but it''s absolutely wrong to be thinking like a programmer when you''re doing business analysis.> It does > not seem feasible that one can write a Cucumber scenario for user > logon and then go from that to the idea that maybe one needs a user > model.I assure you, it is entirely feasible. I do it all the time: write a Cucumber scenario with perhaps only the vaguest idea of what models I need, then start experimenting with the best way to make it pass. Remember, Cucumber scenarios are written in English for a reason: they''re meant to test user-facing behavior, not code. You could completely rearchitect a system and still have the Cucumber scenarios pass.> Is it not true that the concept of a User must exist before > one can write the scenario?The business concept, sure. But it''s premature to translate that into a concept of a User class in the requirements gathering stage. (To be fair, user management is simple in most cases and requires a User class. But I''ve been doing stuff with my medical records application where I may have a bunch of features gleaned from the client and translated to Cucumber stories -- and still have no idea what the underlying models should look like.)> Note again that I am not suggesting > writing any code at this time, just thinking about what the models > should be.And I''m telling you that that''s a bad idea. Don''t think about models till you actually need to write them.> > ColinBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Radhames Brito wrote:> > Authlogic is more flexible but it wont allow one page login for all > users easily. >I do not understand what you mean by this. I have authlogic in production where there is but one authentication view used by every user. Each session created thereby has its own credentials and the user instance thereafter obtains its permissions from the declarative_authorization roles and rights configuration file. I will not pretend that dealing with these two formidable packages was without its difficulties, particularly in the the beginning when my ignorance of them was complete. However, once one grasps the concepts upon which each is based then elaboration of the resulting security system is far easier than I ever thought possible.> Cancan requires a different ability per model so there is a lot of > redundancy when i need to define permissions for one type > of user and almost the same for another type of user. Thats why i have > been thinking of joining everything in one model, but first i wanted > ask to see if that was the best/only way to overcome all those obstacles.I have not used CanCan (Ryan Biggs wrote that for one of his Railscasts episodes did he not?) but from what I can gather from your other messages it seems that you conflate authentication with authorization at several points. Authlogic, Devise and similar packages simply identify a particular set of credentials as having a unique accessor instance in the system. Declarative_Authorization and CanCan type packages tie access to specific bits of the application to specific accessor identities. Both need some form of implementation of the idea of a session to be of much use. My own experience with RBAC is that it proves best to stay away from things that you do not fully understand until you need to address them directly and can afford the time to master the intricacies involved. Imagining what you will need in the absence of concrete requirements is a great time waster. For an initial implementation of authentication and authorization I would create some minimal methods in the application controller to handle hard coded identities, rights and roles and then go ahead build the application. At some point the need for users will present itself and then you can implement your user models/classes modifying the stub methods to handle authorization alone. When authorization becomes the natural focus of development then it is time to look at things like Authlogic and CanCan. I think that you will find the this approach permits you to remain focused on the value-added part of your project and leaves the administrative pieces on the periphery until their requirements are largely defined by the rest of your application. -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 October 2010 13:47, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Colin Law wrote: >> On 8 October 2010 03:34, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> >> wrote: >>> involved before thinking about the desired functionality. >>> I''ll turn the question around: why would you want to consider >>> implementation before functionality? �What possible benefits could it >>> produce? >> >> Well of course you need some idea of functionality before anything can >> be designed. If I can bring back a quote from your earlier post: >> >>> ... when I >>> put together an application, I usually think first about how I want it >>> to present itself to the user and what the user should be able to >>> accomplish (and write Cucumber scenarios accordingly). Only as a result >>> of making those scenarios reality do I write model classes or anything >>> else. >> >> I am suggesting that there is a phase before considering in detail how >> the application should present itself to the user. > > There is the phase of deciding in very general terms what the broad goal > of the application is -- in your case, something like "people should be > able to order products from us". > >> For example to >> take the ubiquitous shopping app, before considering how the logon >> page should operate there is the decision that there will be users and >> that there should be a page where the user can logon. > > Sort of. Out of the idea that users can order products comes the idea > that we need a way to tell the system who''s ordering. From that idea > may come the fact that we want user accounts and a login interface. > That''s probably as far as I''d go down that particular path in initial > requirements gathering with my client. > >> Similarly >> before considering how precisely the user adds a product to his >> shopping cart there is the decision that there will be products and >> shopping carts. > > First step: Users should be able to order products. > Second step: We want to present them a shopping cart interface to do so. > Third step: Users should be able to do the following things from that > interface. > > The domain concepts emerge from requirements gathering. They are not > considered before it so much as simultaneously with it in my experience. > >> It is at this stage that initial stabs at what the >> models will be can be made (note that I am not suggesting writing any >> code here, merely thinking about what the models will be). > > No! It''s premature. The business domain objects are a good start for > guessing what model classes you''ll need, but it''s absolutely wrong to be > thinking like a programmer when you''re doing business analysis. > >> It does >> not seem feasible that one can write a Cucumber scenario for user >> logon and then go from that to the idea that maybe one needs a user >> model. > > I assure you, it is entirely feasible. I do it all the time: write a > Cucumber scenario with perhaps only the vaguest idea of what models I > need, then start experimenting with the best way to make it pass. > Remember, Cucumber scenarios are written in English for a reason: > they''re meant to test user-facing behavior, not code. You could > completely rearchitect a system and still have the Cucumber scenarios > pass. > >> Is it not true that the concept of a User must exist before >> one can write the scenario? > > The business concept, sure. But it''s premature to translate that into a > concept of a User class in the requirements gathering stage. > > (To be fair, user management is simple in most cases and requires a User > class. But I''ve been doing stuff with my medical records application > where I may have a bunch of features gleaned from the client and > translated to Cucumber stories -- and still have no idea what the > underlying models should look like.) > >> Note again that I am not suggesting >> writing any code at this time, just thinking about what the models >> should be. > > And I''m telling you that that''s a bad idea. Don''t think about models > till you actually need to write them.I think we are just going to have to agree to differ on this one, though in fact I do not think our viewpoints are as far apart as it might appear from this discussion. I also think that you have to allow a bit of flexibility in approach for the different ways that different peoples brains work when analysing a system requirement. Looking back over my career I cannot remember any instances where I got in a mess or wasted significant time by thinking about the underlying objects too early in the analysis, but I can remember instances of problems when I left this phase too late. Of course the length of my career may have a bearing on what I can and cannot remember :) The one thing that I am sure we can agree on is the importance of making sure that what is provided is what the user wants, not what you think he aught to want or what his managers thinks he wants. Provided we achieve that then slight variations in the route to get there are not so important. Failing to understand the user requirements is the principle cause of IT system failures I think. Regards Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote:> On 8 October 2010 13:47, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: >>> >> There is the phase of deciding in very general terms what the broad goal >> may come the fact that we want user accounts and a login interface. >> Third step: Users should be able to do the following things from that >> guessing what model classes you''ll need, but it''s absolutely wrong to be >> Remember, Cucumber scenarios are written in English for a reason: >> (To be fair, user management is simple in most cases and requires a User >> till you actually need to write them. > I think we are just going to have to agree to differ on this one,I would rather not do that. In general, that''s a sign that more discussion is needed, as one or both of us is probably missing something. Certainly I''m learning a lot from this discussion. However, I''m perfectly willing to start a new thread for this.> though in fact I do not think our viewpoints are as far > apart as it might appear from this discussion.Quite probably not. As I think about it more, I do realize that I have a *slight* idea about my model class structure at the time I write my Cucumber stories. But then again, the steps that usually change the most are the explicitly model-related ones (Given a user exists with name: "Fred"...)> I also think that you > have to allow a bit of flexibility in approach for the different ways > that different peoples brains work when analysing a system > requirement.Maybe. I am not at all sure that this is a matter of cognitive style.> Looking back over my career I cannot remember any > instances where I got in a mess or wasted significant time by thinking > about the underlying objects too early in the analysis,Not to be snarky, but would you really know? It''s easy to do a premature analysis, get it wrong, and stick with it long after it should have been discarded. I''ve probably been guilty of this on occasion myself.> but I can > remember instances of problems when I left this phase too late.What sort of problems? In general, leaving it as late as possible seems like the right thing to do.> Of > course the length of my career may have a bearing on what I can and > cannot remember :):)> > The one thing that I am sure we can agree on is the importance of > making sure that what is provided is what the user wants, not what you > think he aught to want or what his managers thinks he wants.Right.> Provided > we achieve that then slight variations in the route to get there are > not so important. Failing to understand the user requirements is the > principle cause of IT system failures I think.Yes, I would think so, with hacking a close second.> > Regards > > ColinBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > Authlogic is more flexible but it wont allow one page login for all > > users easily. > > > > I do not understand what you mean by this. I have authlogic in > production where there is but one authentication view used by every > user. Each session created thereby has its own credentials and the user > instance thereafter obtains its permissions from the > declarative_authorization roles and rights configuration file. > >Because you have one user model i have 4, so when i authenticate i have to loop all the models to find the credentials beacuse there can be a company_user with name "pedro" and an admin name "pedro" because they are 2 diferent models, there is another problem because those 2 pedros could have the same password, all because i am using different models for each user type.> I will not pretend that dealing with these two formidable packages was > without its difficulties, particularly in the the beginning when my > ignorance of them was complete. However, once one grasps the concepts > upon which each is based then elaboration of the resulting security > system is far easier than I ever thought possible. >Oh have use then successfully before and they are quite easy to use, The problem is i tried out way of using them that is not commun> > > Cancan requires a different ability per model so there is a lot of > > redundancy when i need to define permissions for one type > > of user and almost the same for another type of user. Thats why i have > > been thinking of joining everything in one model, but first i wanted > > ask to see if that was the best/only way to overcome all those obstacles. > > I have not used CanCan (Ryan Biggs wrote that for one of his Railscasts > episodes did he not?) but from what I can gather from your other > messages it seems that you conflate authentication with authorization at > several points. Authlogic, Devise and similar packages simply identify > a particular set of credentials as having a unique accessor instance in > the system. Declarative_Authorization and CanCan type packages tie > access to specific bits of the application to specific accessor > identities. Both need some form of implementation of the idea of a > session to be of much use. >ryan bates did, it only handles authorization, but all through an ability class and to this class you have to pass the user model on initialization, but since i have 4 models i need 4 ability class and switch them during login> > My own experience with RBAC is that it proves best to stay away from > things that you do not fully understand until you need to address them > directly and can afford the time to master the intricacies involved. > Imagining what you will need in the absence of concrete requirements is > a great time waster. > > For an initial implementation of authentication and authorization I > would create some minimal methods in the application controller to > handle hard coded identities, rights and roles and then go ahead build > the application. At some point the need for users will present itself > and then you can implement your user models/classes modifying the stub > methods to handle authorization alone. When authorization becomes the > natural focus of development then it is time to look at things like > Authlogic and CanCan. > > I think that you will find the this approach permits you to remain > focused on the value-added part of your project and leaves the > administrative pieces on the periphery until their requirements are > largely defined by the rest of your application. > > I agree with this to some point, but i hate refactoring , and i like todeal with the untested/new/hard stuff first so that if i dont find a solution with one strategy i can easily rebuild everything from scratch -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Radhames Brito wrote:>> > Because you have one user model i have 4, so when i authenticate i have > to > loop all the models to find the credentials beacuse there can be a > company_user with name "pedro" and an admin name "pedro" because they > are 2 > diferent models, there is another problem because those 2 pedros could > have > the same password, all because i am using different models for each user > type.Why the hell would you do it this way? Just use one user model with a role and have done with it. You''re getting name conflicts and other problems the way you''re doing it...so don''t do it that way! Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
from my fourth comment I presume that your models are Admin, Owner, User and Client (or>> similar names). >> >> yes exactly, but i created separated models because there would be a lot of > conditional validations if i didnt, > for example owners can manage a companies but a user should belong to a > company.> > The fact that you worded your initial requirement as >> I have pointed out above suggests that these are all Users with >> different roles. >> >yes but i would require different controllers and views for each roles/type> of user, and what i call user, which is the > company employee in this case, has many roles. >I though about all this before, but the reason i have hesitated to do it> this way is because of the validations, excess in attributes > for the roles/types that dont require them and possible security issues. > > I see not way of avoiding the creation of a very fat user model, with lots > of accesible attributes dynamically changing and lots of scopes. >in my fourth comment im explained why i was doing it this way. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Radhames Brito wrote:> from my fourth comment > > I presume that your models are Admin, Owner, User and Client (or >>> similar names). >>> >> > >> yes exactly, but i created separated models because there would be a lot of >> conditional validations if i didnt, >> for example owners can manage a companies but a user should belong to a >> company. > > > >> >> The fact that you worded your initial requirement as >>> I have pointed out above suggests that these are all Users with >>> different roles. >>> >> > yes but i would require different controllers and views for each > roles/type >> of user,That doesn''t mean you need different models to go along with them.> and what i call user, which is the >> company employee in this case, has many roles.HABTM roles is perfectly feasible. You might want to use something like rails_authorization or CanCan to make managing privileges easier.>> > > > > I though about all this before, but the reason i have hesitated to do it >> this way is because of the validations, excess in attributes >> for the roles/types that dont require them and possible security issues.Huh? No. A User is a User is a User, if I understand correctly. Stop trying to justify a bad design decision.>> >> I see not way of avoiding the creation of a very fat user model, with lots >> of accesible attributes dynamically changing and lots of scopes.There''s nothing wrong with a fat model if it is the best representation for your data. But I''d be more inclined to use various has_ones for the additional information. I''m doing something like this in a medical records app I''m working on, where clinicians and patients are both Users, but each patient record also has_one Chart to hold medical information that clinicians don''t have stored. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > That doesn''t mean you need different models to go along with them. >I wanted to keep the models thiner , but it does not seem to go well with authorization and authentication.> HABTM roles is perfectly feasible. You might want to use something like > rails_authorization or CanCan to make managing privileges easier. >Surely i will use is HABTM is im more worried on how to handle company owners, since they can exist before their companies do but their employees should only exist after he creates a company, thats why i believe ill need a set of controllers and views for those main roles.> Huh? No. A User is a User is a User, if I understand correctly. Stop > trying to justify a bad design decision. >Im not justifying thats why am here asking you guys because i notice its a bad design and to note make a similar mistake again am asking for advise. There''s nothing wrong with a fat model if it is the best representation>for your data. But I''d be more inclined to use various has_ones for the> additional information. >Yes colin told me that, but since everything before this project has been cleaner and direct i felt like that wasnt the "rails way"> > I''m doing something like this in a medical records app I''m working on, > where clinicians and patients are both Users, but each patient record > also has_one Chart to hold medical information that clinicians don''t > have stored. > > Very interesting approach, can you explain a bit more, how are you handlingthe conditional fields/validations? I said this before but , the app im trying to build will be like http://www.shopify.com/ it should allow various scopes of administration/interaction , that''s why a have an admin,he is in truth the site administrator that controls the complete site , the company owner is the user that creates an account and pays a subscription fee for each company they create, what i call the user is a company employee that works interacting with that company''s clients and the client is the user to whom they give the service. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 October 2010 14:56, radhames brito <rbritom-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> [...] > Because you have one user model i have 4, so when i authenticate i have to > loop all the models to find the credentials beacuse there can be a > company_user with name "pedro" and an admin name "pedro" because they are 2 > diferent models, there is another problem because those 2 pedros could have > the same password, all because i am using different models for each user > type. >I am sorry to have to point out that the route you have gone down here supports Marnen''s contention that model definition should not be started till the operational requirements are known. I imagine in your original spec you would have specified a single logon page (not four different ones). This is a clue that all the different types of users should be of the same (or derived) types. :( Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Fri, Oct 8, 2010 at 11:18 AM, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 8 October 2010 14:56, radhames brito <rbritom-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > [...] > > Because you have one user model i have 4, so when i authenticate i have > to > > loop all the models to find the credentials beacuse there can be a > > company_user with name "pedro" and an admin name "pedro" because they are > 2 > > diferent models, there is another problem because those 2 pedros could > have > > the same password, all because i am using different models for each user > > type. > > > > I am sorry to have to point out that the route you have gone down here > supports Marnen''s contention that model definition should not be > started till the operational requirements are known. I imagine in > your original spec you would have specified a single logon page (not > four different ones). This is a clue that all the different types of > users should be of the same (or derived) types. > > :( > > Yes i see, the idea come after checking out how devise handles roles intheir examples, devise uses a sort of scope and roles can be different models, so i figure using this appreach would let me avoid the creation one big fat user model, but it didnt work as expected. Just take a quick look at devise and you will see where the idea come from. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote:> On 8 October 2010 14:56, radhames brito <rbritom-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> [...] >> Because you have one user model i have 4, so when i authenticate i have to >> loop all the models to find the credentials beacuse there can be a >> company_user with name "pedro" and an admin name "pedro" because they are 2 >> diferent models, there is another problem because those 2 pedros could have >> the same password, all because i am using different models for each user >> type. >> > > I am sorry to have to point out that the route you have gone down here > supports Marnen''s contention that model definition should not be > started till the operational requirements are known.Haha! Resistance is futile. You will be assimilated. [...]> > :( > > ColinBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Radhames Brito wrote:> Because you have one user model i have 4, so when i authenticate i have to > loop all the models to find the credentials beacuse there can be a > company_user with name "pedro" and an admin name "pedro" because they are 2 > diferent models, there is another problem because those 2 pedros could have > the same password, all because i am using different models for each user > type.From what I have read I suggest that you reconsider what exactly a user is, what data is specific to a user and what data is specific to certain classes of users. It seems to me, taking your statement above as a guide, that you are confused as to the actual arrangement of things in the real world. First, there is, and can only every be, one real person with the identity ''pedro''. There might be many people with similar names who are also known to your system but they are all different individuals. In a computer system, indeed in any organized filing system, some method of distinguishing between individuals other than by common name is required. Thus User IDs, SSNs, SINs, IRS IDs and so forth. Whatever the case, a given individual should have only one identity in a system and a single system identity should only ever refer to one individual. Second, the attributes of a company belong in something that is related to that society in its own right and not to any individual associated with it. Third, the user membership of a society is a separate issue as well. Consider that userid pedro might work for two companies at once. Or might work first for one company and then for a different company. This is an association or state that is distinct from either the user or the company even if it is dependent upon both. In a similar fashion, user pedro might have superuser privileges for one company but only user privileges for another. As I understand your proposal this person would require an entry with one userid in the company-admin model and another in the company-user model and possibly even more entries for different company-user or company-admin model combinations. This is a maintenance nightmare that you are creating. If instead you look at this from the point of view of entities and their relations then resulting data structure will be much more natural and will be easier to work with. So something like: User 1---n CompanyUser n---1 Company plus CompanyUser n---n UserRole n---n Role n---n RoleRight n---1 Right Is likely a more flexible way to obtain the requisite functionality. If you go with AuthLogic and Declarative Authorization then after these are wired into your app all you are left to implement with respect to RBAC is in essence just: Company 1---n CompanyUser n---n UserRole Which strikes me as a bit more manageable. Devise is an authentication system. The fact that it can be used to implement a primitive two-tier authorization system is a convenience for web apps that do not require a finer-grained approach to RBAC and wish to avoid the overhead of a full-featured RBAC implementation. I cannot see Devise''s authorization functionality dealing with anything very elaborate for the reasons that have been discussed at length in this thread. Namely, it either requires a separate User model or a separate User attribute for each and every role. The bottom line is that you have asked for advice. The advice that you are getting is uniformly against your chosen path. That is not to say that our advice is perfect or that your approach will fail. However, that seems the way to bet at the moment. -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > The bottom line is that you have asked for advice. The advice that you > are getting is uniformly against your chosen path. That is not to say > that our advice is perfect or that your approach will fail. However, > that seems the way to bet at the moment. >oh and i appreciate your advice very much, apparently every time i explain why i choose that path at the beginning readers think im jutifiying it, there is a confusion im not saying that the way i started is a good way , no no no, that design gave me a head ache but before refactoring i wanted to make sure the other options i was going to try wasnt wrong too (now im gona start with the features first and will create one user model with HBTM roles). There seems to be some confusion, i was convinced that my first approach was is wrong since like the third reply you guys gave. Right now i just want to know if anyone has had a similar problem and can give me any tips. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.