00:00:23 <stepcut> yeah
00:02:13 <donri> or maybe we're stupid for trying to make a document transport into an application platform ;)
13:31:14 <stepkut> if you do a 'git add' and then change the file more and do a 'git commit', it only records the changes up to when you did the 'git add' ?
13:36:04 <stepkut> I managed to send a pull request for a patch that only contained half the changes I assumed actually got committed :-/
13:36:33 <stepkut> git strikes again
13:59:16 <Entroacceptor> stepkut: that's your fault for not knowing git :)
13:59:32 <Entroacceptor> git has three layers, the working copy, the staging area and the commits
13:59:58 <Entroacceptor> git commit commits the staging area to a commit; git add pushes the file to the staging area
14:00:11 <Entroacceptor> the file as it is right now
14:02:50 <donri> stepcut: git commit -a works more like darcs record
14:03:07 <donri> well, darcs record -a
14:03:24 <donri> plain record is something like, add -i; commit
14:03:57 <donri> oh, git commit -p
14:06:41 <donri> also: git diff shows the changes in the working copy, diff --cached shows the staged changes, git show shows the HEAD commit, could also do something like diff master..origin/master
15:30:25 <donri> we probably should make httpOnly not configurable too in clientsession
15:30:55 <donri> if you want to read it in JS, you need to send the client your server-side crypto key
15:31:27 <stepkut> k
15:31:32 <stepkut> with httpOnly = True then ?
15:31:37 <donri> yes
15:31:39 <stepkut> make it so!
15:31:54 <donri> i will!
15:32:13 <stepkut> I am less certainly about what to do about the http cookie hijacking potential
15:32:25 <donri> sessionSecure?
15:32:29 <donri> yeah
15:32:52 <donri> you really shouldn't use clientsession without tls, but it does make development harder
15:33:10 <stepkut> yeah.. though using happstack-server-tls is not *that* hard
15:33:32 <stepkut> I guess my big concern is that if it only works with https, then we need to have a clear way to indicate why it is not working if you try to use it with http
15:33:47 <donri> yeah
15:33:53 <stepkut> for example, if it just silently doesn't send the cookie.. that would be bad
15:34:12 <stepkut> if it throughs a 500 Internal Server Error message and says, client session only works with https.. that would probably be fine
15:34:20 <donri> we should at minimum make it clearer in the docs, but probably we should do something more visible too
15:34:26 <stepkut> even, better, the message should link to a page the explains why and shows how to set it up with https
15:34:29 <donri> yeah
15:35:30 <donri> also happstack-clientsession is still pretty much unusable because you have to manually define the HSP instances
15:35:39 <donri> which most people have no clue how to even do
15:40:39 <donri> also maybe we should sketch out the plans for a serversession... we discussed it but i don't think we took notes?
15:41:41 <donri> (a serversession is similarly vulnerable to XSS and hijacking, though)
15:42:59 <stepkut> right
15:43:03 <stepkut> sessions are only safe over https
15:43:10 <stepkut> no matter what you do, AFAIK
15:43:18 <donri> pretty much
15:43:44 <stepkut> so, for a serverside session.. we need a way to create a sessionid
15:43:52 <stepkut> and then places to store data on the server
15:44:02 <stepkut> and ways to expire sessions
15:44:15 <stepkut> there are also two ways you might want to store session data on the server
15:44:33 <stepkut> persistently (via acid-state or something) and non-persistently (via STM or something)
15:44:48 <stepkut> non-persistently also implies that you are probably not going to worry about replication
15:44:54 <donri> the benefits of a serversession is ACID and less size limits. downsides are that it requires a round trip to the database, and to expire it you need to issue writes even
15:45:09 <stepkut> yeah
15:45:37 <stepkut> for expiring sessions.. if you do not care about replication you could store the expiration stuff in STM
15:45:39 <donri> you had some ideas for efficient expiration that was a bit like "eventual consistency" IIRC
15:46:06 <stepkut> yeah.. happstack-authenticate does that now.. though I couldn't figure out why I made it so complicated
15:46:11 <donri> STM isn't persistent though
15:46:14 <stepkut> so I went with the less complicated but similar solution
15:46:30 <stepkut> right, with STM the sessions would expire when you restart the server and you would not have replication
15:46:58 <stepkut> but you avoid creating lots of boring events in your acid-state logs
15:47:24 <stepkut> my thought is that session expiration could be a separate db from the session data itself, so you can pick STM or acid-state
15:47:25 <donri> which isn't that bad because long-living sessions have security problems too, but at the same time you might not want to log everyone out every server restart
15:47:43 <donri> aha
15:47:55 <stepkut> what is missing from happstack-authenticate at the moment is the 'remember me' checkbox support, which requires another cookie
15:48:03 <donri> or we just support acid-state but optionally you can use the memory backend
15:48:17 <donri> that way we get a single interface, the AcidState handle
15:48:43 <stepkut> oh right!
15:48:52 <stepkut> I thought of that and then forgot
15:48:56 <donri> :)
15:49:05 <stepkut> that gives you the option for replication/remote without the disk log
15:49:13 <donri> ah cool
15:49:50 <donri> that also means you could run a separate process for an in-memory session with an acidServer and restart the web server without losing sessions
15:50:14 <donri> although then the writes have to be sent over a socket, duno what the overhead is there
15:50:34 <donri> and the reads
16:04:57 <stepkut> yeah
16:05:22 <stepkut> pretty low probably, but not nearly as low as between haskell threads :)
16:36:53 <donri> + cereal overhead
16:37:12 <donri> not sure local queries are serialized at all