> Would the Security component be a solution to this problem?
Kind of, but not really. The Security components handles access
requests at the HTTP level, and while it can detect and deflect POST
requests that don't come from within the application, it is still
possible inject form elements or sp
Would the Security component be a solution to this problem?
http://manual.cakephp.org/chapter/18
With it, I believe you can ensure that people can't post data to your
controller from another server - so they'd have to somehow change the
html form on your own server for it to validate. I've never
I suppose we could add an option to treat the whitelist as a blacklist,
but anything beyond that and we're getting ahead of ourselves.
Handling security at this level is very application-specific.
--~--~-~--~~~---~--~~
You received this message because you are sub
in your model file you could create your own save function that has a default $whitelist that then gets passed to the parent::save()Sam DOn 7/7/06,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
While, I feel a little less sheepish for not having noticed that ifthese guys didn't either. I'm going to
While, I feel a little less sheepish for not having noticed that if
these guys didn't either. I'm going to have to print out the api for my
bedtime reading :-)
I'm still not sure I like that solution best... when my user model
contains 40-some fields, I'd rather not be passing arrays of that size
Ahh you are right, it does take such a parameter. Hmm I'm beginning to
wonder why I've got this
great CakeSheet laying next to me if I don't actually look at it : p.
--
http://www.thinkingphp.org
http://www.fg-webdesign.de
Samuel DeVore schrieb:
I belive that model::
Hey Samuel,
Nice tip, that's going straight to the pool room.
Ryno
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe fr
I belive that model::save takes a third parameter of fields to savehttp://api.cakephp.org/class_model.html#ef348bd6a62f8196fe42b2cebafc945f
Sam DOn 7/6/06, Felix Geisendörfer <[EMAIL PROTECTED]> wrote:
Hey Chris,
I think you've got a good point there. One solution I could think of is
to
Hey Chris,
I think you've got a good point there. One solution I could think of is
to do something like this:
class PostsController extends AppController
{
var $name = 'Posts';
function update()
{
$post = $this->__limitFields($this->data['Post'],
array('text', 'title'
> [mailto:[EMAIL PROTECTED] On Behalf Of Chris Renner
> Now, this fix for this can be easy: in my action, unset those
> fields I
> don't want to be writable. But it seems like there must be better way
> to do it... based on user roles in the before_filter perhaps? Or even
> in the model? What'
It just occurred to me that I've left a serious security hole in my
recent cake apps. By blindly using $this->params['data'] in my save,
I'm leaving a hole for users to change whatever fields they want to. I
want to remind people about the potential for this, and see if the
group has a more el
11 matches
Mail list logo
