Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

monger.joda-time ns `print-dup` method relies on read-eval #59

Closed
ptaoussanis opened this Issue Jul 8, 2013 · 6 comments

Comments

Projects
None yet
2 participants

Hi guys,

Issue was reported by a Nippy user, Ref. ptaoussanis/nippy#14 (comment)

Not at all familiar with the Monger code base, so not sure what the best workaround would be.

Cheers! :-)

Owner

michaelklishin commented Jul 8, 2013

Well, it's a hack that uses undocumented reader features, I'm not sure if we can do that with, say, Nippy.

Hey Michael,

For some context, could you explain roughly why you're overwriting the default Date representation? Would the data-readers not be appropriate for your use case?

For security purposes, I generally recommend that most folks disable *read-eval* unless they absolutely know the implications and that the data they're dealing with is sanitary.

Owner

michaelklishin commented Jul 8, 2013

It was added in 1.3 days, maybe now there are better options to explore. One way is dropping 1.3 support. I believe
JDK dates can be serialized using 1.4's reader (as tagged literals) and that's sufficient for what monger.joda-time tries to do.

Not sure what your internals look like, but perhaps it'd be possible to do this coercion w/o needing to mod the reader at all? Is this coercion entirely internal, or is the user going to be interacting with the serialized-to-string forms?

Owner

michaelklishin commented Jul 8, 2013

It is there to enable dates to be serialized.

Got that much :-) Anyway, yeah - there are a number of possibilities ranging from a thread-local coercion to a namespaced or thread-local data-reader if you're prepared to bump to 1.4. Will leave it to you, but I would suggest the current behavior is dangerous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment