By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,658 Members | 1,255 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,658 IT Pros & Developers. It's quick & easy.

JSON and the cyclical data structures...

P: n/a
Welcome
As suggested i looked into JSON project and was amazed but...

What about cyclical data structures - anybody was faced it in some
project ?
Is there any satisactional recomendation...

PS i am ready to use JSON as data/object interchange when using AJAX
and my J2EE project - because it is easier to traverse the JavaScript
object than its XML representation (so of course may argue).

Best regards...
LM

Nov 23 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
As i think more about it a askem myself a question - is there any JSON
extension which does a little more than:
- construction of object as name/value pairs;
- construction of arrays as values;

The extended functionality would be adding JavaScript functions to JSON
implemented in Java and send it to browser javascript code to produce
additional functionality - an object with arrays and functions !

Best regard.
PS probably i will add this functionality in JSON implementation in
Java...

Nov 23 '05 #2

P: n/a
VK
Luke Matuszewski wrote:
The extended functionality would be adding JavaScript functions to JSON
implemented in Java and send it to browser javascript code to produce
additional functionality - an object with arrays and functions !
If we're talking Java, let's say it in Java: Remote Methods Invocation
(RMI) technics :-)

JSON is a great idea, but IMHO the author just open the door and
stopped in the door step.

JSON++ (which is indeed badly needed now) should make full reliable
object serialization / deserialization so you could send an object to
server and get it back all filled with needed data.

*** and ***

I guess I'm in the author's kill-files but maybe someone will tell him:
did he ever wondered why so many requests recently about inserting
script from file / changing script src ?

The author is just answering on such requests and asking "Why do you
need it?".

You did not get it yet? People are doing AJAX over <script> using JASON
as the transport media!
People are hitting the stupid "same domain" limitation of
XMLHttpRequest more and more often. It all depends now of the incoming
IE 7.0 / FF 1.5: if the "same domain" limitation will be preserved (and
it looks like that) it may be the beginning of the decline of AJAX and
reuse of JASON++ where the script source handling will be build in into
package itself.
PS probably i will add this functionality in JSON implementation in


You are very welcome ;-)

Nov 23 '05 #3

P: n/a
VK
I called JSON as "JASON"

My fault:
<http://www.crockford.com/JSON/index.html>

Definitely a spoiling influence of the American sub-culture (but the
first movie is really cool)
:-D

Nov 23 '05 #4

P: n/a
I think that best and easiest way to pass JavaScript function using
JSON and not modifing it is to pass it as name / value pair ... value
would be:
function() {
/* code in JavaScript */
}

and then in JavaScript using XmlHttpRequest do:

var myObjectFromServerSide = eval(x.responseText);

myObjectFromServerSide.myFunc1 = eval(myObjectFromServerSide.myFunc1);

Am i correct ?

Nov 23 '05 #5

P: n/a
VK

Luke Matuszewski wrote:
I think that best and easiest way to pass JavaScript function using
JSON and not modifing it is to pass it as name / value pair ... value
would be:
function() {
/* code in JavaScript */
}
You did not read JSON right: the whole idea is to have a
platform-independent transport package. JavaScript function is
*JavaScript* function so on the other side have to know how to deal
with it. Array and Associative array structures are universal. So the
caller and the callee do not need to know to what language this
structure appertains to and what syntacs they need to look for / follow
and then in JavaScript using XmlHttpRequest do:
var myObjectFromServerSide = eval(x.responseText);
myObjectFromServerSide.myFunc1 = eval(myObjectFromServerSide.myFunc1);

Am i correct ?


It is explained on the JSON site (and I tend to believe) that explicit
eval() may lead to some complications. Specially it's true for
serialization / deserialization mechanics

So JSON's stringify(value) and parse(text) object methods should be
used instead.

And in future I see serialize(value) and deserialize(text) in JSON++
..
..
..
P.S. To whom it may concern: 1) there are all different *array* and
*associative array* in JavaScript and 2) javascript: psi-link may be
used.
But JSON indeed has some great potential I consider to be overlooked.

Nov 23 '05 #6

P: n/a

VK napisal(a):
It is explained on the JSON site (and I tend to believe) that explicit
eval() may lead to some complications. Specially it's true for
serialization / deserialization mechanics

