aboutsummaryrefslogtreecommitdiffstats
path: root/activesupport/lib/active_support/json
Commit message (Collapse)AuthorAgeFilesLines
* [Active Support] `rubocop -a --only Layout/EmptyLineAfterMagicComment`Koichi ITO2017-07-112-0/+2
|
* Use frozen-string-literal in ActiveSupportKir Shatrov2017-07-092-0/+2
|
* [Active Support] require => require_relativeAkira Matsuda2017-07-012-4/+4
|
* Merge pull request #26933 from prathamesh-sonpatki/fix-26877Andrew White2016-11-131-1/+1
|\ | | | | Fix an issue with JSON encoding of "Infinity" and "NaN" values
| * Fix an issue with JSON encoding of "Infinity" and "NaN" valuesPrathamesh Sonpatki2016-10-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | - When `as_json` returns `Infinity` or `NaN` as the value of any of the key, we don't used to call `as_json` on it as it was treated as primitive. - This used to pass `Infinity` or `NaN` to `JSON.generate` and Ruby used to throw an error for `Infinity/NaN not allowed in JSON.` - This patch changes the code to call `as_json` on these primitives so that they are converted to proper values before being passed to `JSON.generate`. - Fixes #26877.
* | Add missing `+` around a some literals.bogdanvlviv2016-10-271-1/+2
|/ | | | | | Mainly around `nil` [ci skip]
* modernizes hash syntax in activesupportXavier Noria2016-08-061-1/+1
|
* applies new string literal convention in activesupport/libXavier Noria2016-08-062-8/+8
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Use correct timezone when parsing date in jsonGrzegorz Witek2016-01-221-2/+9
| | | | | | | | | | | | | Fixes https://github.com/rails/rails/issues/22171 Time specified in ISO 8601 format without `Z` should be considered as local time, yet until now it was treated as UTC. This commit fixes problem by parsing time using timezone specified in application config. The downside of this solution is performance hit (`Time.zone.parse` is ~ 1.6x slower than `Time.parse`), so maybe there's a better solution.
* Escape HTML entities in JSON keysRafael Mendonça França2015-06-161-0/+4
| | | | Fixes CVE-2015-3226
* Remove not used `options` argument from `ActiveSupport::JSON.decode`Carlos Antonio da Silva2015-05-131-8/+2
| | | | | | In Rails 4.0, json decoding relied on MultiJson. This changed from 4.1 forward since it reached its end of life, and this extra argument was kept for compatibility. We are safe to remove it now.
* Remove deprecated ActiveSupport::JSON::Encoding::CircularReferenceError.Rafael Mendonça França2015-01-041-22/+0
|
* Remove deprecated ActiveSupport::JSON::Encoding.encode_big_decimal_as_string=Rafael Mendonça França2015-01-041-27/+0
|
* edit pass over all warningsXavier Noria2014-10-281-1/+1
| | | | | | | | | | | | | | | This patch uniformizes warning messages. I used the most common style already present in the code base: * Capitalize the first word. * End the message with a full stop. * "Rails 5" instead of "Rails 5.0". * Backticks for method names and inline code. Also, converted a few long strings into the new heredoc convention.
* specify protocol for external linksRobin Neumann2014-10-152-2/+2
| | | | to ensure correct parsing result of rdoc
* Add support for JSON time_precision to Time and DateTimeAndrew White2014-01-261-0/+1
|
* Rename subsecond_fraction_digits option to time_precisionAndrew White2014-01-261-4/+4
|
* Customize subsecond digits when encoding DateWithTimeParker Selbert2014-01-261-1/+6
| | | | | | | | | | | The subsecond fraction digits had been hardcoded to 3. This forced all timestamps to include the subsecond digits with no way to customize the value. While the subsecond format is part of the ISO8601 spec, it is not adhered to by all parsers (notably mobile clients). This adds the ability to customize the number of digits used, optionally setting them to 0 in order to eliminate the subsecond fraction entirely: ActiveSupport::JSON::Encoding.subsecond_fraction_digits = 0
* JSON: speed up date/time encodingJeremy Kemper2013-12-111-24/+19
| | | | | | | | | | | | | | | | Comparing dates & times with other objects using #== is slow. Internally, it hits #<=> which calls #to_datetime on objects that don't respond to it, so we incur the cost of raising an exception with a possibly-deep backtrace. Cost of #jsonify on a Time object: Calculating ------------------------------------- old 3644 i/100ms new 12652 i/100ms ------------------------------------------------- old 43373.8 (±3.5%) i/s - 218640 in 5.047017s new 173437.6 (±5.2%) i/s - 872988 in 5.047747s
* Added back the `encode_big_decimal_as_string` option with warningGodfrey Chan2013-12-021-0/+27
| | | | | Also added the missing CHANGELOG entry for #12183 @ 80e7552073 and 4d02296cfb.
* EscapedString is also private API [ci skip]Godfrey Chan2013-12-011-1/+1
|
* Make the JSON encoder pluggableGodfrey Chan2013-11-261-2/+8
|
* Removed the Ruby encoder and switched to using the JSON gemGodfrey Chan2013-11-261-52/+72
| | | | | | | | | Got all the tests passing again. Support for `encode_json` has been removed (and consequently the ability to encode `BigDecimal`s as numbers, as mentioned in the previous commit). Install the `activesupport-json_encoder` gem to get it back.
* Removed support for encoding BigDecimal as a JSON numberGodfrey Chan2013-11-261-6/+0
| | | | | | | | | | This is because the new encoder will no longer support encode_json. Therefore our only choice is to return `to_i` or `to_s` in `BigDecimal#as_json`. Since casting a BigDecimal to an integer is most likely a lossy operation, we chose to encode it as a string. Support for encoding BigDecimal as a string will return via the `activesupport-json_encoder` gem.
* Move the JSON extension require statements to the right place.Godfrey Chan2013-11-061-8/+0
| | | | | | | In #12203, the JSON core extensions were moved into the `core_ext` folder. Unfortunately, there are some corresponding requires that were left behind. The problem is partially addressed in #12710, this commit fixes the rest.
* Do not expose internal state in the public encoder API (i.e. as_json)Godfrey Chan2013-11-061-37/+24
| | | | | | | | | | | | | | | See [1] for why this is not a good idea. As part of this refactor, circular reference protection in as_json has been removed and the corresponding error class has been deprecated. As discussed with @jeremy, circular reference error is considered programmer errors and protecting against it is out of scope for the encoder. This is again based on the excellent work by @sergiocampama in #11728. [1]: https://github.com/intridea/multi_json/pull/138#issuecomment-24468223
* Moved AS::JSON::DATE_REGEX as it's only used for decodingGodfrey Chan2013-11-062-3/+3
|
* Require time before monkey-patching itRobin Dupret2013-10-311-1/+0
| | | | | | Same as #12710 but for the time module this time. This time it should fix the Active Model test suite in isolation avoiding a TypeError to be raised about the superclass of the DateTime object.
* Require bigdecimal before monkey-patching itRobin Dupret2013-10-311-1/+0
| | | | | | | | If we try to monkey-patch the class before requiring it, then a "superclass mismatch" (TypeError) error is raised and the build can't run correctly. Fixes #12708
* Raise an error when AS::JSON.decode is called with optionsGodfrey Chan2013-10-301-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Rails 4.1 has switched away from MultiJson, and does not currently support any options on `ActiveSupport::JSON.decode`. Passing in unsupported options (i.e. any non-empty options hash) will now raise an ArgumentError. Rationale: 1. We cannot guarantee the underlying JSON parser won't change in the future, hence we cannot guarantee a consistent set of options the method could take 2. The `json` gem, which happens to be the current JSON parser, takes many dangerous options that is irrelevant to the purpose of AS's JSON decoding API 3. To reserve the options hash for future use, e.g. overriding default global options like ActiveSupport.parse_json_times This change *DOES NOT* introduce any changes in the public API. The signature of the method is still decode(json_text, options). The difference is this method previously accepted undocumented options which does different things when the underlying adapter changes. It now correctly raises an ArgumentError when it encounters options that it does not recognize (and currently it does not support any options).
* Moved all JSON core extensions into core_ext/object/jsonGodfrey Chan2013-09-131-195/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR The primary driver is to remove autoload surprise. This is related to #12106. (The root cause for that ticket is that json/add defines Regexp#to_json among others, but here I'll reproduce the problem without json/add.) Before: >> require 'active_support/core_ext/to_json' => true >> //.as_json NoMethodError: undefined method `as_json' for //:Regexp from (irb):3 from /Users/godfrey/.rvm/rubies/ruby-2.0.0-p195/bin/irb:16:in `<main>' >> //.to_json => "\"(?-mix:)\"" >> //.as_json => "(?-mix:)" After: >> require 'active_support/core_ext/to_json' => true >> //.as_json => "(?-mix:)" This is because ActiveSupport::JSON is autoloaded the first time Object#to_json is called, which causes additional core extentions (previously defined in active_support/json/encoding.rb) to be loaded. When someone require 'active_support/core_ext', the expectation is that it would add certain methods to the core classes NOW. The previous behaviour causes additional methods to be loaded the first time you call `to_json`, which could cause nasty surprises and other unplesant side-effects. This change moves all core extensions in to core_ext/json. AS::JSON is still autoloaded on first #to_json call, but since it nolonger include the core extensions, it should address the aforementioned bug. *Requiring core_ext/object/to_json now causes a deprecation warnning*
* Enabled quirks mode on JSON.parse, fixes broken test in af9caaeGodfrey Chan2013-09-121-1/+1
| | | | | | | It turns out that ActionPack depends on the decoder to parse JSON "fragments" (e.g. '"a string"', '1', 'null', etc), so we need to enable quirks mode on JSON.parse. Also added coverage on the decoder side to prevent regression.
* Replace JSON.load with JSON.parse, also removed the proc parameterGodfrey Chan2013-09-111-2/+2
| | | | | | | | | | | | | Since we are dealing with untrusted user input, we should not be using JSON.load. According to the docs[1]: BEWARE: This method is meant to serialise data from trusted user input, like from your own database server or clients under your control, it could be dangerous to allow untrusted users to pass JSON sources into it. The default options for the parser can be changed via the ::load_default_options method. [1] http://www.ruby-doc.org/stdlib-2.0/libdoc/json/rdoc/JSON.html#method-i-load
* Remove active_support/json/variable was deprecated.kennyj2013-06-012-19/+0
|
* Replace multi_json with jsonErik Michaels-Ober2013-05-111-21/+4
|
* Merge pull request #10534 from cmaruz/masterRafael Mendonça França2013-05-101-1/+4
|\ | | | | | | | | | | | | Escape of U+2028 and U+2029 in the JSON Encoder Conflicts: activesupport/lib/active_support/json/encoding.rb
| * Added escaping of U+2028 and U+2029 inside the json encoder.Mario Caropreso2013-05-091-3/+6
| | | | | | | | | | | | | | | | | | | | | | U+2028 and U+2029 are allowed inside strings in JSON (as all literal Unicode characters) but JavaScript defines them as newline seperators. Because no literal newlines are allowed in a string, this causes a ParseError in the browser. We work around this issue by replacing them with the escaped version. The resulting JSON is still valid and can be parsed in the browser. This commit has been coauthored with Viktor Kelemen @yikulju
* | Fix syntax error on Ruby 2.0Rafael Mendonça França2013-05-101-2/+4
| | | | | | | | | | Since Ruby 2.0 is UTF-8 by default we need to explictly say that the encoding of this file is US-ASCII
* | Escape multibyte line terminators in JSON encodingzackham2013-04-021-2/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, json/encoding respects the JSON spec (as it should) which disallows \n and \r inside strings, escaping them as expected. Unfortunately, ECMA-262 (Javascript) disallows not only \n and \r in strings, but "Line Terminators" which includes U+2028 and U+2029. See here: http://bclary.com/2004/11/07/#a-7.3 This pull request adds U+2028 and U+2029 to be escaped. # Why?  It's very common to see something like this in a Rails template: <script type="text/javascript">  var posts = <%= @posts.to_json %>; </script> If U+2028 or U+2029 are part of any attributes output in the to_json call, you will end up with an exception. In Chrome: Uncaught SyntaxError: Unexpected token ILLEGAL  # Why not? This is JSON encoding, and the JSON spec is specific about how to  encode strings. U+2028 and U+2029 don't get special treatment. Just trying to start a discussion... what do you do in your apps to deal with this? Is there a convention I'm missing?
* Revert "Simplify code in AS json encoder"Guillermo Iguaran2013-02-251-8/+15
| | | | | | This reverts commit 046e27a7338f2961c10e9d133e0e2229b51c2ba8. Check https://github.com/rails/rails/pull/8815#issuecomment-14026122 for details.
* Merge pull request #8815 from bogdan/simplified-to-json-argsSteve Klabnik2013-02-241-15/+8
|\ | | | | AS JSON encoder: remove monkey patch of Array
| * Simplify code in AS json encoderBogdan Gusiev2013-01-061-15/+8
| |
* | prefer american spelling of 'behavior'Gosha Arinich2013-01-071-1/+1
|/
* Remove unicode character encoding from ActiveSupport::JSON.encodeBrett Carter2012-12-141-7/+1
| | | | | | | | | | The encoding scheme (e.g. ☠ -> "\u2620") was broken for characters not in the Basic Multilingual Plane. It is possible to escape them for json using the weird encoding scheme of a twelve-character sequence representing the UTF-16 surrogate pair (e.g. '𠜎' -> "\u270e\u263a") but this wasn't properly handled in the escaping code. Since raw UTF-8 is allowed in json, it was decided to simply pass through the raw bytes rather than attempt to escape them.
* `#as_json` isolates options when encoding a hash. Closes #8182Yves Senn2012-11-121-1/+1
| | | | | | Setting options in a custom `#as_json` method had side effects. Modifications of the `options` hash leaked outside and influenced the conversion of other objects contained in the hash.
* Make caller attribute in deprecation methods optionalAlexey Gaziev2012-10-301-1/+1
|
* Provide a call stack for deprecation warnings where needed.Nikita Afanasenko2012-10-291-2/+3
| | | | It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
* update AS/json docs [ci skip]Francesco Rodriguez2012-09-142-12/+20
|
* Add back missing requireRafael Mendonça França2012-08-071-0/+1
|
* Fix the deprecation horizon. [ci skip]Rafael Mendonça França2012-08-071-1/+1
|