Regression with empty nested attributes in parameters #8832

Closed
Chetane opened this Issue Jan 9, 2013 · 134 comments

Comments

Projects
None yet

Chetane commented Jan 9, 2013

Rails 3.2.11 is causing a regression when nested attributes have an empty value. For example, the following code works in 3.2.10 but throws an exception in 3.2.11:

            $.ajax('/home/index', {
                type: 'POST',
                contentType: "application/json; charset=utf-8",
                dataType: "json",
                data: JSON.stringify({ post: { comments_attributes: [] }}),
                error: function(response, status, jqxhr) { $("#response").html(response.responseText); },
                success: function(response, status, jqxhr) { $("#response").html("Request successful"); }
            });
        });

You can reproduce the bug with the following repro application:

This is breaking my application, and other will most likely encounter this exception. This commit is causing the regression: d5cd97b

hash[k] = nil if v.empty

+1

We had to work around this in production just after we deployed 3.2.11. An empty array is a perfectly reasonable value.

ienders commented Jan 9, 2013

+1

I don't usually comment on issues, but I'm sorry, this is pretty upsetting. An empty array and nil are not the same thing at all.

akavi commented Jan 9, 2013

+1

Why is the fix in JSON parsing instead of in query generation?

Note that this fix also strips nils from within arrays (eg. [1, 2, 3, nil] => [1, 2, 3])

Contributor

PikachuEXE commented Jan 9, 2013

Should be related to #8831

Chetane commented Jan 9, 2013

Definitely related. It's worth pointing however that in this case, an exception is thrown. In #8831, it silently strips nil. Both should definitely be fixed.

Owner

jeremy commented Jan 9, 2013

Please do investigate! Need a fix that doesn't result in args injection. See the tests @ d5cd97b#L7R27

Contributor

homakov commented Jan 9, 2013

tough question: leave nils and expect injection in find methods or remove them and get JSON broken. I don't know..

+1

Contributor

nicolasblanco commented Jan 9, 2013

+1.
My app is broken because of this patch. And this application does not even use ActiveRecord.

Contributor

homakov commented Jan 9, 2013

ok, +1 too

simonx1 commented Jan 9, 2013

+1

Owner

jeremy commented Jan 9, 2013

We have +7 but no code proposed. Please do investigate!

+1

jlsync commented Jan 9, 2013

+1 on this issue. Perhaps the solution is to delete the key from the params hash rather than setting the value to nil (which is my current work-around in a before_filter ).

TheBerg commented Jan 9, 2013

+1

rainulf commented Jan 9, 2013

+1

TheBerg commented Jan 9, 2013

After investigating it some more, I totally understand why this was implemented the way it was implemented. Rails needs to be secure by default.

Maybe we should add a params_from_post_data method that would still let people get around this. Thoughts?

I am investigating if this would work in my own applications. If it works and people feel like it is a good work around I'll submit a patch.

TheBerg commented Jan 9, 2013

Params from post data would look kinda like this:

  def json_params
    @json_params ||= ActionController::Parameters.new(ActiveSupport::JSON.decode(request.body))
  end

But would need to handle XML, JSON, etc. Thoughts?

@TheJeff : I'm not sure why empty JSON arrays are a security problem in ActionPack.

They may be a problem for AR, but but that's AR's problem, not ActionPack's.

TheBerg commented Jan 9, 2013

Oh, ActionController::Parameters.new is part of StrongParameters & Rails4, not in Rails 3.

TheBerg commented Jan 9, 2013

@mattgreen I agree, but don't see a way to fix this issue without severely crippling ActiveRecord (basically disallowing searching for nil values).

Personally, I feel like this is a per-application security vulnerability, but at the same time I respect the Rails Cores team working to make Rails secure by default.

Another way to fix this would be to extend StrongParameters so that a require or allow would make sure that that value is not an Array or Hash, but that would require people to move to StrongParameters.

Requiring people to use StrongParameters in Rails 4 would be an acceptable resolution to this bug.

But mutilating data that comes in to cover the persistence layer's weaknesses is ridiculous. I'm assuming this bug was an oversight.

+1 This will likely break things for us as well.

