what AD said I can only confirm
if those are user records (which contain a user_id) you will have to
verify that those records belong to the right users, as well.
therefore I always use $this->find('first') in
- every edit action
- every delete action
at the very beginning
this way you can easily put in another condition (in our case user_id)and never assume that the (posted) user_id passed from the form is actually the right one. it can easily be manipulated (even with Security comp. on) therefore you will need to override the user_id in the controller or match it against the one coming from the find() statement above or omitting it using the "valid fields" array (third param of the save method). this way your records will be pretty secure. use a bake template that already does that for you and it saves you a lot of time in the long run some more information on this: http://www.dereuromark.de/2010/09/21/saving-model-data-and-security/ On 7 Dez., 17:50, AD7six <andydawso...@gmail.com> wrote: > On Dec 7, 5:28 pm, Matteo Landi <mat...@matteolandi.net> wrote: > > > > your definition of validate appears to differ from the frameworks. The > > > conclusion I was leading you towards was to always start with the code > > > bake gives you - and you are not. > > > You are right, in the previous sentence with ``validate'' I meant I > > needed to make sure that given id points to a record of the database. > > I have not taken into account the possibility of using bake because > > I'm working on a REST application which has nothing to do with forms > > of flash messages, so I decided to create each controller from > > scratch; however I could give it a try and see how generated > > controllers look like. > > Generally speaking controller code doesn't change whatever the means > of rendering results are. If it's purely for json/xml/whatever > consumption the only difference is likely to be no flash messages and > changing redirects to rendering confirmation messages/exceptions. > > > > > > > > > > > > > >> I think > > >> I will put that logic inside the beforeSave callback in order to keep > > >> controllers as simple as possible. > > > > Doing that doesn't make any sense, you're planning to put something in > > > a model that doesn't belong there. > > > The only problem I see with what I proposed before, is that it would > > be not easy at all to distinguish between save operations trying to > > create a new record, and edit operations trying to edit an existing > > one; probably a new Model->update method would fix that: add > > controllers would invoke save to create a new object, while edit > > controllers would call the update method (which would fail if there is > > no record with given id). Do you think this solution is breaking the > > MVC paradigm? > > Kind of depends. > > if you wanted to explicitly create update and insert functions in your > models, or app model, which simply called save as appropriate (insert > prevented the id being set, update ensures it is and it exists), > that's ok I guess. > > If your beforeValidate or beforeSave function runs if ($this->id && ! > $this->exists()) { return false; } what that does is prevent creating > rows with a specific id. If all your tables are autoincrement you > won't find anything wrong with that, but as a one-size-fits-all > solution thats a bad idea - creating rows with a specific id is a > common use case. > > However, I don't consider "does this row exist" data validation. it's > something the app controls. Just as "can user x edit this row" that's > not data validation either - it's something the app controls. trying > to edit something that doesn't exist is not a validation error - it > should be treated differently. Like $this->setFlash('Naughty naughty, > that dosen't exist and we're logging what you're doing"); $this- > > >redirect('/terms+conditions'); > > All in all starting with baked code (putting if (!$this->Post->exists($id)) { > throw new NotFoundException(); } in a controller edit > > action) means you start with consistent functioning code, it is 100% > applicable whatever db scheme you've got, it'll work almost without > editing whatever type of app you're building and puts the logic check > in the right place IMO. > > AD -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
