With the latest JSON gem 1.7.7, its breaking some of my code because I
was
using:
{“json_class”:“SomeClass”,“foo”:“bar”}
So the it doesn’t recreate the “SomeClass” object back with the new gem
update, I can make it work by passing in :create_additions => true but
that defeats the point of the update. The class has some attribute
values
that are defined by the user’s user_agent and cookie but in the code I
can’t see a way to create new attribute by the user.
Simplified version of some of the code:
class SomeClass
attr_accessor :name, :cookie, :user_agent
def initialize(params)
params = params.symbolize_keys
[‘name’, ‘coookie’, ‘user_agent’].each do |attr_name|
self.send("#{attr_name}=", params[attr_name])
end
end
Sorry forgot to mention I am using #parse but that doesn’t make it safe. This
article shows how parse is used to take advantage of this issue:
That article shows how parse /was/ used to inject, that was fixed, read
the security announcements and update your JSON if you still have that
problem. Parse was never meant to act like that and it was an oversight
that was quickly fixed once noticed by somebody.
[10] pry(main)> class MyClass
[10] pry(main)* def self.json_create(attributes)
[10] pry(main)* new.tap do |instance|
[10] pry(main)* attributes.each do |key, value|
[10] pry(main)* instance.instance_variable_set(
[10] pry(main)* “@#{key}”, value
[10] pry(main)* )
[10] pry(main)* end
[10] pry(main)* end
[10] pry(main)* end
[10] pry(main)* end;
Maybe the best option would be to stop serializing/deserializing classes in
general.
It depends on what you are serializing it for but I’m not here to judge,
all I can say is most of the time for what people are doing it for I
would probably consider it a dumb ass thing to do, but we all do dumb
ass things so I can’t really hate you or chastise you for it, only warn
that there are probably better ways to go about what you are doing, even
if it costs you more CPU time in terms of micro seconds that would
certainly be better.