On 17 June 2015 at 09:51, Thomas Heller <th.hel...@gmail.com> wrote: > > 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. >
The cookie is only transmitted when the session changes. However, several browsers place limits on the size of stored cookies, and so it's generally not a good idea to serialize anything large into a cookie. On 17 June 2015 at 10:10, Fluid Dynamics <a2093...@trbvm.com> wrote: > > 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). > This is generally sound advice, but session cookies in Ring are encrypted and MACed, so they can't be changed by the client and remain valid. However, cookie sessions do have the disadvantage that they're hard to revoke. On 17 June 2015 at 14:27, Surgo <morgon.kan...@gmail.com> wrote: > 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. I don't think an alterable var is the solution. Dynamic vars tend to touch too many things. I think my preferred solution to this would be to add :serialize and :deserialize keys to the cookie-store's options. - James -- 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.
