Hey,
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring. Should be a
fairly simple fix though, doing anything to clojure.edn won't help as it is
not used.
On another note: Sessions in cookies should be VERY VERY small.
java.io.Serializable usually isn't small and especially if you go java
object -> binary -> base64 -> base64 (yes twice) -> encrypt. The size of
the cookie matters as it is transmitted with EVERY request.
I would recommend writing print-method implementation for the Java objects
you need to serialize and keeping those to a minimum. Session cookies are
not arbitrary storage and writing a "transparent" serialization format that
doesn't check the size will lead to uncontrolled growth. I have seen way
too many web apps with cookies above 4kb. One even had Apache configured to
reject requests (well, default config) that had too large cookies and no
one even noticed except for the users that left confused and never came
back.
Just as a warning. :)
Cheers,
/thomas
On Wednesday, June 17, 2015 at 3:47:39 AM UTC+2, Surgo wrote:
>
> I've been working on a Ring app that involves storing sessions as cookies,
> and within the session there are a couple Java objects that implement
> java.io.Serializable. I was somewhat surprised to find that the print-dup
> multimethod didn't have native support for Java Serializables, though I can
> understand why (they aren't really meant for long-term storage because
> version changes are troublesome). It wasn't too much trouble to come up
> with a basic implementation that could cover all of java.io.Serializable:
> https://bitbucket.org/snippets/morgon/jkjyA
>
> The trouble I'm having comes with reading it back in, though. In the above
> snippet, we output as a function call and depend on the behavior of
> clojure.core/read{,-string} to evaluate the function where the magic
> happens. This obviously doesn't work with the safer and recommended
> clojure.edn/read{,-string}. According to the EDN specification I should be
> able to set a dispatch tag like, say, "#java <base64>" and attach a
> deserialization function to :readers for the tag. This isn't transparent
> though: I can't just include the library and have it work with Ring's
> already-existing (de)serialization, nor anywhere else that doesn't
> explicitly pass my special function to clojure.edn/read{,-string}.
>
> Is there anything I can do without filing a ticket and hoping something
> comes to be a part of the core library? To the best of my knowledge there's
> no binding I can alter for the :readers or :default options for
> clojure.edn/read{,-string}; that needs to be passed directly into the
> function at the call site. I could maybe alter the clojure.edn/read and
> clojure.edn/read-string vars themselves to wrap them so I can pass in a
> :readers option with my tag, though that seems kind of nasty and I'm not
> sure it will work in 100% of cases. What is there that can be done for this
> problem?
>
> Thanks,
> -- Morgon
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
