Firstly thanks for such a comprehensive response :o) > Your issue stems from a combination of factors/bad habits/ > assumtpions ;)
I am ully aware that I have bad coding habits as I am totally self- taught and have never been part of a development team. I am hoping CakePHP will introduce me to using more secure and maintainable code. The MVC design pattern alone is a major step forward for me. > * Depending on your php config, a script will stop if it detects that > the client has dropped the connection > (http://es2.php.net/features.connection-handling) Do I need to familiarise myself with these PHP functions? Does Cake access them as part of the issue I am experiencing? > * Assuming that a flash will cause the controller action code to stop > (it doesn't. hint: *return* $this->redirect|flash|etc) I didn't assume it would stop the controller, but did assume it would override the action from rendering a view. It does 50% of the time, I could understand if it did the same thing all the time. > * Your delete method assumes that when it is called with a param it > will always succeed - you have no logic in place for an id present but > invalid/the delete not succeeding - hence if falls through and tries > to render a view As the app is only in it's working wireframe stage and I am the only one testing it the action is only ever receiving valid IDs. As such it is not the lack of invalid parameter logic that is causing the issue. If however the action is doing some strange redirection and therefore running the delete twice, then the second time it would fail as the first run through would have removed the record in question. Could this be the case? > * Your delete method works with only get params - so if by chance or > malicious intent a page generates a request to /whatever/delete/anint > - it'll perform the delete with you none the wiser (although if you > used session setflash you would probably see a confusing (because you > did it yourself, but not deliberately) "xyz with id 123 deleted" > message) - As a concequence a duplicate delete request will show a > missing view because it doesn't exist to be deleted (see previous > point). Google csrf for more details. Again, an area I much do more work in. I am hoping that Cakes built in data sanitization and security component will help me to make my code more secure as I know my code to date is vulnerable to CSRF attacks and SPAM attacks. This is not so much an issue with this app as it is a closed application, but I recognise the importance of adressing such issues. > You'll probably find you get bored of delay and annoyance of seeing > flash message screens I was wondering this myself, I don't mind the flash and delay as a method of informing the user of action updates, but I expect some clients will not share the same opinion. > use session set flash with or without a > redirect depending on whether you want to redirect the user or not > (but RETURN or otherwise prevent any further controller/model logic > from executing and don't rely on your redirect/flash/whatever to > prevent further code from executing) - but the problem in brief is not > accounting for all logical possibilities. So in short, should I be applying a return; command after flashes if I want the action to stop at that point? Thanks again for your time --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
