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 to deal 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