On 1/25/07, tobie <[EMAIL PROTECTED]> wrote:
>
> Colin, Michael, sanitizeJSON is an option and is off by default.
Regarding your patch: Shouldn't the X-JSON processing also use evalJSON() ?
And WRT to options.sanitizeJSON, how about a AJAX.sanitizeJSON global
option for the default behaviour? Then a developer he want to sanitize
every response can set this to true once and he does not have to
specifiy this option on every call.
string.evalJSON() returns
Object if everything is OK
null if eval failed
undefined if sanitize was requested and failed
Shouldn't the last case also return null?
On the Ajax object, a seed for a discussion on how it should behave:
transport.responseJSON is always initialized with "undefined". Users
can compare with undefined to see if there was JSON data in the
response at all.
If content-type is application/json:
- a possible X-JSON header is disregarded.
- the responseText is eval'd via string.evalJSON()
transport.responseJSON is set to the returned value, thous it is
* an Object, if evalJSON() succeeds
* null, if evalJSON() fails because the eval() failed
* null, if sanitize was requested and the data did not pass
Question: should failing the sanitize process in evalJSON()
trigger onException? I believe yes.
If content-type is not application/json:
(only the X-JSON part)
- the X-JSON header is eval'd via string.evalJSON()
transport.responseJSON is set to the returned value, thous it is
* an Object, if evalJSON() succeeds
* null, if evalJSON() fails because the eval() failed
* null, if sanitize was requested and the data did not pass
Result:
transport.responseJSON always contains the JSON object returned (if
there was any), regardless how it was transported.
Question:
The callbacks get a parameter list of (transport, json). The json
parameter is not needed any more, if transport.responseJSON is used
consistently, but we cannot let it go for compatibility reasons.
If If content-type is not application/json, json gets its value from
the X-JSON header.
If If content-type is application/json, should it gets its value from
from the responseText?
I say yes. It should not matter what way (header / body) was used to
transfer the data.
> If is data created by a user, you better sanitize it.
Sure, but the server script creating the JSON response should create a
valid JSON representation of the user supplied data. If it cannot
assure this, then this is the component to fix first.
Bye,
Martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" 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/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
