gistfile1.txt

Session Start: Fri May 07 09:07:16 2010
Session Ident: #padrino
03[09:07] * Now talking in #padrino
03[09:07] * Topic is '0.9.10 Released! http://bit.ly/blbRXF | Padrino : http://bit.ly/a7cJg8 | GitHub: http://bit.ly/daUL8z | Google Groups: http://bit.ly/c80Bim'
03[09:07] * Set by [email protected] on Fri Apr 23 04:23:14
03[09:07] * danishkhan ([email protected]) has joined #padrino
02[09:10] * neaf ([email protected]) Quit (Quit: neaf)
03[09:10] * zenom__ (~aj1973@unaffiliated/aj1973) has joined #padrino
02[09:11] * zenom_ (~aj1973@unaffiliated/aj1973) Quit (Ping timeout: 252 seconds)
03[09:11] * onethirtyfive ([email protected]) has joined #padrino
[09:11] <onethirtyfive> nesquena: Hey nes, you there?
[09:11] <@nesquena> onethirtyfive: hey man
[09:11] <onethirtyfive> nesquena: Hi!
[09:12] <onethirtyfive> nesquena: I have 3 hours to spare, and I was wanting to get started on rack-identity... but I don't know where to start. Do you have a minute to hash out some of the details with me?
[09:13] <onethirtyfive> nesquena: It can wait until this weekend if need be.
[09:13] <@nesquena> onethirtyfive: i recently saw a rack middleware attempt at authorization
[09:13] <@nesquena> onethirtyfive: http://github.com/stonean/monty
[09:13] <@nesquena> onethirtyfive: its not as good as our conception but i thot it was interesting
[09:14] <@nesquena> onethirtyfive: i have a bit of time to spare. what would you like to discuss
[09:14] <onethirtyfive> nesquena: That seems ok, but it's authorization and its granularity is limited to actions on resources.
[09:15] <onethirtyfive> nesquena: I think ours is more worth implementing even if from scratch.
[09:15] <onethirtyfive> nesquena: *its. It's alright. I like the DSL feel.
[09:15] <@nesquena> onethirtyfive: yea its a good start tho having it as a nice rack library
[09:15] <onethirtyfive> nesquena: Hm...
[09:16] <onethirtyfive> nesquena: For authorization, I think it's going to require a bit more domain-specific context.
03[09:16] * neaf ([email protected]) has joined #padrino
[09:16] <onethirtyfive> nesquena: And since this is effectively a different rack app--the way it's implemented--it's separate from any domain specific details. Aside from, say, what it can pull out of the session (or any other shared global state)
[09:16] <onethirtyfive> nesquena: Authentication, however, is a different problem. And it's got me hung up.
02[09:17] * neaf ([email protected]) Quit (Client Quit)
[09:17] <@nesquena> onethirtyfive: yes i think a good authentication library is not trivial to build
[09:17] <@nesquena> onethirtyfive: what are you hung up on
[09:18] <onethirtyfive> nesquena: Do you know of any rack apps that persists data independently of the app that it's serving?
[09:18] <onethirtyfive> mmm... beer.
[09:18] <@nesquena> onethirtyfive: where would it be persisted? like persists things into a database?
[09:19] <@nesquena> onethirtyfive: usually the rack middlewares tend not to require any particular persistence engines that i know of
[09:19] <onethirtyfive> nesquena: So effectively, I'm writing a piece of middleware that persists identities and credentials independent of the app it's serving.
[09:19] <@nesquena> onethirtyfive: right i gotcha, where would you want to persist the identities. what type of store?
[09:19] <@nesquena> onethirtyfive: would it be adapter based so anybody could write their own or just use redis or mongodb or what
[09:20] <onethirtyfive> nesquena: Well, the obvious solution for a first iteration is like sqlite or something.
[09:20] <@nesquena> onethirtyfive: ok fair enough
[09:20] <@nesquena> onethirtyfive: this seems reasonable to have a rack middleware use sqlite to store data. i dont know of any example offhand that do that but i dont see why not
[09:21] <@nesquena> onethirtyfive: perhaps eventually it could be relatively agnostic
[09:21] <@nesquena> onethirtyfive: similar to padrino admin
[09:21] <onethirtyfive> nesquena: The whole point is to separate the data store completely... otherwise, we'd just provide generators. It's kinda a thought experiment: can a piece of middleware identity (i.e. authenticate) users in a way that's extensible enough to work it in with any app?
[09:21] <onethirtyfive> nesquena: *identify
[09:21] <@nesquena> onethirtyfive: right well i mean we need to identify what type of data the middleware needs to store
[09:22] <onethirtyfive> nesquena: The only thing in common for all forms of identity is an identifier.
[09:22] <onethirtyfive> nesquena: for email identities, it'd be an email. for openid, their url.
[09:22] <@nesquena> onethirtyfive: right so in the db, what would we store just the identifier and then the identifier 'type' along with ?
[09:22] <onethirtyfive> nesquena: The task of associating an identity with an account is up to the app.
[09:22] <onethirtyfive> nesquena: the strategy here depends on what ORM we use.
[09:22] <@nesquena> onethirtyfive: i see so the app would hook the identity up to the account on the app side
[09:23] <onethirtyfive> nesquena: Yeah, because then the app could maintain a relationship between a user and multiple identities in a domain-specific way.
[09:23] <onethirtyfive> nesquena: And the thing it would use would simply be the identifier... or maybe a GUID or something.
[09:23] <@nesquena> onethirtyfive: alright that makes sense. but how do you setup that association in a way that works for every orm
[09:23] <@nesquena> i guess the identity could have n id
[09:23] <@nesquena> an id*
[09:23] <onethirtyfive> nesquena: I'm not sure you do is the thing.
[09:23] <onethirtyfive> nesquena: Essentially the relationship is polymorphic.
[09:24] <onethirtyfive> nesquena: An identity has an associated record with details specific to that kind of id.
[09:24] <onethirtyfive> nesquena: AR and DM handle these things differently.
[09:24] <onethirtyfive> nesquena: The way DM simulates STI is much better imno.
[09:24] <onethirtyfive> nesquena: imo
[09:25] <@nesquena> onethirtyfive: right so would this rack-identity manage logging in like checking password/identifier comboes
[09:25] <@nesquena> onethirtyfive: it seems like it would be hard for it to do this?
[09:25] <onethirtyfive> nesquena: I'm wondering if it's too ballsy to be like 'to use rack-identity you must have DataMapper'
[09:25] <onethirtyfive> nesquena: Maybe the adapter would be better... but the whole point is to keep this as self-contained as possible.
[09:25] <onethirtyfive> nesquena: Not at all. but that's kinda detailed.
[09:25] <onethirtyfive> nesquena: Happy to give you my thoughts if you want.
[09:25] <@nesquena> onethirtyfive: i dont like rack-identity being tied to a particular orm
[09:25] <@nesquena> onethirtyfive: esp if this is to become connected to padrino
[09:26] <@nesquena> onethirtyfive: but i guess for it to start off just to get the ball rolling
[09:26] <@nesquena> onethirtyfive: and get the concept working
[09:26] <@nesquena> onethirtyfive: i guess what im getting at is what are the points of interaction with rack-identity
[09:26] <@nesquena> onethirtyfive: so you need to link your domain specific accounts to the 'identity' clearly but what other interactions would it provide
[09:27] <@nesquena> onethirtyfive: some way to authenticate users given a supplied login credentials, a way to logout, a way to get the current user ?
[09:27] <onethirtyfive> nesquena: :) I will take the liberty of explaining.
[09:27] <onethirtyfive> nesquena: Am I still in the channel? getting some weird network stuff.
02[09:27] * onethirtyfive ([email protected]) Quit (Quit: onethirtyfive)
[09:29] <nwmcsween> can i use the authentication helpers without having it tied to anything?
[09:29] <nwmcsween> i.e create my own administration panel
[09:30] <nwmcsween> or are the helpers implicitly tangled with the admin app?
[09:31] <@nesquena> the authentication helpers come from the Admin system and are based on use of the generated Account model
[09:32] <nwmcsween> ok so it is hmmm
[09:32] <@nesquena> nwmcsween: you dont have to actually use the admin panel (just remove / unmount it) but the account model would need to be used
[09:32] <@nesquena> nwmcsween: of course nothing at all forces you into using that
[09:32] <@nesquena> nwmcsween: you can just as easily use warden
[09:32] <@nesquena> nwmcsween: or any other sinatra / rack authentication mechanism
03[09:34] * onethirtyfive ([email protected]) has joined #padrino
[09:34] <onethirtyfive> nesquena: Sorry, network flakiness.
[09:34] <@nesquena> onethirtyfive: np
[09:34] <onethirtyfive> nesquena: What's the last thing you saw from me?
[09:35] <@nesquena> Am I still in the channel? getting some weird network stuff.
[09:35] <onethirtyfive> nesquena: You are.
[09:35] <@nesquena> is the last thing
[09:35] <@nesquena> i saw from you
[09:35] <onethirtyfive> nesquena: haha ok.
[09:35] <@nesquena> onethirtyfive: funny because before i could answer you had left the char
[09:35] <@nesquena> chat*
[09:35] <@nesquena> onethirtyfive: so go ahead and elaborate
[09:35] <onethirtyfive> nesquena: Strange.
[09:36] <onethirtyfive> nesquena: So the thing that really actually messes this all up is ::drum roll:: form-based account creation.
[09:36] <onethirtyfive> nesquena: and authentication.
[09:37] <@nesquena> onethirtyfive: why does this mess it all up?
[09:37] <onethirtyfive> nesquena: What this approach does (for both user account and login) is interject an 'identify yourself' stage into the works.
[09:37] <onethirtyfive> nesquena: before registration, and before accessing a protected webpage.
[09:38] <onethirtyfive> nesquena: Form-based authentication means dedicating a part of your domain to session creation.
[09:38] <onethirtyfive> nesquena: because you have to expose forms.
[09:38] <onethirtyfive> nesquena: This isn't intrinsically part of HTTP, but it's a real-world "we have to do this" kind of thing.
[09:38] <onethirtyfive> nesquena: So the middleware will need to expose an endpoint that accepts POST data for creation of sessions.
[09:38] <onethirtyfive> nesquena: i.e. letting people identify themselves
[09:39] <@nesquena> onethirtyfive: right
[09:39] <onethirtyfive> nesquena: The long and short of it is...
[09:40] <onethirtyfive> nesquena: I have a clear picture of it in my head, but communicating this picture is laborious.
[09:40] <@nesquena> onethirtyfive: yes i know how that can be
[09:41] <onethirtyfive> nesquena: the middleware has to respond to exactly one route to handle form data postbacks for logins. If authentication is done via HTTP headers, then this endpoint won't even be touched.
[09:41] <onethirtyfive> nesquena: rack-openid (upstream from our layer) can handle openid authentication. :)
[09:41] <@nesquena> onethirtyfive: thats nice
[09:42] <onethirtyfive> nesquena: Yep. by the time the openid provider redirects there and back, the verified id will be in RACK_ENV.
[09:42] <@nesquena> onethirtyfive: and yes i see what you are saying exposing a url to post to so that it can handle the form data
[09:42] <@nesquena> onethirtyfive: right thats true for openid at least
[09:42] <onethirtyfive> nesquena: Form authentication is a hack and I hate it, but we have to handle it.
[09:42] <onethirtyfive> yes, for openid.
[09:42] <onethirtyfive> nesquena: So, this all boils down to a few things:
[09:42] <@nesquena> onethirtyfive: yea i mean basic form authentication is the bread and butter of login processes for most apps
[09:43] <onethirtyfive> nesquena: Shame, but true.
[09:43] <@nesquena> onethirtyfive: theres also facebook authentication, google authentication, etc
[09:43] <@nesquena> onethirtyfive: which are easier to handle on some level
[09:43] <onethirtyfive> nesquena: Yeah, but we can accommodate that, I think.
[09:43] <onethirtyfive> nesquena: And the identities will be stored independent of the app. no more reinventing the authentication wheel everytime.
[09:43] <onethirtyfive> nesquena: It's ballsy, but I think it can be done.
[09:44] <onethirtyfive> nesquena: 401 responses (html reps of them anyhow) can include a form that posts back to the middleware-exposed route.
[09:44] <onethirtyfive> nesquena: Embed some context and implement some request forwarding and you have a full-fledged authentication layer.
[09:45] <@nesquena> onethirtyfive: sometimes it helps to just 'write the readme' as if the app existed showing the usage of it from the users perspective. or alternatively just start hacking on it
[09:45] <onethirtyfive> nesquena: The README thing is great.
[09:45] <onethirtyfive> nesquena: I've never tried that.
[09:45] <@nesquena> onethirtyfive: yea i do that all the time
[09:45] <@nesquena> onethirtyfive: before i write a library i purposely force myself to document it first in that way
[09:45] <@nesquena> onethirtyfive: heres installation, configuration, setup and usage
[09:46] <onethirtyfive> nesquena: I like that.
[09:46] <@nesquena> onethirtyfive: it really helps the idea solidify in my life
[09:46] <@nesquena> in my mind rather hhaa
[09:46] <onethirtyfive> nesquena: It's all spaghetti in my head.
[09:46] <@nesquena> onethirtyfive: yea also its useful to work out the public api
[09:46] <@nesquena> onethirtyfive: just in general and then follow that up with test driven development based on the 'readme' spec
[09:47] <onethirtyfive> nesquena: or I could write stories. :)
[09:47] <@nesquena> onethirtyfive: yes that too
[09:47] <onethirtyfive> nesquena: ahem, features
[09:47] <@nesquena> onethirtyfive: but i mean development is iterative. you dont necessarily need a full picture of all moving parts before you get started writing readme/features/specs/code
[09:47] <onethirtyfive> nesquena: and that's how I need to be a better coder.
[09:47] <onethirtyfive> nesquena: specifically. :)
[09:48] <onethirtyfive> I'll go write the readme now.
[09:48] <@nesquena> onethirtyfive: we all need to strive to be better coders no question. its a lifelong process
[09:48] <@nesquena> onethirtyfive: great that always helped me tremendously but everyone is different
[09:48] <@nesquena> onethirtyfive: personally i dont mind writing 'practical' documentation in fact i enjoy it
[09:48] <@nesquena> onethirtyfive: theres nothing i hate more than a great library with piss poor usage examples
[09:49] <onethirtyfive> nesquena: Yeah.
[09:50] <@nesquena> onethirtyfive: theres no shame in having a github repo with just a readme and some experimental 'features' specs
[09:50] <onethirtyfive> nesquena: I already made a rack-identity repo. :)
[09:50] <@nesquena> onethirtyfive: ah thats a good start :P
[09:50] <onethirtyfive> nesquena: I just didn't want to populate it with an abortion of stuff...
[09:50] <onethirtyfive> nesquena: I mean on github
[09:50] <@nesquena> onethirtyfive: haha fair enough
[09:51] <onethirtyfive> nesquena: Seriously, though... is identifying a user predictable enough to isolate it from an app?
[09:51] <onethirtyfive> nesquena: Um... yes.
[09:51] <@nesquena> onethirtyfive: seems like the answer is definately yes
[09:51] <onethirtyfive> nesquena: Is the authorization on their operations within the domain isolatable? Definitely not.
[09:52] <@nesquena> onethirtyfive: right
[09:52] <onethirtyfive> nesquena: Thanks for helpin' me sort things out. When it comes to integrating custom markup into the identity creation forms, etc...
[09:52] <onethirtyfive> nesquena: I'll need your ideas again.
[09:52] <onethirtyfive> nesquena: for one-step registration on a site.
[09:52] <@nesquena> onethirtyfive: of course man. this sounds like an interesting project so far :)
[09:52] <onethirtyfive> nesquena: as opposed to "identify yourself" followed by "create your account"
[09:53] <@nesquena> onethirtyfive: well it can all be part of one action or route
[09:53] <onethirtyfive> nesquena: Even though I'd kinda like to introduce the concept of having to identify yourself before you do anything on a domain. it'd be nice to train users to that new paradigm.
[09:53] <@nesquena> part of the creation process will be interacting with the rack-identity interface it seems to me
[09:53] <@nesquena> so you can create your domain specific account and register / retrieve an identity
[09:53] <@nesquena> in a single action
[09:53] <onethirtyfive> nesquena: reading
[09:54] <onethirtyfive> nesquena: don't want to talk over you w/o understanding what you're saying.
[09:54] <@nesquena> well what I am saying is lets say theres a registration form
[09:54] <@nesquena> i would say that after they hit register
[09:54] <@nesquena> its probably going to have to postback on some level to the app itself right
[09:54] <@nesquena> because theres domain specific things to do
[09:54] <onethirtyfive> nesquena: absolutely if there's data that needs to be stored to a domain-specific resource.
[09:55] <@nesquena> so what i am saying is that in the 'route' that is posted to by the register
[09:55] <@nesquena> i would imagine there would be app specific code
[09:55] <@nesquena> and then also code to 'link' up the app specific user with the identity
[09:55] <onethirtyfive> nesquena: Humor me... I don't think so. :D
[09:56] <onethirtyfive> nesquena: Let's expand the domain of our middleware with one more route: register.
[09:56] <onethirtyfive> nesquena: takes POST.
[09:56] <onethirtyfive> nesquena: It can kinda function as a pass-through: creates an identity which needs to be verified (potentially) and passes through to the application server whatever information is 'context'
[09:56] <onethirtyfive> nesquena: or is that what you're saying?
[09:57] <@nesquena> onethirtyfive: yea i guess its more or less we are on the same page
[09:57] <onethirtyfive> nesquena: cool
[09:57] <onethirtyfive> nesquena: Though it'd be kinda nifty if you went to a site and it said "before we get started, we need to know who you are."
[09:57] <@nesquena> onethirtyfive: yea i could see that
[09:57] <onethirtyfive> nesquena: "you can identify yourself via openid, facebook, or with an email address.
[09:57] <onethirtyfive> nesquena: After you have, we'll create your account.
[09:58] <onethirtyfive> nesquena: details, details.
[09:58] <@nesquena> onethirtyfive: somewhat up to the app developer also
[09:58] <onethirtyfive> nesquena: it needs to be.
[09:58] <onethirtyfive> nesquena: one-step or walled garden.
[09:58] <@nesquena> onethirtyfive: clearly we need a sample app eventually too
[09:58] <onethirtyfive> nesquena: Yeah.
[09:58] <@nesquena> onethirtyfive: to demonstrate what rack-identity can do
[09:58] <onethirtyfive> nesquena: I need to write that. :D
[09:58] <@nesquena> onethirtyfive: perhaps a padrino app to demonstrate :)
[09:59] <@nesquena> onethirtyfive: altho rack-identity should clearly be able to be used with sinatra, padrino, rails, merb, etc
[09:59] <@nesquena> onethirtyfive: there can even be wrappers on top like for warden to smooth integration for each eventually
[09:59] <@nesquena> onethirtyfive: for instance rails has a 'devise' plugin which makes warden use much easier
[10:00] <@nesquena> onethirtyfive: but thatd be later
[10:00] <onethirtyfive> nesquena: Yeah, rack-identity is only going to be suitable for apps that clearly separate the concerns of authentication and authorization.
[10:00] <onethirtyfive> nesquena: Warden ties authorization into the model... which is _not_ the domain... it's kinda... weird.
[10:01] <onethirtyfive> nesquena: Shucks, authorization strategies are only currently built into padrino. :D
[10:02] <onethirtyfive> nesquena: I guess there's no reason the authorization layer couldn't be built on rack, tho.
[10:02] <@nesquena> onethirtyfive: right
[10:02] <onethirtyfive> nesquena: thanks for your time, man. very helpful.
[10:03] <@nesquena> onethirtyfive: no problem. like i said this will be a very interesting project once it gets going
[10:03] <@nesquena> onethirtyfive: just got to take it one step at a time :)
[10:03] <onethirtyfive> nesquena: ya
15[10:10] * farmer_ ([email protected]) has joined #padrino
08[10:11] <SoreGums> (sorry wall of text...) I've seen one site that has a here's what this app does. then a "get cracking" button, that basically lets you start using the app, then as soon as something needs to be saved/persisted it pops up a box saying "we just need to identify you, email,facebook,etc" go through that process and then you can either fill in the rest of the details, like name etc, or keep using the app. that style of app would be pretty cool for the example app...
08[10:13] <SoreGums> it was the two parts of "identifying" then building the app specific stuff around that identity
[10:13] <onethirtyfive> SoreGums: thanks.
15[10:14] * zenom__ (~aj1973@unaffiliated/aj1973) Quit (Ping timeout: 276 seconds)
[10:14] <onethirtyfive> SoreGums: That's kinda what I'm shooting for: authentication is actually pretty domain-independent. Authorization, not so much. The reason I think previous attempts have failed is because they conflate "who are you?" with "am I allowed to do this?"
[10:14] <onethirtyfive> SoreGums: After speaking with nesquena, I decided to embark on a bit of hackin' to see if I can't make this happen.
15[10:16] * zenom_ (~aj1973@unaffiliated/aj1973) has joined #padrino
08[10:17] <SoreGums> onethirtyfive: i think you are onto something there ;)