Available formats: content-negotiated html turtle (see SIOC for the vocabulary)
Back to channel and daily index: content-negotiated html turtle
These logs are provided as an experiment in indexing discussions using IRCHub.py, Irc2RDF.hs, and SIOC.
| 17:09:51 | <jmcarthur> | it stays awfully quiet in here lately |
| 17:10:34 | <sm> | indeed.. thomas and matt are busy |
| 17:11:07 | <sm> | as is everyone else, I guess |
| 17:11:27 | <jmcarthur> | :o somebody is paying attention to #happs! |
| 17:12:19 | <jmcarthur> | i'm working on mightybyte's happstack-auth package. liberally polishing and redesigning as i see fit without regard to whether mightybyte would approve ;) |
| 17:32:29 | <sm> | polish is good |
| 17:32:55 | <sm> | happstack is not so much a web framework as a web framework construction set, right now |
| 17:40:17 | <jmcarthur> | i'm personally fine with that |
| 17:40:44 | <jmcarthur> | frameworks are just a kind of design lock-in |
| 18:37:06 | <mightybyte> | jmcarthur: Glad to here that someone is using happstack-auth. I'd say it's quite likely that I'll approve of whatever changes you're making. |
| 18:37:28 | <mightybyte> | jmcarthur: If you want to discuss anything, let me know. |
| 19:02:13 | <jmcarthur> | mightybyte: sweet, thanks |
| 19:05:29 | <jmcarthur> | mightybyte: i'm making stylistic changes which you would probably see as unnecessary, switching the storage types for username and hashes to bytestrings, thinking about making a reader for withSession and company, and removing the (arbitrary?) sanitation of the username... among many other major changes |
| 19:20:20 | <mightybyte> | jmcarthur: Sounds good. I think we should keep some username sanitation by default to prevent attacks, since this is a user-specified field that will likely be displayed to other users in pages. |
| 19:26:30 | <jmcarthur> | mightybyte: my opinion on sanitation is that it should be done as it is output |
| 19:26:50 | <jmcarthur> | mightybyte: it means that the sanitation algorithm can be changed and everything automatically benefits |
| 19:29:47 | <jmcarthur> | and anyway, i like to allow people to register with things like email addresses and stuff as their usernames if they choose |
| 19:32:41 | <jmcarthur> | basically i just mean i think the sanitation for HTML should be the responsibility of the rendering code, as that is the most domain specific area for that form of sanitation. just like one usually sanitizes text for SQL queries right as he generates the query itself |
| 19:37:59 | <mightybyte> | Yeah, the email address case is reasonable. |
| 19:39:37 | <mightybyte> | And I understand what you're saying about sanitizing on output. I was coming at it from the idea that it would be nice for a bolt-on auth library to preclude some of these attacks on its own. |
| 19:39:59 | <jmcarthur> | how about a compromise on taking a function as a parameter that performs sanitation if the developer chooses, and also include a version that performs no sanitation? |
| 19:40:43 | <mightybyte> | That sounds good. |
| 19:40:56 | <jmcarthur> | that is, one version that accepts a (Username -> Bool) function and another that performs so sanitation |
| 19:41:00 | <jmcarthur> | okay cool, i'll do that |
| 19:41:10 | <mightybyte> | Excellent. Did you clone my repo on github? |
| 19:41:11 | <jmcarthur> | s/so/no/ |
| 19:41:14 | <jmcarthur> | yes |
| 19:41:22 | <jmcarthur> | none of my changes are up yet though |
| 19:41:34 | <mightybyte> | Great, then it will be simple to merge them in. |
| 19:41:42 | <jmcarthur> | hopefully |
| 19:41:53 | <jmcarthur> | unless my stylistic changes conflict with something you have done yourself |
| 19:42:08 | <mightybyte> | The other day I was wondering if the library should do any sort of IP address checking. |
| 19:42:17 | <jmcarthur> | i was thinking about that too |
| 19:42:20 | <jmcarthur> | also user agent and stuff |
| 19:42:25 | <jmcarthur> | make sure nobody s scraping cookies |
| 19:42:32 | <jmcarthur> | maybe an optional thing though |
| 19:42:37 | <jmcarthur> | i don't want to make it too limiting |
| 19:42:52 | <mightybyte> | Yeah, there are certainly situations where I don't think you'd want it. |
| 19:43:21 | <jmcarthur> | i have a branch for that, but i'm deprioritizing it right now |
| 19:43:28 | <mightybyte> | Ok |
| 19:46:29 | <mightybyte> | Any idea when you'll commit the bytestring changes? |
| 19:46:46 | <jmcarthur> | later today, probably |
| 19:47:08 | <jmcarthur> | i just realized something bad |
| 19:47:25 | <jmcarthur> | the AuthUser function.... takes a password as an argument |
| 19:47:49 | <jmcarthur> | which appears to serialize the password... |
| 19:48:17 | <jmcarthur> | i think that shouldn't be a State primitive |
| 19:48:23 | <mightybyte> | Ooooh, that's right. |
| 19:48:34 | <jmcarthur> | i found that by making a Password type :) |
| 19:49:02 | <jmcarthur> | i'll get that too, if i can find an elegant redesign for it |
| 19:49:27 | <mightybyte> | Well, just make the state functions operate on hashed passwords. |
| 19:49:35 | <jmcarthur> | yeah, that's what i'm thinking |
| 19:49:38 | <mightybyte> | Then don't expose those functions to the user. |
| 19:49:47 | <jmcarthur> | yup |
| 19:49:48 | <mightybyte> | Wrap them with other functions that do the hashing. |
| 19:50:01 | <jmcarthur> | AuthUser is the only one like that, the others all typecheck still |
| 19:50:12 | <koeien> | i quickly skimmed the code, liked the idea :) |
| 19:50:22 | <koeien> | in fact i implemented something like that before but uglier |
| 19:50:34 | <mightybyte> | Hmmm, if you're making a Password type, it would be good to make some other changes in the process. |
| 19:50:44 | <jmcarthur> | i'm making quite a few |
| 19:50:47 | <jmcarthur> | very intrusive changes |
| 19:51:09 | <jmcarthur> | also things like making Password and instance of FromData and stuff |
| 19:51:16 | <jmcarthur> | very convenient |
| 19:51:54 | <mightybyte> | Have you read this thread? |
| 19:51:56 | <mightybyte> | http://groups.google.com/group/HAppS/browse_thread/thread/aaf65745e3ee5eda/d1a71f41523e12b4?lnk=gst&q=auth#d1a71f41523e12b4 |
| 19:53:39 | <jmcarthur> | oh that's a good idea |
| 19:54:08 | <jmcarthur> | right now there is a SaltedHash type, but we could make a variety of them for different algorithms |
| 19:54:19 | <jmcarthur> | or just give it different constructors, if we want |
| 19:54:26 | <koeien> | would that really be necessary? |
| 19:54:37 | <jmcarthur> | koeien: for migrations and stuff, yes |
| 19:54:39 | <koeien> | i like a sensible default choice |
| 19:54:49 | <koeien> | well it will change in the future |
| 19:55:04 | <koeien> | (such as SHA-512 now) |
| 19:55:04 | <jmcarthur> | yeah a sensible default is definitely good |
| 19:55:21 | <koeien> | and 512 iterations iirc |
| 19:55:48 | <jmcarthur> | you're right though, if SHA-512 * 512 is good at the moment, we probably don't need the extra infrustructure yet |
| 19:56:02 | <koeien> | SHA-3 will be around some time in the future |
| 19:56:15 | <jmcarthur> | only once we want a new algorithm, and then a typical State migration will still work fine |
| 19:56:19 | <mightybyte> | Yes, but Daniel's point was that the details of the algorithm and the number of repetitions should be encoded in the hashed password. |
| 19:56:51 | <koeien> | like (SHA512, 512, "...." |
| 19:57:10 | <jmcarthur> | mightybyte: we know right now that they are all 512 repetitions of sha-512. later down the line when we do this we can just have the migration put that encoding in for the existing passwords |
| 19:57:10 | <mightybyte> | How can a typical state migration do it? You can't convert one hash into another. |
| 19:57:34 | <mightybyte> | I think we have to have special support for password migration. |
| 19:57:51 | <jmcarthur> | the point is we don't migrate the hashed passwords, really |
| 19:57:54 | <mightybyte> | Passwords can only be migrated when a user logs in and gives us the cleartext. |
| 19:57:57 | <koeien> | but then you need to know which scheme is used per password |
| 19:58:11 | <jmcarthur> | when we have multiple hashing algorithms / iterations, _then_ we can encode that stuff with the hashes |
| 19:58:29 | <mightybyte> | Yeah, that makes sense. |
| 19:58:54 | <koeien> | i doubt it will be necessary some time soon |
| 19:59:14 | <jmcarthur> | would be nice to allow developers to choose number of iterations and stuff, maybe |
| 19:59:23 | <mightybyte> | Well...I already have a site in alpha with users under the current happstack-auth. |
| 19:59:40 | <koeien> | but the password will be submitted in plaintext ? |
| 19:59:43 | <jmcarthur> | mightybyte: snap, that means i have to write migration code for the bytestring version :P |
| 19:59:57 | <koeien> | isn't it better to let the user send the password hashed? |
| 20:00:00 | <mightybyte> | Yeah, although that migration should be normal. |
| 20:00:11 | <koeien> | to prevent eavesdropping. |
| 20:00:22 | <mightybyte> | Doesn't do any good. |
| 20:00:23 | <koeien> | (although for sensitive stuff you should use SSL anyway) |
| 20:00:27 | <jmcarthur> | koeien: yes, but there is not a good way to do that yet, without the use of encryption anyway |
| 20:00:33 | <mightybyte> | Eve will still be able to send the same hash to the site. |
| 20:00:48 | <jmcarthur> | koeien: to send the javascript or whatever, you would have to use SSL anyway |
| 20:01:00 | <koeien> | jmcarthur: i am talking about passive eavesdropping attacks |
| 20:01:11 | <koeien> | mightybyte: or some challenge-response |
| 20:01:16 | <koeien> | maybe overkill |
| 20:01:19 | <jmcarthur> | mightybyte: not if the server requests a certain salt with it |
| 20:01:25 | <mightybyte> | koeien: Yes, but that's what SSL is for. |
| 20:01:34 | <jmcarthur> | but that would require the server to know the password |
| 20:01:36 | <jmcarthur> | which we don't want |
| 20:01:40 | <koeien> | jmcarthur: no |
| 20:01:41 | <mightybyte> | jmcarthur: Right |
| 20:02:00 | <koeien> | H( session_salt ++ H( salt ++ password) ) |
| 20:02:35 | <mightybyte> | But then we're requiring javascript support. |
| 20:02:41 | <koeien> | yes, that's not-so-nice |
| 20:02:50 | <jmcarthur> | and the javascript still must be sent SSL |
| 20:02:55 | <jmcarthur> | oh, passive |
| 20:02:56 | <jmcarthur> | nevermind |
| 20:03:09 | <koeien> | not so sure whether that is necessary/worth it/useful |
| 20:03:17 | <jmcarthur> | i don't think it is worth it, personally |
| 20:03:20 | <koeien> | you should use SSL anyway |
| 20:03:22 | <jmcarthur> | for all that, might as well go with SSL |
| 20:03:26 | <koeien> | if you want this kind of security |
| 20:03:38 | <koeien> | then you also prevent active attacks |
| 20:03:53 | <jmcarthur> | on another note, i would love to have OpenID support eventually as well |
| 20:04:04 | <jmcarthur> | but that is a whole other beast |
| 20:04:07 | <mightybyte> | Yeah |
| 20:04:27 | <mightybyte> | jmcarthur: Hmmm, I just tested a user creation and the password isn't stored anywhere in the state. |
| 20:04:54 | <jmcarthur> | mightybyte: if you have a state-changing function that relies on AuthUser, you will have it saved |
| 20:05:02 | <jmcarthur> | just a query by itself is safe |
| 20:05:22 | <mightybyte> | Hmmm, will we ever need that? |
| 20:05:52 | <jmcarthur> | developer might decide not to make a session, just do a one-shot authentication for something |
| 20:05:59 | <jmcarthur> | in that case, yes |
| 20:06:53 | <jmcarthur> | say i wanted to make a blog post without logging in. could just have a username and password field on the post form or something |
| 20:07:09 | <jmcarthur> | and use AuthUser to check it |
| 20:08:00 | <mightybyte> | But would that need to be serialized and stored? |
| 20:09:14 | <jmcarthur> | well, i guess not if the developer does the AuthUser in a query and then does the posting in an update |
| 20:09:16 | <mightybyte> | I guess it depends on how the user implements it. |
| 20:09:20 | <jmcarthur> | but that isn't transactional |
| 20:09:32 | <mightybyte> | Yeah |
| 20:09:56 | <jmcarthur> | it would be the weirdest race condition i ever heard of, deleting a user or changing his password as he makes a post |
| 20:10:55 | <mightybyte> | Heh |
| 20:10:57 | <jmcarthur> | regardless, i think it would be wise to try to not have Passwords involved in transactions |
| 20:11:09 | <mightybyte> | Yes, I agree. |
| 20:13:33 | <jmcarthur> | there are two ways to do this... 1) retrieve the salt as a query, hash the password with a pure function, compare the hash as a query... 2) retrieve the salted hash as a query, hash and compare with a pure function |
| 20:13:52 | <jmcarthur> | i'm not sure which to go with |
| 20:14:25 | <mightybyte> | #2 seems better to me. |
| 20:14:29 | <jmcarthur> | i'm thinking number 2 right now |
| 20:14:30 | <jmcarthur> | yeah |
| 20:14:37 | <mightybyte> | Fewer queries. |
| 20:14:47 | <jmcarthur> | alright, i'll do that |
| 20:31:48 | <jmcarthur> | simplest solution, new type for authUser :: MonadIO m => Username -> Password -> m (Maybe User) |
| 20:31:54 | <jmcarthur> | and no more AuthUser |
| 20:32:07 | <mightybyte> | Yeah |
| 20:32:12 | <jmcarthur> | can't be used transactionally, but that seems to be no problem at the moment |
| 20:32:22 | <gcollins> | hey guys -- I'm going to chime in to say that "if it sends passwords in cleartext, I won't be using it" |
| 20:32:49 | <mightybyte> | Well, the auth library has nothing to do with how the passwords are sent. |
| 20:33:48 | <jmcarthur> | gcollins: yeah, an SSL layer or something would be another components if you want that |
| 20:34:01 | <gcollins> | I use happstack for app-server-ish stuff at work, we're doing challenge-response there. Right now we don't have SSL support except through a proxy, correct? |
| 20:34:22 | <mightybyte> | As far as I know that's correct. |
| 20:35:02 | <gcollins> | I've never actually checked out that auth library |
| 20:35:30 | <mightybyte> | The main purpose of the auth library is to provide user/password storage in happstack state. |
| 20:35:42 | <mightybyte> | ...along with session management. |
| 20:36:09 | <gcollins> | I see. I don't use happstack-state at all (although session management would be a good use case) |
| 20:37:06 | <gcollins> | I had to roll a custom auth module for my last project |
| 20:37:16 | <mightybyte> | Yeah, that's why I built this one. |
| 20:37:30 | <gcollins> | we're a mobile company and several of the cell providers mangle the HTTP headers (ugh) |
| 20:37:36 | <gcollins> | so we had to do auth using POST data |
| 20:37:58 | <gcollins> | I just keep my session state behind an MVar |
| 20:38:20 | <gcollins> | If you're interested in taking a look I can chuck it into hpaste |
| 20:38:41 | <mightybyte> | Sure. |
| 20:40:22 | <gcollins> | http://hpaste.org/fastcgi/hpaste.fcgi/view?id=5231#a5231 |
| 20:40:47 | <gcollins> | kind of a cheat 'cause this app doesn't have any session state beyond "have you authenticated?" |
| 20:41:37 | <gcollins> | ..and here's the auth code |
| 20:41:38 | <gcollins> | http://hpaste.org/fastcgi/hpaste.fcgi/view?id=5232#a5232 |
| 20:42:04 | <jmcarthur> | gcollins: any reason you are rolling your own Map? |
| 20:42:21 | <gcollins> | yes |
| 20:42:34 | <jmcarthur> | oh, it's a pair of sets |
| 20:42:36 | <gcollins> | right |
| 20:42:38 | <jmcarthur> | i didn't notice that the first time |
| 20:42:45 | <gcollins> | sorry I was just going to explain that :) |
| 20:42:53 | <gcollins> | This is for an analytics server |
| 20:42:59 | <jmcarthur> | ah! |
| 20:43:15 | <jmcarthur> | a two-way map? |
| 20:43:15 | <gcollins> | it accepts event packets and aggregates some useful statistics |
| 20:43:45 | <mightybyte> | Any reason you don't use Happstack's state? |
| 20:43:47 | <gcollins> | jmcarthur: similar -- we need to look up values in the session table by challengekey and also by timestamp |
| 20:43:59 | <gcollins> | mightybyte: I don't trust it |
| 20:44:16 | <mightybyte> | Heh |
| 20:44:50 | <gcollins> | I mean, it seems good in theory but I'm not sure I'd use it for "real data" -- but I think we've had this conversation |
| 20:45:06 | <gcollins> | Mostly I'm unsure of how well it would deal with very large data sets |
| 20:47:04 | <mightybyte> | We certainly need to get sharding implemented before we can really claim to handle large data sets. |
| 20:47:56 | <gcollins> | The biggest reason I don't use it, to be honest, is that I don't really understand how it works |
| 20:49:00 | <gcollins> | I.e. I've scanned some design documents but haven't invested any time in grokking the code |
| 20:51:35 | <jmcarthur> | yeah i can't wait for sharding. that's the big hurdle, in my opinion |
| 20:52:14 | <gcollins> | Lately I'm really into tokyo tyrant |
| 20:52:19 | <mightybyte> | happstack-ixset is also a nice solution for multiple key lookups |
| 20:52:25 | <gcollins> | that's what I'm using for state now |
| 20:52:38 | <gcollins> | mightybyte: maybe I should refactor it then |
| 20:53:16 | <gcollins> | because if I need to add any per-session state to that I'd have to rip it apart |
| 20:53:18 | <jmcarthur> | isn't IxSet specific to State, though? |
| 20:53:38 | <jmcarthur> | or maybe i'm way off |
| 20:53:48 | <mightybyte> | jmcarthur: No, it's just a generic indexed sit. |
| 20:53:48 | <jmcarthur> | not much experience with it yet |
| 20:53:52 | <mightybyte> | s/sit/set/ |
| 20:53:52 | <jmcarthur> | oh, nice |
| 20:54:08 | <gcollins> | the interface looks a little wacky to me |
| 20:54:23 | <mightybyte> | ...with the necessary instances for happstack-state |
| 20:56:34 | <jmcarthur> | mightybyte: i have the bytestring version building now. not tested whatsoever yet. need to add the optional sanitation. also have no migrations yet |
| 20:57:05 | <jmcarthur> | i'll go ahead and push to github, but i don't recommend a pull yet |
| 20:58:03 | <mightybyte> | Ok |
| 20:58:05 | <jmcarthur> | mightybyte: pushed |
| 20:58:16 | <gcollins> | what does IxSet use the Typeable dependency for? |
| 20:58:40 | <mightybyte> | For Happstack state I think. |
| 20:59:41 | <gcollins> | ok -- I tried to use Typeable/Dynamic in my last project and ran into huge performance problems |
| 21:00:02 | <gcollins> | although I'm willing to bet that was just about "you're doing it wrong' |
| 21:00:27 | <mightybyte> | I'm not familiar with how state is implemented. |
Back to channel and daily index: content-negotiated html turtle