My concept is to generete JSON object (with data in it) on server side
and pass it to XmlHttpRequest (and JSON Java Classes are for it - and
thank to Douglas Crockford i can construct in Java my data structures
and than use toString() method to produce String which be passed to
responseText property of XmlHttpObject then i will do:

var myObject = eval(x.responseTexT);

in my function triggered on onreadystate event of XmlHttpRequest.
I can use eval because the JSON site says i can:
http://www.crockford.com/JSON/js.html
<quote>
To convert a JSON text into an object, use the eval() function. eval()
invokes the JavaScript compiler. Since JSON is a proper subset of
JavaScript, the compiler will correctly parse the text and produce an
object structure.

var myObject = eval('(' + aJSONtext + ')');

</quote>

Furthermore one of my properties of myObject would by a String with
function code in it - so to make it function again i would use:

/* myObject.myFunc == "function() { /* some code */ }" */

/* alert(typeof myObject.myFunc == "string") yelds true */

myObject.myFunc = eval(myObject.myFunc);

/* alert(typeof myObject.myFunc == "function") yelds true */

The restriction is only one - in my myFunc string i cannot use " (but i
can use ' ) as JSON states.
So JSON's stringify(value) and parse(text) object methods should be
used instead.


I i want to get a string representation of my object than i would use

JSON.stringify(myObject);

Another issue is when i want to make additional check:

<quote>
When security is a concern it is better to use a JSON parser. A JSON
parser will only recognize JSON text and so is much safer:

var myObject = JSON.parse(aJSONtext);
</quote>

Hope you will understand.
BR
Luke.

Nov 23 '05 #7

P: n/a
VK

Luke Matuszewski wrote:
Hope you will understand.


Perfectly, Luke

And the JSON copyright entitle you to do whatever you want as long as:

<quote>
The Software shall be used for Good, not Evil.
</quote>

So you may start realizing your plans right now. If you have some code
ready in the future(and if you decide to keep it freeware) - do not
hesitate to post it here.

Nov 23 '05 #8

P: n/a
Luke Matuszewski wrote:
I think that best and easiest way to pass JavaScript function using
JSON and not modifing it is to pass it as name / value pair ... value
would be:
function() {
/* code in JavaScript */
}

and then in JavaScript using XmlHttpRequest do:

var myObjectFromServerSide = eval(x.responseText);

myObjectFromServerSide.myFunc1 = eval(myObjectFromServerSide.myFunc1);

Am i correct ?


That's what many people do, but it's not JSON. JSON is a specific
subset of JavaScript's syntax that only has literal structures like
arrays and strings--it doesn't allow arbitrary expressions. The
advantage of this is twofold:

1) A JSON parser is relatively straightforward to write in any
programming language, without requiring it to have a full JavaScript
implementation.
2) You can safely parse JSON without having to worry about security
vulnerabilities. eval() can only be used on data from trusted sources,
because anyone who has access to it can use it to get around the same
origin restriction.

I can imagine situations in which you would need eval() to dynamically
load code from a server, but it's not a great idea for static data,
especially since the JSON library is already freely available.

-- David

Nov 23 '05 #9

P: n/a

David Wahler napisal(a):
2) You can safely parse JSON without having to worry about security
vulnerabilities. eval() can only be used on data from trusted sources,
because anyone who has access to it can use it to get around the same
origin restriction.
Can you point how to get around the same origin restriction ? (Can i
use XmlHttpRequest open() URL parameter which is in different origin
(domain) than my script/document when i do it via eval( ) ? )
I can imagine situations in which you would need eval() to dynamically
load code from a server, but it's not a great idea for static data,
especially since the JSON library is already freely available.


And here you don't understand the concept. JSON site states that when i
have stringified JSON data structure a can use eval to get it back as a
reference in JavaScript so to use it as object/array/string etc.... (i
can also use JSON.parse - but it is slower then eval - and i don't have
to use parse if i know that received data from XmlHttpRequest object is
JSON stringified data structure).

BR.
Luke

Nov 23 '05 #10

P: n/a
VK

