On Dec 9, 2:12 pm, WebbedIT <[EMAIL PROTECTED]> wrote:
> 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?
returning after flashing does not address your specific problem - it
is a good habit to get into though.
Try looking at your question from 'the other side'. Here's your own
code with some debug logic stuck in it - note specifically the last
comment http://bin.cakephp.org/view/883413034
Cake will not automatically try to render a view if it already has
done so (it sets autorender to false when it renders. see
https://trac.cakephp.org/browser/branches/1.2.x.x/cake/libs/controller/controller.php#L821
)
If you debug, the log will speak for itself.
Here's a simplified suggestion: http://bin.cakephp.org/view/1956130980
Here's a more thorough/comprehensive example:
http://trac.assembla.com/mi/browser/branches/base/controllers/abstract/app_controller.php#L240
regards,
AD
>
> 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
-~----------~----~----~----~------~----~------~--~---
