I think I should clarify. I think Adam correctly understood what I was trying to get at. For further context, look at the blog example code and how they use the HTML helper to craft the links to actions like deleting posts, creating posts, etc. So you get a delete link that when you hover you see a URL that you could copy into the address bar, modify parameters and press enter. Even my mom could notice the connections :-).
I fully understand that tools abound to discover things that are slightly better hidden. Heck, even with POST, someone can just look at the page source and see the action, etc. And I have no doubt that tools for forging POST info exist. And yes, I totally agree that to thwart a determined hacker you have to have server side security to prevent SQL injection, etc. I fully plan to implement all that. Who knows, maybe I miss something somewhere. I guess I just don't like the "hover" effect making it clear to any average Joe that if they just type in a crafter URL into the toolbar, they might be able to cheat my app. Hopefully all my server side controls will prevent that, but then I will have to create all the pages that inform the user they aren't authorized to call that action from where they are at, yada, yada. If I just contain the actions that "do stuff" to POST input, I can discourage the creative exploration and temptation to "try this" that people like me tend to do when they see the app logic so blatantly exposed through hyperlinks which you can just hover over. I think the answer I am getting from Adam is what I was thinking. Use POST for actions that "do stuff" to the database, regular URL based actions for just simple viewing type actions. ...And know that that is not "security", at least not real security, but just a simple frontline measure to discourage the average attempt at tampering. What I am getting from Miles is the authorization mechanisms to implement on the server side, which is part B to the answer. I see that, for example, I can limit it so that an action is only callable by a POST, so even if someone figures out how to craft a URL, it won't work because the Cake won't allow it. But that means that the view that allows the user to select that action CANNOT use the typical URL based linking (as in the blog example), which goes back to my original question, of whether the blog example is typical for a real world app that allows data modification, or just instructive to show how things are linked up in CakePHP. Thanks all! I think that answers what I was looking for. Particularly, thanks Adam. Spot on what I was looking for. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