Luke Matuszewski wrote:
Can you point how to get around the same origin restriction ? (Can i
use XmlHttpRequest open() URL parameter which is in different origin
(domain) than my script/document when i do it via eval( ) ? )
You did not get it totally right because - I have to admit - the
relevant part of JSON docs is ambiguous. It doesn't talk about *that*
eval() from JavaScript. JavaScript eval() doesn't give you any extra
preferences to bypass browser security: neither with XMLHttpRequest,
nor with JSON, nor with any other tools.

But the method with the same name and function presented in many other
languages often used on the server side.

Think for example of a Perl server where you are admin and you have a
JSON module. So you're processing client request like:
eval $JSON_TEXT
and what if $JSON_TEXT contains `rm -rf /` string instead of JSON code?

You may want to check Unix shell commands to see what
eval `rm -rf /`
means to your server ;-)
And here you don't understand the concept. JSON site states that when i
have stringified JSON data structure a can use eval to get it back as a
reference in JavaScript so to use it as object/array/string etc.... (i
can also use JSON.parse - but it is slower then eval - and i don't have
to use parse if i know that received data from XmlHttpRequest object is
JSON stringified data structure).


You need to accept first author's understanding of security which is
much wider than just "can I format your drive or not?"

If a text doesn't contain a valid JSON data, eval(txt) will lead to an
error. If you did not put the eval block into try-catch block (or if
it's not supported) then eval(txt) will lead to an uncaught error and
script abort. This *is* a security violation (taking this wider look at
the security).

Nov 23 '05 #11

P: n/a
VK napisal(a):
This *is* a security violation (taking this wider look at
the security).

So now i understand... but i only meant to use eval in javascript.

Nov 24 '05 #12

P: n/a
"VK" <sc**********@yahoo.com> writes:
I guess I'm in the author's kill-files but maybe someone will tell him:
did he ever wondered why so many requests recently about inserting
script from file / changing script src ?

The author is just answering on such requests and asking "Why do you
need it?".


And right he is.

There is no reason to extend JSON with a variable assignment, since
Javascript already has that. If you send JSON as a Javascript, e.g.,
by changing the src-attribute of a script tag, you can also extend
what you send with a variable assignment. I.e., send it as Javascript,
but embed the JSON value in it, which you can since JSON is a subset of
Javascript.

That said, I can see a need for an object serialization format that
retains constructors and cyclic references, but that's a different
problem.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Nov 24 '05 #13

P: n/a

VK napisal(a):

So you may start realizing your plans right now. If you have some code
ready in the future(and if you decide to keep it freeware) - do not
hesitate to post it here.


Can you provide your jsFireReader ? I am interested ;-)

Nov 24 '05 #14

P: n/a
Luke Matuszewski wrote:
Welcome
As suggested i looked into JSON project and was amazed but...

What about cyclical data structures - anybody was faced it in some
project ?
Is there any satisactional recomendation...

PS i am ready to use JSON as data/object interchange when using AJAX
and my J2EE project - because it is easier to traverse the JavaScript
object than its XML representation (so of course may argue).


JSON, like XML, only serializes trees. Neither handle cyclical
structures directly. It is possible within either standard to define a
metalanguage which could be used to serialize cyclical structures.

This can be useful when persisting complex object systems. It is not
normally useful in the data interchange applications for which JSON is
intended.

www.JSON.org
Nov 24 '05 #15

P: n/a
VK
Luke Matuszewski wrote:
Can you provide your jsFireReader ? I am interested ;-)


<snip> !! :-)

But do not blaim on me: I decided to wait just a bit with the Gecko
part because FF 1.5 is due to be realeased within days. And "release
candidtates" (3rd now) have their security and XPConnect details
roaming like a marchandising boat in the boot.

So I want to see the final decisions first. And I do not want to post
IE-only part: this is comp.lang.javascript here, not some
microsoft.public.scripting.jscript

Nov 24 '05 #16

P: n/a
Luke Matuszewski wrote:
David Wahler napisal(a):
2) You can safely parse JSON without having to worry about security
vulnerabilities. eval() can only be used on data from trusted sources,
because anyone who has access to it can use it to get around the same
origin restriction.
Can you point how to get around the same origin restriction ? (Can i
use XmlHttpRequest open() URL parameter which is in different origin
(domain) than my script/document when i do it via eval( ) ? )


