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.
