Re: Different logic and view for each group

Control what is displayed to the end user in your views as mentioned
before. Control user auth and access in the controller via the ACL or
other User auth implementations

You'll also want to make sure your Controllers are very user aware.
Just because the link doesn't show up in the view doesn't mean someone
isn't going to try and visit the link. Especially after seeing the
simple human readable structure of the url /product/28.

Never try to secure your site via the view or by simply hiding the
available actions from the user. The controller should be the place
you verify that the user is authorized to call it.

Even more important is remove the parameter data from the url and add
it to post data when the call is destructive. Like in a delete. don't
request product/delete/28, post product/delete with post data so your
controller can verify $this->data['Product']['id'] and also some other
hashed hidden field which gets changed and verified. Security
Component handles this hash for you and can verify that the field data
provided matches what was given. http://book.cakephp.org/view/175/Security-Component

I prematurely deployed a site which was not properly secure and woke
up one morning to an empty database. I know others have posted the
same thing and found that search robots had traversed the site and
stumbled on the many fascinating delete request. Now a day this is the
first thing I take care of when building a new site. Nothing like
learning the hard way to really make the lesson stick ;)

Lunar Darco

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 cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en