Sorry, I didn't phrase that very well. eval() doesn't break
cross-domain security by itself; however, it increases the likelihood
of cross-site scripting (XSS) attacks. Let me use a quick example:
suppose you have a fancy, AJAXified database which stores records in
JSON format, like so:

// (this is just an example)
var rowString = '{
"id": "12345",
"foo": "bar"
}';
var row= eval('('+rowString+')');
document.write(row.id);

If you use eval() to parse the rows, then anyone who can submit data
can inject code that runs in the context of your site. Since they're
running their code on your site, they're getting around the same origin
restriction, and they can then do all kinds of evil things:

var rowString = '(function() {
var req = new XMLHTTPRequest();
req.open("POST", "/messageboard/changepassword.cgi", false);
req.send("newpassword=haxxored");
return {"id": "I just changed your password!"};
})()';
var row= eval('('+rowString+')');
document.write(row.id);

This means that anyone who views that database row gets their password
changed, and their account compromised. If you don't think this type of
attack is plausible, MySpace--which had taken extensive security
precautions--had their security blown out of the water by a JavaScript
worm just over a month ago:
http://blog.outer-court.com/archive/2005-10-13-n73.html

If you don't want this to happen, you have (off the top of my head)
three options:
1) Use a real JSON parser on the client.
2) Use a real JSON parser on the server, that carefully verifies all
data that gets submitted.
3) Don't use JSON for client-to-server communications, but some other
protocol; this largely defeats the purpose of using JSON in the first
place, which is simplicity.
I can imagine situations in which you would need eval() to dynamically
load code from a server, but it's not a great idea for static data,
especially since the JSON library is already freely available.


And here you don't understand the concept. JSON site states that when i
have stringified JSON data structure a can use eval to get it back as a
reference in JavaScript so to use it as object/array/string etc....


I do understand the concept, but maybe I wasn't making myself clear (if
that is the case, I apologize). You can parse JSON with eval(), but
"can" is not the same as "should". The JSON site also states: "When
security is a concern it is better to use a JSON parser. A JSON parser
will only recognize JSON text and so is much safer."
(i can also use JSON.parse - but it is slower then eval - and i don't have
to use parse if i know that received data from XmlHttpRequest object is
JSON stringified data structure).


By all means, go ahead and use eval(), but bear in mind that you're
trusting your security to the integrity of that received data. If
you're confident that your data is trustworthy, that's your decision to
make.

-- David

Nov 24 '05 #17

P: n/a

David Wahler napisal(a):
This means that anyone who views that database row gets their password
changed, and their account compromised. If you don't think this type of
attack is plausible, MySpace--which had taken extensive security
precautions--had their security blown out of the water by a JavaScript
worm just over a month ago:
http://blog.outer-court.com/archive/2005-10-13-n73.html Well yes, because the XmlHttpRequest makes requests like real user -
so anyone that have access to web page source code can inject any
script that emulates user interaction...

- and after all the best solution is to disable scripting at all ;(
If you don't want this to happen, you have (off the top of my head)
three options:
1) Use a real JSON parser on the client.
This will insure me that response data on client side is verified JSON
data (no direct code in it)
2) Use a real JSON parser on the server, that carefully verifies all
data that gets submitted.
This will insure me that request data send by client side(submitted) to
server side is verified JSON data - no functions (Perl has also eval
which can eval even some worst things that all of as could imagine).
3) Don't use JSON for client-to-server communications, but some other
protocol; this largely defeats the purpose of using JSON in the first
place, which is simplicity.


Client-to-server communications was always a problem - because of
actions that server can take on client http request.
I can imagine situations in which you would need eval() to dynamically
load code from a server, but it's not a great idea for static data,
especially since the JSON library is already freely available.


And here you don't understand the concept. JSON site states that when i
have stringified JSON data structure a can use eval to get it back as a
reference in JavaScript so to use it as object/array/string etc....


I do understand the concept, but maybe I wasn't making myself clear (if
that is the case, I apologize). You can parse JSON with eval(), but
"can" is not the same as "should". The JSON site also states: "When
security is a concern it is better to use a JSON parser. A JSON parser
will only recognize JSON text and so is much safer."


