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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
