The security component validates the allowed fields in a post.
What I was wondering is wether it really should validate (and
blackhole) fields in fields in fields the way it does at present?

Say a model has these fields:
User
    id -int
    prefs - blob
    password - varchar

In this case the blob can not be used to store serialised data since
Security invalidates the post when it finds that prefs is an array of
values. That is I can't post this kind of field, I guess because it is
not referenced in any schema: data[User][prefs][color][background]

I am a bit fuzzy on how that data could be a security problem since as
far as I can tell it will be ignored unless I actively serialise it or
otherwise make use of it.

As the title states, this is probably desired behavior but I thought
I'd ask since there has been tickets regarding similar data (I found
tickets for HABTM fields and selects).

regards
/Martin

Since questions about doing it some other way usually comes up:

The reason I use serialised data and not a relationship to another
table or fixed fields is that the prefs will hold different data for
different plugins and this is by far the simplest way to store simple
settings for an unknown number of plugins. I know it is not optimal
design but it is simple and enough for my needs.
If Security-checking posted data was optional it would be ok but now I
can't use any feature Security in the same controller as a form with
this kind of data, which is sort of the resulting problem for me.



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to