Altering root vars is a bit of an annoying hack but it's the only way I've found so far to be fully transparent with already-existing code and libraries.
For anyone who needs Java serialization support I've wrapped all of this up into a simple library, which can be found here: https://bitbucket.org/morgon/jfreeze Cheers, -- Morgon On Wednesday, June 17, 2015 at 3:51:02 PM UTC-4, James Reeves wrote: > > On 17 June 2015 at 09:51, Thomas Heller <th.h...@gmail.com <javascript:>> > 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 <a209...@trbvm.com <javascript:>> > 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...@gmail.com <javascript:>> 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.