Yep - but there is no eval in Java which will 'execute' recieved data
(or maybe there is but it must be used with advanced class loading
mechanism or methods that runs scripts on the command shell).
(i can also use JSON.parse - but it is slower then eval - and i don't have
to use parse if i know that received data from XmlHttpRequest object is
JSON stringified data structure).


By all means, go ahead and use eval(), but bear in mind that you're
trusting your security to the integrity of that received data. If
you're confident that your data is trustworthy, that's your decision to
make.


Thanks for arumentation and answer.

In security the only one thing will never change:
- the security is always as secure as the weakest element of the
security model (which in common are humans).

Nov 24 '05 #18

P: n/a
> This means that anyone who views that database row gets their password
changed, and their account compromised. If you don't think this type of
attack is plausible, MySpace--which had taken extensive security
precautions--had their security blown out of the water by a JavaScript
worm just over a month ago:
http://blog.outer-court.com/archive/2005-10-13-n73.html

If you don't want this to happen, you have (off the top of my head)
three options:
1) Use a real JSON parser on the client.
2) Use a real JSON parser on the server, that carefully verifies all
data that gets submitted.
3) Don't use JSON for client-to-server communications, but some other
protocol; this largely defeats the purpose of using JSON in the first
place, which is simplicity.


4) Use a real JSON encoder on the server.

A Samy attack is only possible with JSON if there are two blunders in
the server implementation:

A) Don't properly validate data from the client.
B) Don't properly encode the JSON text.

If you avoid either one of those, JSON is safe. You should always
validate and encode properly. For example, taking a string from the
database and simply concatenating quotes to it does not properly
encode a JSON string. It is necessary to make sure that quotes within
it are properly escaped.

Had MySpace used JSON for its messaging, we would not be talking about
Samy today.

http://www.JSON.org
Nov 24 '05 #19

P: n/a
VK

David Wahler wrote:
MySpace--which had taken extensive security


I'm sorry but the case description shows that MySpace had zero security
and this is why the case might happened.
* You cannot allow any real tags / style attributes in a public forum.
Only a preset set of pseudo-tags. *
This baby lore is being taught in sysadmin kindergardens.

But yes, you always have to be careful with a food you cannot know
anything about until you eat it - and eval() is such food.

Nov 24 '05 #20

P: n/a

Douglas Crockford napisal(a):
If you don't want this to happen, you have (off the top of my head)
three options:
1) Use a real JSON parser on the client.
2) Use a real JSON parser on the server, that carefully verifies all
data that gets submitted.
3) Don't use JSON for client-to-server communications, but some other
protocol; this largely defeats the purpose of using JSON in the first
place, which is simplicity.


4) Use a real JSON encoder on the server.

A Samy attack is only possible with JSON if there are two blunders in
the server implementation:

A) Don't properly validate data from the client.
B) Don't properly encode the JSON text.

If you avoid either one of those, JSON is safe. You should always
validate and encode properly. For example, taking a string from the
database and simply concatenating quotes to it does not properly
encode a JSON string. It is necessary to make sure that quotes within
it are properly escaped.


JSON.parse is for that - to be sure that received data (both on
client-side or server-side) are JSON data and nothing more.

Using JSON on client-side is extremly easy with JavaScript (and with
Perl on server-side - since Perl has very similar structures) <- it is
the main argument for me to use JSON in HTTP response which will land
in XmlHttpRequest responseText property. Using XML would require to
build algorithm to traverse data/build object. So i asked myself what
for ? if i have JSON then there it is - on one hand !

Yes, using JSON parse every time when i receive data on responseText
would be nessesery to build code that will not break or even do
somthing that i would not want it to do (see all replies above).

Another thing which made me to use JSON is its Java Implementation - i
can build JSONObject in Java code and build structures around it so as
a final step i use toString() - to post string to the client (UA) to
land in responseText....

And that two main reasons to use it - simplicity (XML need parsing and
require to use DOM methods to access its data - well or parse it
manually :))) ).

Best Regards.
Luke.

Nov 24 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.