TheBerg commented Jan 9, 2013

@mattgreen I believe it was an oversight, but also I don't really know of any other way to solve this issue without doing it. I am racking my brain for a solution and I just can't think of another one.

@ghost

ghost commented Jan 9, 2013

We've created a before filter that will fix this issue until there is a new actionpack release see the gist here:

https://gist.github.com/4495772

abuggia commented Jan 9, 2013

+1

edawerd commented Jan 9, 2013

+1

xdaveyx commented Jan 9, 2013

+1

bartiaco commented Jan 9, 2013

+1

+1 seeing a lot of "undefined method `length' for nil:NilClass"...

Contributor

ndbroadbent commented Jan 10, 2013

Hi, here's my attempt at a fix: #8862

+1

foogoof commented Jan 10, 2013

+1 – please fix the fix!

rapid7/metasploit-framework#1281

A metasploit has been released to drop the attacker to a shell on vulnerable server.

We are currently unable to update to 3.2.11 because the regression breaks things.

Is there anything we can do in the meantime to mitigate the risk without updating?

Contributor

ndbroadbent commented Jan 10, 2013

@brightbits, if you don't use XML, add a file at config/initializers/cve_2013_0156_patch.rb, containing:

# Workaround for security vulnerability in https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML)
Contributor

imanel commented Jan 10, 2013

For everyone that have this problem - you can revert to old method with this: https://gist.github.com/e01089009479a1596056

BTW - it's sad that someone is messing all JSON-based applications just because there is small probability to corrupt something by searching nil in database. That's wrong solution to this problem and it should be reverted immediately.

Contributor

charliesome commented Jan 10, 2013

How about params becomes a cleaned version that only contains String, Array and Hash, and params.body is the un-tampered-with data from the request body.

Contributor

nicolasblanco commented Jan 10, 2013

@imanel : I totally agree with you. This is not the job of ActionPack to strip params from the user input just because it may lead to a leak in ActiveRecord.
I'm suffering from this regression and not even using AR at all in my latest applications.

Contributor

imanel commented Jan 10, 2013

@slainer68 did you tried my fix? I'm also not using AR and that fixed it.

Another thing is that releasing something like this together with critical path(second one is really critical) is stupid and surely will prevent a lot of people from updating :/

@imanel Your fix works but I've had to change it slightly: https://gist.github.com/4501559

This didn't fix everything for us as we use serialize :something, JSON which has the same problem!

Many thanks

Contributor

imanel commented Jan 10, 2013

@brightbits fixed my gist and tweaked a little. I'm pretty sure that serialize bug is not reported(this is related, but it's separate one) - please report and write test case.

@imanel

I'd remove the indentation with this

return unless request.format.json? 

We are currently investigating the serialize case, to work out the cause. A issue will be opened when we have more information

Contributor

imanel commented Jan 10, 2013

@brightbits that's correct. Still it's bypassing bug instead of fixing it. I just created pull request #8870 with revert of this functionality - that's probably only reasonable fix for this.

spilth commented Jan 10, 2013

+1

We're using the following work-around for this issue:

  • Keep initializer disabling XML parameter parsing from hotfixes linked above
  • Patch the ParamsParser middleware to remove the usage of deep_munge() from stripping empty parameters

This isn't ideal, but seemed like the best compromise to allow us to upgrade to 3.2.11 and take all of the other fixes (currently on 3.2.8)

Contributor

nfm commented Jan 11, 2013

+1.

Thanks for the hard work everyone. It's a tricky one to solve!

Owner

jeremy commented Jan 11, 2013

Secure by default! Pending a fix that helps prevent unintentional args injection, you can workaround in Rails 3.x by swapping out the default ParamsParser middleware with your own:

config.middleware.swap ActionDispatch::ParamsParser,
  ActionDispatch::ParamsParser,
  Mime::JSON => lambda { |body| Yajl.load(body).with_indifferent_access }

The previous workaround by @jeremy worked like a charm. Thanks! In fact, I learned that since 2.3.6 Rails uses yajl for json decoding if you require yajl-ruby.

@jeremy so where is this ParamsParser middleware file located please?

+1 on rails 3.1.10

