Well, "the exact same serialization problems" do not exist with a database
because size doesn't matter so much. Security does matter more also because
of "replay" attacks, it is not just about keeping your key secret. Anyways,
that was meant as a warning.
I don't agree with the "alterable var" approach and changing the ring
handler to properly handle the API of read is less work than typing out
this email but if you want to alter a var you can probably alter
#'clojure.tools.reader/*data-readers* to get what you want. I prefer
explicit configuration over "transparent" vars spread all over but YMMV.
/thomas
On Wednesday, June 17, 2015 at 3:27:44 PM UTC+2, Surgo wrote:
>
> Let's not get into the motivation behind this too much -- the exact same
> serialization problems exist if you write out the session to a database.
> Ring also encrypts the cookies so the above issue is not a problem, it's
> only on you to actually choose and protect your encryption key.
>
> I came across *data-readers* as well.I did not find it possible to make it
> completely transparent if one was to use the REPL though because it is
> bound on entering the REPL. Furthermore I don't think it works with
> clojure.edn as well. However, it seems that
> clojure.core/default-data-readers does work with both clojure.core and
> clojure.edn functions. Thus I've solved the issue by altering
> clojure.core/default-data-readers to include my library's tag. This seems a
> bit hackish because I'm not sure you're supposed to be modifying this var,
> but it's the only thing I can find that both clojure.core/read{,-string}
> and clojure.edn/read{,-string} respect.
>
> > 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.
>
> I don't think the fault lies here with ring. It doesn't seem right to
> expect that library callers of these functions expose their full API to
> their own users...that would put a serious burden on them to more closely
> track the API as well. Better to have some alterable var so this can all
> run transparently.
>
> > it uses clojure.tools.reader.edn/read-string
>
> Ugh, thanks. I forgot about that one as well.
>
> On Wednesday, June 17, 2015 at 5:10:24 AM UTC-4, Fluid Dynamics wrote:
>>
>> On Wednesday, June 17, 2015 at 4:52:00 AM UTC-4, Thomas Heller wrote:
>>>
>>> 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. :)
>>>
>>
>> If you really do need to store session state that can potentially grow
>> that large, your best bet is to stick it in a server-side database and put
>> that table's primary key in the client-side cookie, looking up the state
>> object on receiving it back. This also prevents the end-user or a MITM from
>> monkeying with the state, which might prevent some types of attacks
>> (typically, session hijacking methods that aren't simple replay attacks, or
>> cheating to give yourself the super-duper armor for free in an online game,
>> or whatever). Remember when AT&T was embarrassed by some guy finding he
>> could peek at every customer's data just by changing an &custID=nnn sort of
>> URL parameter? Same thing can happen with a cookie that just says "logged
>> in as user#6178" or equivalent. Change it to "6179" and boom you're someone
>> else. But if the cookie is something like a random UUID that points to a
>> server-side DB entry that says "logged in as user#6178" fiddling with the
>> UUID will just produce error messages. Just don't use an autoincrement
>> integer PK or you are right back where you started. :)
>>
>>
--
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.
