First, take a look at ACL component. If you can make it work, that's
what you need. (Although it's really confusing, and I don't use it for
my needs).

If you decide to not use ACL, you'll use Auth component (that's just
being able to login; you'd use it with ACL, too), then store your
user.id in a session, and do authorization based on privileges of each
user (and user type).

Use only one User model. In it, have several boolean columns that
distinguish between user types (example below). Then, in your model do
validation s.t. an admin cannot possibly be a member, when they
register. Have several registration forms that only make some columns
available, but use the same model.

Your authorization (not to confuse with authentication) will go in
beforeFilter() of AppController.

example user table:

create table users(
`id` int(12) not null auto_increment primary key,
`username` varchar(200) null,
`password` varchar(60) null,
`first_name` varchar(200) null,
`last_name` varchar(200) null,
`created` timestamp default now(),
`is_admin` boolean default false,
`is_member` boolean default false,
`is_affiliate` boolean default false
);

But, you know, as soon as you feel that the thing is getting too
complex (which is likely), just go with ACL.

_V



On Mar 16, 1:44 pm, cricket <[email protected]> wrote:
> I'm just starting on a site that will have several types of users and
> am uncertain of the best approach to take. I'd like to hear from
> others who have done something similar.
>
> The site will have the following user types:
>
> Administrators
> Members
> Affiliates
>
> Admins may or not be Members. Affiliates will not be Admins nor
> Members, but the fields for Affiliates and Members are quite similar.
> However, they may diverge further down the road.
>
> All should be able to log in, so I plan to, at least, have a users
> table with the passwords. But I'd prefer not to have every possible
> field stuffed in there and instead use separate models for each type.
> This seems like a good fit for role-based authentication, using
> Groups, but I think it would make more sense to have separate Member,
> Affiliate, and Administrator models.
>
> But, in that case, how should I go about registering what a newly-
> logged-in User is? One idea I had was to include "model" &
> "association_key" fields in the users table, then loading the info as
> needed (because it will be stored Auth's session array).
>
> So, how have others approached this? ExtendableBehavior?
> InheritableBehavior? PolymorphicBehavior? Something else?

Check out the new CakePHP Questions site http://cakeqs.org and help others with 
their CakePHP related questions.

You received this message because you are subscribed to the Google Groups 
"CakePHP" 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/cake-php?hl=en

Reply via email to