Workaround from #8862 (comment) worked as a temp fix.

+1 on 3.0.19

+1

Owner

rafaelfranca commented Jan 11, 2013

This is already fixed

Owner

rafaelfranca commented Jan 11, 2013

And please before posting useless +1 comments, at least read the issue

Owner

rafaelfranca commented Jan 11, 2013

oops, pull request was not merged yet. Sorry

rafaelfranca reopened this Jan 11, 2013

+1 on reverting this back once the main security issue is solved.

Contributor

gnufied commented Jan 14, 2013

@rafaelfranca which pull request that you speaks of? Curious because want to review it.

Owner

rafaelfranca commented Jan 14, 2013

It is linked on this issue.

Contributor

gnufied commented Jan 14, 2013

@rafaelfranca there are many pull requests linked to this ticket. I am truly sorry, but I can't quite figure out, which one is being considered for being merged.

Contributor

imanel commented Jan 14, 2013

@gnufied there are only two pull requests linked to this issue - #8862 and #8870, out of which only one is open.

Owner

rafaelfranca commented Jan 14, 2013

@gnufied sorry I was away from computer so I could not link the pull request. I was talking about #8862

Contributor

imanel commented Jan 14, 2013

@rafaelfranca is there any possibility that Rails will start parsing JSON in correct way? Because #8862 is surely not fixing it. Something like optional switch dont_spoil_my_json?

Contributor

grosser commented Jan 15, 2013

FYI: monkey-patch for rails 2.3 and 3.0

mabahamo referenced this issue in thoughtbot/factory_girl Jan 15, 2013

Closed

NoMethodError .to_i when upgrading to Rails 3.2.11 #473

👍

Any updates to this issue? It's still holding us up from updating. I wish I understood what was going on and could offer more help then being a pest! 👍

Contributor

grosser commented Jan 17, 2013

It should be safer to just update and disable deep munge for now then not
update
On Jan 16, 2013 11:28 PM, "Altonymous" notifications@github.com wrote:

Any updates to this issue? It's still holding us up from updating. I wish
I understood what was going on and could offer more help then being a pest! [image:
👍]


Reply to this email directly or view it on GitHubhttps://github.com/rails/rails/issues/8832#issuecomment-12357297.

foogoof commented Jan 18, 2013

Apps have been securely broken for a week and a half. Hmm.

Contributor

zdennis commented Jan 25, 2013

arel seems to already have this fixed (as of last summer) in how query generation works.

These are not released yet (they only seem to be in master). It seems that the change mentioned in this commit that is problematic can be removed if these changes make it out into a release.

Contributor

zdennis commented Jan 25, 2013

Note: the above only deals with truly empty hashes or arrays and not arrays containing nil values.

Contributor

zdennis commented Jan 25, 2013

With regard to arrays containing nil values this is a strange fix at the framework level since since querying for nil in a collection is entirely valid (or invalid) depending on the context. It depends on what the application is doing.

I ❤️ that the workarounds for this is to completely ignore the fix that CVE-2012-0155 was supposed to supply.

