Channels
#server
- t
tipsy
06/28/2017, 6:20 PMit's just a very thin wrapper on top of the servlet request/response - t
tipsy
06/28/2017, 6:20 PMi'm extremely lazy 😄 - d
dave
06/28/2017, 6:20 PM@orangy for our web-apps, we generally rely on encrypted cookies. no session state. - d
dave
06/28/2017, 6:20 PM@tipsy that's a good trait 🙂 - t
tipsy
06/28/2017, 6:21 PMi thought the servlet spec would be easy enough to interface with, since it's so old.. but it's proving more difficult than i had hoped - o
orangy
06/28/2017, 6:23 PM@dave well, do you use just raw cookies, or do you mean you store session data in cookies? - d
dave
06/28/2017, 6:24 PMTBH it's a bit of both, depending on the use-case. - o
orangy
06/28/2017, 6:25 PMYep, that’s the most interesting part: use cases 🙂 - d
dave
06/28/2017, 6:27 PMeven when it's "session state", it's nothing more than an encrypted serialised JSON object of identifiers. I wouldn't store anything complex or mutable in there. - a
andrewoma
06/28/2017, 6:28 PM@orangy Our sessions are almost always random ids with server side state. The state is very lightweight and usually stored in redis as string - o
orangy
06/28/2017, 6:29 PM@andrewoma and what’s there in a session on a server? Do you store json, or serialized instance of some data class? Or simply a string map? - a
andrewoma
06/28/2017, 6:33 PMFor server to server we're more likely to use basic auth - a
andrewoma
06/28/2017, 6:37 PMIt's usually just a long that maps to the user id. We sometimes serialise to JSON if there's more data. e.g. a device id to lock a session to a particular device - o
orangy
06/28/2017, 6:39 PMHmm, so you have a random id in a cookie, that maps to a long which is a user id? - a
andrewoma
06/28/2017, 6:40 PMThe servers themselves will cache user details by id - sessions never store mutable data - a
andrewoma
06/28/2017, 6:42 PMPretty much. We don't trust the stateless encrypted/signed approach - o
orangy
06/28/2017, 6:43 PMI see. So, when you need some user data for current session, how would the code look like? Schematically. - a
andrewoma
06/28/2017, 6:47 PMThe session ids are also hashed when stored or looked up from something like redis to prevent extracting of session ids and spoofing of sessions - a
andrewoma
06/28/2017, 6:52 PM1. Extract session id from header. 2. Get session from session store by session id 3. Get user id from session then fetch user plus permissions (cached) 4. Check permissions 5. Proceed - a
andrewoma
06/28/2017, 6:55 PMCode wise this is usually done by filters and annotations in Java - o
orangy
06/28/2017, 6:56 PMAre your sessions strongly typed like serialized classes, or property bags (Map<String, String>)? - a
andrewoma
06/28/2017, 6:58 PMStrongly typed and serialised to JSON - a
andrewoma
06/28/2017, 7:02 PMIn Dropwizard you'd just add a parameter annotated with @AuthUser to the function that serves the request and write the code that plugs into auth filters - o
orangy
06/28/2017, 7:06 PMMeanwhile reading some posts on session and stuff… it’s complicated… - a
andrewoma
06/28/2017, 7:06 PMI must admit I found ktors session object reflection stuff a bit weird. At the low level we're all happy to serialise without framework support - o
orangy
06/28/2017, 7:07 PMYes, it’s a little bit not aligned with the rest of APIs and somewhat bolted together. That’s the main reason I’m looking into it. - a
andrewoma
06/28/2017, 7:12 PMOops 5am. Better put the phone down and get some sleep!💤 2 - v
vonox7
06/28/2017, 8:34 PM@orangy We are using sessions with signed cookies from the server, which contain a user login token. The server looks up the userId of the loginToken on each request. That’s all we need to store in the session. - s
spand
06/29/2017, 7:16 AM@orangy Our use is mostly the same as Andrews. The data is just a (sessionid, userid) mapping in a database. We just use raw cookies so no experience with the ktor session stuff. - o
orangy
06/29/2017, 7:26 AMThanks!