Jump to content

Storing JavaScript functions in JSON


NotionCommotion

Recommended Posts

I would like to store the following string in a database, and have the client download it and use it to configure a Highchart chart.  Ideally, I would like to download it as JSON, however, the 22nd line color: (Highcharts.theme && Highcharts.theme.contrastTextColor) || 'black' is not data but script and JSON is meant only for data.

 

So I could only think of two options:

  • Keep it as JSON but come up with some sort of encoding strategy where the script is turned into data, and then parse it client side.
  • Use it generate JavaScript on the initial page load.

Is one option better than the other?  Are there other options?  How would you recommend implementing?

 

Thank you

{
    "chart": {
        "plotBackgroundColor": null,
        "plotBorderWidth": null,
        "plotShadow": false,
        "type": "pie"
    },
    "title": {
        "text": "Browser market shares January, 2015 to May, 2015"
    },
    "tooltip": {
        "pointFormat": "{series.name}: <b>{point.percentage:.1f}%</b>"
    },
    "plotOptions": {
        "pie": {
            "allowPointSelect": true,
            "cursor": "pointer",
            "dataLabels": {
                "enabled": true,
                "format": "<b>{point.name}</b>: {point.percentage:.1f} %",
                "style": {
                    "color": color: (Highcharts.theme && Highcharts.theme.contrastTextColor) || 'black'
                }
            }
        }
    },
    "series": [
        {
            "name": "Brands",
            "colorByPoint": true,
            "data": [
                {
                    "name": "Microsoft Internet Explorer",
                    "y": 56.33
                },
                {
                    "name": "Chrome",
                    "y": 24.03,
                    "sliced": true,
                    "selected": true
                },
                {
                    "name": "Firefox",
                    "y": 10.38
                },
                {
                    "name": "Safari",
                    "y": 4.77
                },
                {
                    "name": "Opera",
                    "y": 0.91
                },
                {
                    "name": "Proprietary or Undetectable",
                    "y": 0.2
                }
            ]
        }
    ]
}
Link to comment
Share on other sites

I just recalled that I plan on storing data in the string, so it needs to be well formed JSON no matter which option I take.  Here are my thoughts:

  • Authorized user adds the initial JSON such as: '{"foo":"bar","script":"{{ javascript(); }} }'.
  • PHP confirms the string is well formed and identifies the nodes which have the {{ }} deliminator.  These node locations are stored in the JSON as meta data, and maybe the deliminator are stripped.
  • Either:
    • The JSON which includes the script node meta data are sent to the client via JSON, and the client takes appropriate action on the script nodes.
    • Two copies of the string are stored: one which is JSON and the other which is used to write the JavaScript on the client.
  • If the string needs to be edited, the deliminators are reinserted by the server allowing the authorized user to edit.

 

Thoughts?

Link to comment
Share on other sites

Option 3: Treat the contents as Javascript code and not JSON. JSON is inherently valid Javascript so anything already existing is still good, and you just consider the string to be (shudder) eval-uatable code.

var evaluated = eval("(function() { return " + value + "; })()");
At what point does the color need to be (re)evaluated? Is the theme data known server-side too?
Link to comment
Share on other sites

So you want the chart component to execute any JavaScript code? Even if that code steals the session ID, fetches the user password or executes drive-by malware? I hope not.

 

What I see is a plain simple color with fixed boilerplate code for the theme. That's not “I need to store and run arbitrary JavaScript code”. It's storing a plain simple color and then preprocessing the data with the fixed boilerplate code for the theme.

 

You should write a preprocessor or even wrapper for the Highcharts libray where you receive pure data from the database and then add all the dynamic parts. I wonder why Highcharts itself doesn't do that.

Link to comment
Share on other sites

Option 3: Treat the contents as Javascript code and not JSON. JSON is inherently valid Javascript so anything already existing is still good...

On my second post, I added the cryptic "I just recalled that I plan on storing data in the string, so it needs to be well formed JSON no matter which option I take.", so this is not so easy.  My reason is I wish to be able to change, for instance, just the title.  Sure makes it easier if it is JSON.

 

 

At what point does the color need to be (re)evaluated? Is the theme data known server-side too?

For color, I can keep it all server-side, so I don't have the need to store script.  There is also some other cases, however, where JavaScript is used in the Highchart config, and it would be nice to be flexible enough to handle these cases when they become evident.

Link to comment
Share on other sites

So you want the chart component to execute any JavaScript code? Even if that code steals the session ID, fetches the user password or executes drive-by malware? I hope not.

 

What I see is a plain simple color with fixed boilerplate code for the theme. That's not “I need to store and run arbitrary JavaScript code”. It's storing a plain simple color and then preprocessing the data with the fixed boilerplate code for the theme.

 

You should write a preprocessor or even wrapper for the Highcharts libray where you receive pure data from the database and then add all the dynamic parts. I wonder why Highcharts itself doesn't do that.

 

Your hopes have been met.  I don't want the first scenario!

 

Regarding color, I agree there are better strategies which don't require storing and running arbitrary JavaScript code.  There are other times, however, when JavaScript is used in the configuration, and I may not be able to use some sort of preprocessing.  Unless I can come up with a good way of deal ling with them, it seems like maybe I should not even attempt to support these other cases.

Link to comment
Share on other sites

What are those “other cases”?

 

And what do your users really need? Yes, I'm sure Highcharts can be pumped up with thousands of lines of highly dynamic JavaScript code, but unless you're targeting diagram fetishists, I'm sure most people just want to select a chart type, enter their data and be done with it.

Link to comment
Share on other sites

What are those “other cases”?

 

And what do your users really need? Yes, I'm sure Highcharts can be pumped up with thousands of lines of highly dynamic JavaScript code, but unless you're targeting diagram fetishists, I'm sure most people just want to select a chart type, enter their data and be done with it.

 

I agree implementing ever little feature of Highcharts isn't really necessary.  I just didn't know if I would later discover some user need which would require JavaScript.  For now, I will not attempt to do so.  Thanks

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.