If Rails keeps in this security fix to be secure-by-default then it seems it should at least be able to be turned off on a per controller/action/route basis and should be moved into StrongParameters. That would allow the application developer to make the call on an action-level and give people who currently have broken apps, can't upgrade because it breaks things, or don't want to undo the suggested security fix, globally for their app (which is the most ironic thing for the recommendation post-security-fix be to undo the security-fix.

I'd be happy to work on a patch if any one else can confirm this is a worthwhile line of thought to pursue. If it's not then there's no need wasting time.

Contributor

zdennis commented Jan 25, 2013

According to @dhh on rails/strong_parameters#82 @fxn is already working on the above described feature in StrongParameters.

@jsomara jsomara pushed a commit to jsomara/rails that referenced this issue Jan 29, 2013

@ndbroadbent ndbroadbent + Jordan OMara Fix #8832 - Parse '{"person":[]}' JSON/XML as {'person' => []}. f20b598
Contributor

zdennis commented Jan 29, 2013

@manlycode has a PR ( #9117 ) which will resolve unnecessary failures by ensuring that nils are treated the same as [] and {} previously.

@tenderlove tenderlove added a commit that referenced this issue Jan 30, 2013

@tenderlove tenderlove Merge pull request #9111 from jsomara/3-0-json-fix
Fix #8832 - Parse '{"person":[]}' JSON/XML as {'person' => []}.
10513d2
Contributor

jonhyman commented Mar 3, 2013

Is this is still an issue in the rails gem out on rubygems, 3.2.13.rc1? I'm concerned about breaking my app by upgrading.

Contributor

laserlemon commented Mar 5, 2013

@tenderlove's commit above doesn't solve the issue of the surprise introduced by an array parameter being changed to nil. This might.

One day at Rails world headquarters…

DHH: All these damn kids are using these snazzy front-end app frameworks. How can we compete?

DEV: What if we mangle all JSON input so whole subsets of the JSON language can no longer be expressed by a front-end client when talking to a Rails server?

DHH: Genius. We'll backdoor it the next time we have a massive security hole and everyone is eager to upgrade.

jpaas commented Mar 10, 2013

3.2.13.rc2 doesn't fix it either

👍

I'm using 3.2.12 and this isn't fixed yet!

jpaas commented Mar 18, 2013

Not a big surprise, but it's also not fixed in the new 3.2.13 release.

Owner

rafaelfranca commented Mar 18, 2013

Please do investigate. It is not fixed yet because no one come with a solution for it that doesn't introduce security holes.

Contributor

laserlemon commented Mar 18, 2013

@rafaelfranca I think I did. #9569

TheBerg commented Mar 18, 2013

@rafaelfranca What about #8862 ?

Owner

rafaelfranca commented Mar 18, 2013

I'll ask to our security team to review these pull requests. Thank you guys

Contributor

imanel commented Mar 18, 2013

Difference between #9569 and #8862:

Received JSON:

{"person":[null]}

Result in #9569:

{"person":[]}

Result in #8862:

{"person":nil}

First result is probably more acceptable(it preserves class of array no matter what) while second is breaking JSON even further(empty array => array, array with nil => nil). This still is not valid parsing of JSON, but at least it will not break so many APIs...

Contributor

ndbroadbent commented Mar 18, 2013

#8862 #8862 preserves the current
behaviour, since [null] is currently parsed as nil. It just adds a case so
that [] is parsed as [].

On Tue, Mar 19, 2013 at 8:26 AM, Bernard Potocki
notifications@github.comwrote:

Difference between #9569 #9569 and
#8862 #8862:

Received JSON:

{"person":[null]}

Result in #9569 #9569:

{"person":[]}

Result in #8862 #8862:

{"person":nil}

First result is probably more acceptable(it preserves class of array no
matter what) while second is breaking JSON even further(empty array =>
array, array with nil => nil). This still is not valid parsing of JSON, but
at least it will not break so many APIs...


Reply to this email directly or view it on GitHubhttps://github.com/rails/rails/issues/8832#issuecomment-15076137
.

Contributor

imanel commented Mar 18, 2013

Yes - that's exactly what I'm calling breaking it even further, as it increase inconsistency. Current behavior is totally breaking JSON applications, but at least is consistent. #9569 is not perfect, but much better than current behavior and #8862.

synth commented Mar 19, 2013

+1 - caught this in the wild with v3.2.13

TheBerg commented Apr 3, 2013

@rafaelfranca any update on any of these pull requests?

+1 This is causing us headaches developing a JSON api. There's no way that passing in { "some_array" : [] } should be recieved as { :some_array => nil }

Contributor

homakov commented Apr 13, 2013

we should rather replace nils with ''

panupan commented Apr 17, 2013

+1

Need it too.

mikeric commented Jun 21, 2013

+1

Contributor

timruffles commented Jul 3, 2013

+1

Contributor

artemave commented Jul 4, 2013

+1

krobi64 commented Sep 4, 2013

Was this resolved in 3.2.14? I don't see anything in the Changelogs.

Member

steveklabnik commented Sep 4, 2013

@krobi64 as you can see, the issue is still open.

Contributor

jonhyman commented Sep 4, 2013

@steveklabnik Do you know if this issue exists in Rails 4? We haven't upgraded to Rails 4 yet and I'm concerned that it'll break our JSON API if this problem still exists in Rails 4.

Member

steveklabnik commented Sep 4, 2013

I don't remember off the top of my head if this issue ever affected 4 or not, I think so?

Contributor

jonhyman commented Sep 4, 2013

Hm. What are other people on this thread doing to work around it? Is everyone just accepting this badness? We have tons of AJAX calls in our web app that post arrays, which can be empty [] -- when I had tried upgrading 8 months ago, lots of our controller actions broke for things such as NoMethodError :each on nil. We're still on 3.2.10 using the workaround described in https://groups.google.com/forum/m/?fromgroups#!topic/rubyonrails-security/61bkgvnSGTQ. We could live with the upgrade by always doing something like params[:my_array] || [] but that's suboptimal.

jlsync commented Sep 4, 2013

As mentioned above, I'm deleting the key

  before_filter :fix_params

  # my fix for https://github.com/rails/rails/issues/8832
  def fix_params
    if params and params['list'] and params['list'].key?('items_attributes') and 
            params['list']['items_attributes'].nil?
      params['list'].delete('items_attributes')
    end
  end

nerdrew commented Sep 11, 2013

@jonhyman Yeah, I just ran into it in Rails 4.0.0.

TheBerg commented Sep 11, 2013

@rafaelfranca @tenderlove Any way to get some love on this issue?

opyh commented Sep 26, 2013

Ouch, this is still open? :)

+1

mikeric commented Oct 24, 2013

+1

+1, Rails 4.0.0

nybblr commented Oct 31, 2013

+1. We need to be able to distinguish between "no value given" and "empty array," esp. as code rarely assumes anything unique about empty arrays.

By "no value given" I assume you mean nil? If so, here's one potential distinction:

arr = [] # Empty array
arr[0] # Element 0 returns nil

n = nil # No value given
n[0] # => Element 0 returns an error: NoMethodError: undefined method `[]' for nil:NilClass

Is this fixed in Rails 4.0.1?

kuon commented Nov 9, 2013

Still seeing the issue with 4.0.1

Contributor

laserlemon commented Nov 9, 2013

Milestone is set to 4.0.2.

Owner

rafaelfranca commented Nov 9, 2013

But this doesn't mean it will be included in 4.0.2 😄

+1 Still an issue for me. I need a JSON [] to not be changed to nil behind my back for my JSON API to work.

Contributor

imanel commented Nov 11, 2013

I would opt for removal of this - it's no longer necessary after permitted params were introduced.

Looks like #11044 should solve this.

LOL @ milestone 4.0.2.

"Hey guys, remember that time we broke compliance with JSON in a patch release? Well we're going to fix it in a patch release, too. Hope you didn't write any hacks to get around the asinine behavior."

Owner

rafaelfranca commented Nov 13, 2013

Like I said, the milestone doesn't mean it will be fixed on that milestone,
it is just to make sure we will revisit this issue when release that
milestone.
On Nov 13, 2013 8:52 PM, "Jason Petersen" notifications@github.com wrote:

LOL @ milestone 4.0.2.

"Hey guys, remember that time we broke compliance with JSON in a patch
release? Well we're going to fix it in a patch release, too. Hope you
didn't write any hacks to get around the asinine behavior."


Reply to this email directly or view it on GitHubhttps://github.com/rails/rails/issues/8832#issuecomment-28442476
.

Ah. Serves me right to open my mouth before reading all the comments (though in all honestly I'm squelching this thread now because it's just been 👍s for months now).

Chetane commented Nov 14, 2013

Can a contributor add the "Regression" label to this issue please?

Owner

rafaelfranca commented Nov 14, 2013

Agree with you we have to take a decision here. This is why I added the
milestone. I'll make sure we come with some solution before the 4.0.2
release. But it can be included only on 4.1.
On Nov 13, 2013 10:47 PM, "Jason Petersen" notifications@github.com wrote:

Ah. Serves me right to open my mouth before reading all the comments
(though in all honestly I'm squelching this thread now because it's just
been [image: 👍]s for months now).


Reply to this email directly or view it on GitHubhttps://github.com/rails/rails/issues/8832#issuecomment-28450070
.

Contributor

imanel commented Nov 14, 2013

@rafaelfranca what is the reason for deep munge after implementation of permitted params. From what I remember the reason was passing array instead of string, which is now prevented by default...

@carpeliam carpeliam added a commit to pophealth/popHealth that referenced this issue Dec 5, 2013

@carpeliam carpeliam set selected_measure_ids to [] if it's set to nil
This works around a rails bug; see rails/rails#8832 for more details
d4cc720

@carpeliam carpeliam added a commit to pophealth/popHealth that referenced this issue Dec 5, 2013

@carpeliam carpeliam set selected_measure_ids to [] if it's set to nil
This works around a rails bug; see rails/rails#8832 for more details
49cb82a

@carpeliam carpeliam added a commit to pophealth/popHealth that referenced this issue Dec 6, 2013

@carpeliam @eedrummer carpeliam + eedrummer set selected_measure_ids to [] if it's set to nil
This works around a rails bug; see rails/rails#8832 for more details
345a8aa

melcher commented Dec 11, 2013

+1

mikeric commented Dec 12, 2013

+1

luisobo commented Dec 13, 2013

👍

11449 commented Dec 17, 2013

+1

Member

chancancode commented Dec 20, 2013

Hey guys, thank you for submitting this and expressing your concerns about this issue! Speaking for myself, I understand where you are coming from, and I agree we could do better. Unfortunately, this PR does not meet our requirements for an acceptable solution to the problem.

Please stop responding with +1s and "me too"s. Those comments are only going to create noise for everyone and slow down the progress. We heard you loud and clear, and yes, we definitely care a lot about your opinion on this.

Instead, please head over to #13420 for the background and contribute your ideas. Thanks again! ❤️ 💚 💙 💛 💜

rafaelfranca locked and limited conversation to collaborators Aug 15, 2014

@juliusv juliusv added a commit to prometheus-junkyard/promdash that referenced this issue Nov 7, 2014

@juliusv juliusv Support for uploading dashboard definitions.
This enables PUT-ing and GET-ing of full dashboard definitions through
/<slug>.json. In this API, the 'dashboards_json' database field is
converted from a JSON string to a native JSON suboject of the Rails
Dashboard model JSON. The full externally exposed JSON looks like this:

{
  "name": "Test Dashboard",
  "created_at": "2014-11-07T00:25:57.000Z",
  "updated_at": "2014-11-07T00:38:23.000Z",
  "dashboard_json": {
    "globalConfig": {
      // ...global configuration...
    },
    "widgets": [
      // ...widget definitions...
    ]
  }
}

Upon PUT, the 'dashboards_json' field is validated against the
JSON-schema definition in the file 'dashboard_schema.json' and then
saved again as a string in a single database field.

Since Rails converts JSON empty arrays to "nil" values by default, this
also upgrades PromDash to Rails 4.1.1, which supports an option to turn
off this automatic conversion. See the following issues about this
regarding security implications (which for now we shouldn't need to
worry about in PromDash):

rails/rails#8832
rails/rails#13420

Further, as we're exposing the dashboard_json as an external API for the
first time, this also includes a lot of naming cleanups in the JSON
fields and the related code.
86c09b3

@juliusv juliusv added a commit to prometheus-junkyard/promdash that referenced this issue Nov 7, 2014

@juliusv juliusv Support for uploading dashboard definitions.
This enables JSON-schema-validated PUT-ing and GET-ing of full dashboard
definitions through /<slug>.json. In the external part of this API, the
'dashboards_json' database field is converted from a JSON-encoded string
to a native JSON subobject of the Rails Dashboard model JSON
representation. The full externally exposed JSON for a dashboard looks
like this:

{
  "name": "Test Dashboard",
  "created_at": "2014-11-07T00:25:57.000Z",
  "updated_at": "2014-11-07T00:38:23.000Z",
  "dashboard_json": {
    "globalConfig": {
      // ...global configuration...
    },
    "widgets": [
      // ...widget definitions...
    ]
  }
}

Upon PUT, the 'dashboards_json' field is validated against the
JSON-schema definition in the file 'dashboard_schema.json' and then
saved again as a serialized string in a single database field.

Since Rails converts empty JSON arrays to "nil" values by default, this
also upgrades PromDash to Rails 4.1.1, which supports an option to turn
off this automatic conversion. See the following issues about this
regarding security implications (which for now we shouldn't need to
worry about in PromDash):

rails/rails#8832
rails/rails#13420

Further, as we're exposing the dashboard_json as an external API for the
first time, this also includes a lot of naming cleanups in the JSON
fields and the related code.
b71abf8

@juliusv juliusv added a commit to prometheus-junkyard/promdash that referenced this issue Nov 7, 2014

@juliusv juliusv Support for uploading dashboard definitions.
This enables JSON-schema-validated PUT-ing and GET-ing of full dashboard
definitions through /<slug>.json. In the external part of this API, the
'dashboards_json' database field is converted from a JSON-encoded string
to a native JSON subobject of the Rails Dashboard model JSON
representation. The full externally exposed JSON for a dashboard looks
like this:

{
  "name": "Test Dashboard",
  "created_at": "2014-11-07T00:25:57.000Z",
  "updated_at": "2014-11-07T00:38:23.000Z",
  "dashboard_json": {
    "globalConfig": {
      // ...global configuration...
    },
    "widgets": [
      // ...widget definitions...
    ]
  }
}

Upon PUT, the 'dashboards_json' field is validated against the
JSON-schema definition in the file 'dashboard_schema.json' and then
saved again as a serialized string in a single database field.

Since Rails converts empty JSON arrays to "nil" values by default, this
also upgrades PromDash to Rails 4.1.1, which supports an option to turn
off this automatic conversion. See the following issues about this
regarding security implications (which for now we shouldn't need to
worry about in PromDash):

rails/rails#8832
rails/rails#13420

Further, as we're exposing the dashboard_json as an external API for the
first time, this also includes a lot of naming cleanups in the JSON
fields and the related code.
be9933f

@vuntz vuntz added a commit to vuntz/barclamp-crowbar that referenced this issue Jan 8, 2015

@vuntz vuntz Do not use deep munge
This is breaking the JSON parsing for empty arrays, which we use with
the magic crowbar-deep-merge-template feature when creating the initial
crowbar proposal.

With deep munge enabled, we cannot remove the nagios proposal, which
results in failures when nagios barclamp is not available.

See:
rails/rails#8832
rails/rails#13420

We can revert this once switching to rails 5 (see comments in second
issue).
e77d543

@vuntz vuntz added a commit to vuntz/barclamp-crowbar that referenced this issue Jan 8, 2015

@vuntz vuntz Do not use deep munge
This is breaking the JSON parsing for empty arrays, which we use with
the magic crowbar-deep-merge-template feature when creating the initial
crowbar proposal.

With deep munge enabled, we cannot remove the nagios proposal, which
results in failures when nagios barclamp is not available.

See:
rails/rails#8832
rails/rails#13420

We can revert this once switching to rails 5 (see comments in second
issue).
762e128

@vuntz vuntz added a commit to vuntz/barclamp-crowbar that referenced this issue Jan 9, 2015

@vuntz vuntz Do not use deep munge
This is breaking the JSON parsing for empty arrays, which we use with
the magic crowbar-deep-merge-template feature when creating the initial
crowbar proposal.

With deep munge enabled, we cannot remove the nagios proposal, which
results in failures when nagios barclamp is not available.

See:
rails/rails#8832
rails/rails#13420

We can revert this once switching to rails 5 (see comments in second
issue).
9905eef

@vuntz vuntz added a commit to vuntz/barclamp-crowbar that referenced this issue Jan 9, 2015

@vuntz vuntz Do not use deep munge
This is breaking the JSON parsing for empty arrays, which we use with
the magic crowbar-deep-merge-template feature when creating the initial
crowbar proposal.

With deep munge enabled, we cannot remove the nagios proposal, which
results in failures when nagios barclamp is not available.

See:
rails/rails#8832
rails/rails#13420

We can revert this once switching to rails 5 (see comments in second
issue).
01d6eda
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.