Well using UUIDs would result into /users/view/LONG-UU-ID-HERE Which would not resolve Cross Site Request Forgery. Use SecurityComponent and use form buttons that use method = post. That way "destructive" links get caught if no form security token was found.
I do it like this: http://github.com/ionas/sna/blob/master/www/app/app_controller.php#L11 http://github.com/ionas/sna/blob/master/www/app/controllers/messages_controller.php#L9 http://github.com/ionas/sna/blob/master/www/app/views/helpers/secure.php <?=$secure->link(__('Restore', true), array('action' => 'restore', $message['Message']['id']), array('class' => 'messageRestore'))?> <?=$secure->link(__('Remove', true), array('action' => 'remove', $message['Message']['id']), array('class' => 'messageRemove'), __('Are you sure you want to remove', true).' "' . $message['Message'] ['subject'] . '" permanently?')?> http://github.com/ionas/sna/blob/master/www/app/views/messages/mailbox.ctp Which generates "destructive" form buttons in an almost same way that normal html links are being generated. You can even style those buttons to look similar to normal text links (but I recommend you NOT to do this, data creating or modifying "links" should be html buttons, data searching/reading/fetching links should be html links, this is a good paradigma for/from the user point of view). You can read more about this topic here: http://www.ad7six.com/read/67-Generic-capability-based-security-(CSRF-prevention) http://teknoid.wordpress.com/2008/11/05/make-your-cakephp-forms-a-lot-more-secure/ http://teknoid.wordpress.com/2008/11/06/clearing-up-some-confusion-regarding-the-security-component/ The other way you could go would be to serialize and unserialize the complete request url. I recommend not to do that (bad for bookmarks for instance) King regards ionas82 On Jan 3, 6:45 pm, euromark <dereurom...@googlemail.com> wrote: > just use UUIDs > that "feature" comes with it automatically > > On 3 Jan., 08:41, Walther <waltherl...@gmail.com> wrote: > > > Not really possible afaik. > > > But, security through obscurity is not the solution. You should rather > > spend the time writing code that will make sure that the user/referer > > has permissions to perform that action. > > > On Jan 1, 9:54 pm, anka <andreas.katz...@gmail.com> wrote: > > > > Hi @all, > > > > I have a (almost) simple question! Is it possible to make all cake php > > > REST URLs unreadable? What I mean is, that a given REST URL like ".../ > > > user/delete/10" is very simple to read for a human and it is very > > > simple to guess that I can call this URL with any ID i want. So it > > > would be very helpful, to generate URLs like ".../ > > > aasdf080234ljasdflk234" or something like that so no human can modify > > > the URL within the browser and to avoid anoying side effects within > > > the system. > > > > Thanks and best regards, > > > Andreas 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
