Geoloqi IRC

2010-07-26

00:01 <tjgillies> hrm actually i don't think the actual client id/secret gets sent does it? its just used to generate request token
00:01 <tjgillies> need to brush up on actual spec, ive been babied by libraries ;)
00:02 <aaronpk> it gets sent when the client requests tokens, but not when it makes requests for resources
00:02 <aaronpk> it's sent using HTTP Basic auth
00:03 <aaronpk> "The authorization server MAY support additional authentication schemes suitable for the transmission of a password.
00:04 <aaronpk> which means we have the option of using Digest auth
00:06 <tjgillies> so i guess that means it doesn't matter if they know client id/secret?
00:07 <aaronpk> who is "they"?
00:07 <tjgillies> the geoloqi server owner
00:07 <aaronpk> the geoloqi server needs to get the client ID/secret in order to verify anything
00:07 <tjgillies> right, thats what ive been saying
00:08 <tjgillies> i was asking if that was bad
00:08 <aaronpk> ah, well you bring up an interesting point
00:09 <tjgillies> afaik, theres no opensource tool that uses oauth
00:09 <aaronpk> I wouldn't want someone else to be able to see the iPhone client's id/secret, but the iPhone sending it to my server is fine.
00:09 <aaronpk> If the user changes the server URL in the iPhone client, the client shouldn't send the geoloqi id/secret to the user's server
00:10 <tjgillies> then how will it auth?
00:10 <aaronpk> it'll need a new id/secret somehow
00:10 <tjgillies> hrm ok have an idea
00:11 <tjgillies> have option to put in client id/secret from "create an app page"
00:11 <tjgillies> don't know if that would be too technical for users
00:11 <aaronpk> ah that's probably a good way to do it
00:11 <tjgillies> its what im implementing right now, which is how i came up with my original question
00:12 <aaronpk> wait a sec
00:12 <aaronpk> that's backwards
00:13 <aaronpk> what exactly are you implementing? a geoloqi server in Node.js?
00:13 <aaronpk> or a geoloqi client?
00:13 <tjgillies> server
00:13 <aaronpk> whoa ok crazy
00:14 <tjgillies> yeah, im copying your api
00:14 <tjgillies> but making a javascript implementation
00:14 <aaronpk> so you're gonna need to do oauth from the server side too
00:14 <tjgillies> yeah
00:14 <tjgillies> thats what im doing now
00:14 <aaronpk> i doubt there's a Node.js OAuth 2 library out there yet
00:14 <tjgillies> nope
00:15 <tjgillies> thats why im writing one, i told you id write one if you suported oauth2
00:15 <aaronpk> sweet
00:15 <tjgillies> or at least use mine until someone writes a better one ;)
00:15 <tjgillies> which is inevitable
00:16 <aaronpk> not if you write yours first! I bet yours will become the "official" one
00:17 <tjgillies> oh god, i hope not
00:17 <tjgillies> ;)
00:18 <aaronpk> ok so your question about the id/secret
00:18 <aaronpk> if you download the iPhone app, you need a way to enter a new id/secret into the app to use with your server, which will be different from the id sent to my server
00:19 <tjgillies> yeah, thats what i said ;)
00:20 <aaronpk> we'll have to add that to the Settings page
00:20 <tjgillies> but that means every user will need to make their own app
00:21 <aaronpk> if you had a way to enter your own id/secret into the app's settings screen then you wouldn't need a new build of the app
00:22 <tjgillies> thats essentially a username/password
00:22 <aaronpk> yes, for the app, not for the user
00:22 <tjgillies> but each phone should have a seperate client id/secret?
00:23 <tjgillies> and that would have to match client id/secret of server
00:23 <tjgillies> well on server
00:24 <aaronpk> *each* phone doesn't need a separate client id, you only need a new client id to talk to a new server
00:25 <Loqi> [[Mobile App Guidelines]] http://geoloqi.org/index.php?diff=247&oldid=241&rcid=249 * Caseorganic * (+78)
00:25 <aaronpk> the default build of the iPhone app will include the id/secret that I've got in my database. if you're running your own server, you'd need to enter the id/secret that's in your db
00:25 <Loqi> [[Mobile App Guidelines]] http://geoloqi.org/index.php?diff=248&oldid=247&rcid=250 * Caseorganic * (+67)
00:26 <Loqi> [[Mobile App Guidelines]] http://geoloqi.org/index.php?diff=249&oldid=248&rcid=251 * Caseorganic * (+1)
00:26 <tjgillies> so you have multiple people sharing the same client id/secret, is that a good idea?
00:26 <aaronpk> yes
00:26 <tjgillies> ok
00:26 <aaronpk> it's equivalent to OAuth 1's consumer key and secret
00:27 <aaronpk> all Tweetdeck apps use the same key/secret
00:27 <aaronpk> that's how Twitter knows it's Tweetdeck
00:27 <tjgillies> yeah but you don't know what it is
00:27 <tjgillies> with this model everyone sharing will know what the id/secret is
00:28 <aaronpk> we'll need to make sure the official iPhone app's client id/secret isn't visible to users
00:28 <tjgillies> right, so its ok if they know id/secret for other clients, just not the "official" one
00:30 <aaronpk> if you're writing a client talking to geoloqi.com, you'll get your own id/secret, which you shouldn't give out to others
00:31 <tjgillies> right
00:31 <tjgillies> but for "normal" users they'll have to share a public one
00:31 <tjgillies> if they use mobile app
00:31 <tjgillies> and aren't talking to geoloqi.com
00:32 <aaronpk> well if you're talking to something other than geoloqi.com, you presumably have a way to create a new client id/secret, so you'd create your own on your server then enter that into the app
00:33 <tjgillies> which is "creating your own app" i.e. the process of creating a new client id/secret
00:34 <aaronpk> i *think* we're on the same page here, but the terminology is slightly confusing
00:36 <tjgillies> yeah the point im making is that any user who uses any server besides geoloqi.com will have to create a new id/secret (which is an app), and then enter that app information into the mobile application
00:36 <aaronpk> perfect
00:37 <tjgillies> which might be "tough" for normal people
00:37 <tjgillies> oh well, only way i see how to do it though
00:37 <aaronpk> unless there was an API method for provisioning client id/secrets
00:37 <aaronpk> which is not too unrealistic
00:38 <aaronpk> but let's take it one step at a time
00:38 <tjgillies> yeah
00:38 <tjgillies> its good to know what potential problems there are, so we can think of addressing them, instead of accidently falling into them
00:38 <aaronpk> yea, i think this is pretty solid so far
00:41 <tjgillies> aaronpk, any idea what you want to use for 'scopes'?
00:41 <aaronpk> yea, just took some notes but haven't officially named them yet, one sec
00:42 <tjgillies> ok
00:45 <aaronpk> there will be current_location and location_history, which also justifies having separate location/last and location/history methods ;)
00:45 <aaronpk> maybe it should be called last_location actually
00:47 <tjgillies> yeah moer accurate
00:47 <tjgillies> more
00:49 <Loqi> [[API]] http://geoloqi.org/index.php?diff=250&oldid=246&rcid=252 * Aaronpk * (+667) added oauth scopes
00:51 <tjgillies> the default path for a lot of oauth2 client libraries is /oauth/access_token
00:51 <tjgillies> its what facebook uses
00:52 <aaronpk> the spec used "token" as the example :P
00:52 <Loqi> Loqi grabs aaronpk's tongue
00:53 <aaronpk> it uses the same path for access tokens, refresh tokens, and password grants
00:55 <aaronpk> tho I suppose separating out the access types into different paths would make access control easier
00:56 <tjgillies> i think the server might return the paths in response parameters after request to /oauth/authorize
00:58 <aaronpk> i think that's just the token
00:58 <tjgillies> gotcha
00:58 <aaronpk> "The location of the token endpoint can be found in the service documentation, or can be obtained by using [[ OAuth Discovery ]]
00:59 <tjgillies> oh, didn't even know oauth discovery existed
00:59 <aaronpk> heh yea
01:00 <aaronpk> wille be fun to get there eventually
01:02 <aaronpk> how far along are you with an oauth2 client?
01:03 <tjgillies> not very far
01:03 <tjgillies> still trying to get a good grasp of the spec before i go screwing things up ;)
01:04 <aaronpk> k. I'm almost done tying in the oauth methods and will need a client to test it
01:06 <tjgillies> i can use ruby to test it
01:06 <tjgillies> the oauth2 client gem only requires a few lines of code
01:06 <aaronpk> oh awesome ok
01:07 <aaronpk> makes me feel better using someone else's code to test against my server rather than writing a client too
01:11 <tjgillies> aaronpk, fwiw, i think putting a leading "/" in front of resource paths would make it more aesthetic
01:12 <aaronpk> the full path will be api.geoloqi.com/1/location/last, that won't be confusing then?
01:13 <tjgillies> ok nevermind
01:19 <tjgillies> ok app is setup, just waiting for id/secret
01:20 <aaronpk> your server is ready?
01:22 <tjgillies> no my client
01:22 <aaronpk> the ruby one?
01:22 <tjgillies> yeah
01:27 <aaronpk> cool. I have no idea if this is going to work yet!
01:27 <aaronpk> i've been writing code for the last couple hours but haven't run any of it yet :/
01:31 <aaronpk> tried to run that, got an error http://gist.github.com/490308#comments
01:33 <tjgillies> you need to 'gem install' the required gems
01:33 <aaronpk> i thought I got them all
01:34 <aaronpk> sinatra, oauth2, json
01:36 <tjgillies> hrmm. what are you running it with?
01:36 <tjgillies> on the command line
01:36 <tjgillies> might also want to gem install thin fi you don't have it
01:36 <tjgillies> if*
01:37 <aaronpk> i have ruby 1.8.6.399
01:38 <aaronpk> I ran `ruby geoloqi.rb` from the command line, not as root
01:39 <aaronpk> `sudo gem install thin` dies with https://gist.github.com/34040d46970acf2f2c75
01:40 <tjgillies> are you on a mac?
01:40 <aaronpk> this is a fedora server
01:41 <tjgillies> yum groupinstall "Development Tools" "Legacy Software Development"
01:41 <tjgillies> sudo
01:42 <tjgillies> thin uses c libraries for speed
01:42 <aaronpk> oh god so many packages
01:43 <tjgillies> yeah, fedoras dev environment is dependency bloated
01:43 <tjgillies> i actually like ubuntu the best
01:43 <tjgillies> was using arch but processes liked to segfault randomly
01:46 <aaronpk> got it to build by installing just g++ stuff
01:46 <aaronpk> now thin is installed, but still getting that error
01:49 <tjgillies> damn
01:49 <Loqi> lolz
01:49 <tjgillies> runs fine on my machine
01:50 <aaronpk> I don't know enough about ruby to decode that error message
01:51 <tjgillies> make a file with a line that just says require 'sinatra'
01:52 <tjgillies> and try to run that
01:52 <aaronpk> yea I get the same error
01:52 <tjgillies> your system has a jacked up install of sinatra
01:53 <aaronpk> well crap
01:54 <tjgillies> might be your ruby version
01:55 <tjgillies> any way to can up to 1.8.7?
01:55 <aaronpk> doesn't look like that's available from the package manager yet
01:56 <tjgillies> packagers always mess up ruby
01:56 <tjgillies> you might have a package of sinata
01:56 <tjgillies> what does yum search sinatra do?
01:57 <aaronpk> one sec, updating all my packages
01:57 <aaronpk> rubygems was one of the updates
01:57 <tjgillies> ok
01:58 <tjgillies> that might be the prob
01:58 <tjgillies> one thing i like about ruby 1.9 is that rubygems is part of the language and not some hacked together dependency
02:02 <aaronpk> ok well the yum package of sinatra was not installed so I isntalled it, but still getting that error
02:06 <tjgillies> hrm.. its probably something with /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra.rb
02:06 <tjgillies> line 4
02:08 <aaronpk> line 4 is "require 'sinatra/base'"?
02:08 <tjgillies> yeah nevermind i'll setup a python outh2 file
02:08 <aaronpk> heh ok
02:08 <tjgillies> hopefully you have a better python install
02:23 <aaronpk> oh jeez, they changed the names of the auth types between version 9 and 10
02:24 <tjgillies> http://github.com/simplegeo/python-oauth2 this is the best python one
02:24 <tjgillies> all the other ones besides ruby are so convoluted though
02:24 <tjgillies> people think to technically
02:25 <tjgillies> s/to/too/
02:25 <aaronpk> it's quite a bit simpler than v1
02:25 <tjgillies> yeah the spec itself, i mean the clients
02:37 <aaronpk> *whew*
02:39 <tjgillies> what?
02:39 <aaronpk> finally ran all that codfe
02:39 <aaronpk> and got an access token given user/pass!
02:39 <tjgillies> nice!
02:40 <aaronpk> ok that's about all i've got in me for this evening
02:40 <tjgillies> nicely done
02:41 <tjgillies> i'll talk to you tomorrow
02:41 <aaronpk> alright, ttyl
07:42 caseorganic joined #geoloqi
07:43 caseorganic_ joined #geoloqi
08:13 workshop joined #geoloqi
08:56 jtbandes joined #geoloqi
10:10 <donpdonp> needed: translate username@geoloqi.com to a URL that gives json locations
10:20 <aaronpk> agreed
10:21 <aaronpk> except that we won't be providing actual email services
10:21 <aaronpk> which I think is then confusing to users since that looks a lot like an email address
10:21 <donpdonp> right, that was discussed on the webfinger list in some detail
10:21 <aaronpk> hm I should look at that
10:21 <donpdonp> i think they're going with it anyways
10:26 <aaronpk> do you think twitter.com is going to start supporting aaronpk@twitter.com? I don't...
10:27 <donpdonp> i dont expect twitter to support SMTP at that address, but its possible they will support webfinger discovery for that address
10:28 <aaronpk> interesting point about the autocomplete at the bottom
10:28 <donpdonp> the flow im thinking of is, android client asks for someone to follow. the identifier for someone is their email address, OR if its known they use geoloqi, bob@geoloqi.com is an acceptable identifier
10:28 <donpdonp> that way bob can tell me how to reach him on geoloqi, and not give out his email address.
10:28 <aaronpk> interesting case
10:28 <aaronpk> I want to set up some sort of discovery on parecki.com so I can use aaron@parecki.com
10:29 <donpdonp> or maybe his email address also gives location provider info
10:29 <donpdonp> right, i think it can go either way, depending on the person
10:29 <aaronpk> yea
10:32 <aaronpk> is there a discussion somewhere about service discovery?
10:32 <aaronpk> like how would you say "this is my ___ provider"
10:33 <donpdonp> not that i know of. i think that is territory that needs to be defined
10:33 <aaronpk> let's DO EET
10:34 <donpdonp> DOOO EET
10:34 <Loqi> Loqi slaps donpdonp with a large trout
10:35 <donpdonp> SHOOOT HER! <jurassic park>
10:40 <aaronpk> so I go to webfinger.org and put in my email, and it finds a bunch of things listed in my google profile, but they're pretty disorganized and not nice URLs
10:42 <aaronpk> I want those to be "typed"
10:42 <donpdonp> yup. i think rel='describedby' is an attempt at that
10:43 <donpdonp> example flow: http://pastie.org/1060813
10:43 <donpdonp> using rel='locatedat'
10:47 <donpdonp> which i made up :)
10:56 <aaronpk> what does "describedby" mean?
11:02 <aaronpk> donpdonp: I made some serious progress on OAuth 2 last night
11:05 <donpdonp> aaronpk: woo!
11:05 <donpdonp> on the server side?
11:05 <aaronpk> yep
11:05 <donpdonp> what lib are you using
11:05 <donpdonp> donpdonp is afraid the answer is 'my own'
11:05 <aaronpk> luckily someone started one for php http://code.google.com/p/oauth2-php/
11:05 <donpdonp> ah :)
11:06 <aaronpk> but it's at v9 of the spec so I had to make a few minor tweaks for v10
11:06 <donpdonp> word.
11:06 <aaronpk> it's surprisingly simpler than oauth1
11:06 <aaronpk> it almost doesn't need a library on the client side
11:07 <donpdonp> interesting.
11:07 <aaronpk> especially for the password method
11:08 <donpdonp> donpdonp nods
11:49 jtbandes_ joined #geoloqi
15:52 workshop joined #geoloqi
16:05 tjgillies joined #geoloqi
17:00 <jtbandes> revelation of the day: geoloqi rhymes with hokey-pokey
17:00 <jtbandes> discuss
17:34 caseorganic joined #geoloqi
18:00 workshop joined #geoloqi
18:02 <workshop> maybe the hokey pokey IS really what it's all about
18:17 <tjgillies> aaronpk, i have my serverside ouath2 working also
18:17 <aaronpk> nicely done
18:19 <tjgillies> aaronpk, this is how my flow works, you ask for "code" at /oauth/authorize, then it redirects you to my geoloqi server and asks if you want to allow app access, you click yes, then it redirects back with an access token. is that how the mobile flow is going to be?
18:19 <aaronpk> the user will enter their user/pass in the mobile phone directly, so the phone will talk directly to /oauth/token to get an access token
18:20 <tjgillies> aaronpk, why not have it ask username/pass on the webpage?
18:20 <aaronpk> wanted to not have to hop out to a web page from the mobile phone
18:21 <tjgillies> ok
18:21 <tjgillies> so thats whay you were doing the digest auth stuff
18:21 <tjgillies> why*
18:22 <aaronpk> yea
18:22 <aaronpk> digest auth of the client id/secret
18:23 <tjgillies> ok i'll redo my server flow
18:23 <aaronpk> it'll use oauth/authorize for any web apps, just not the mobile ones
18:23 <tjgillies> ok so i'll add an additional flow
18:23 <tjgillies> because mobile is my first priority ;)
19:00 <tjgillies> curl "rital.in/oauth/token?grant_type=password&username=tyler&password=tyler"
19:00 <tjgillies> {"access_token":"tgosvgOaUogpvE2MDJH7BP70cS2PzNSF","expires_in":3600}
19:01 <tjgillies> still need to add section to verify client_id and client_secret
19:14 <aaronpk> that's an important bit ;)
19:19 <tjgillies> im installing base64 library right now so i can do it, im suprised nodejs doesn't have native base64 support
19:49 <tjgillies> woohoo: curl "rital.in/oauth/token?grant_type=password&username=tyler&password=tyler" -u foobar:ibDVVWRSmr3Zr0tvwLJByC6ENN3sH9qr
19:49 <tjgillies> {"access_token":"6bmwrN3rfea8dxSW8zmSmT5UaGptTBQo","expires_in":3600}
19:49 jtbandes joined #geoloqi
19:49 <aaronpk> awesome!
19:49 <aaronpk> i'll be back later this evening to poke at some more code
19:50 <aaronpk> jtbandes: are you available this week or weekend to work on some oauth code for the iphone app?
19:51 <jtbandes> I'm going on vacation this weekend, might do some hacking before/after then
19:51 <jtbandes> what was awesome that I missed?
19:51 <aaronpk> ok great, i gotta run but i'll be back later this evening
19:52 <tjgillies> jtbandes, i added oauth2 suport for basic auth to my nodejs geoloqi server
19:53 <jtbandes> nice
19:53 <jtbandes> aaronpk mentioned something about not using oauth 2.0 on the mobile clients
19:53 <jtbandes> [18:58] <aaronpk> oh right... I didn't want to use OAuth 2 for themobile clients because of the overhead of the SSL handshake
19:54 <tjgillies> it doesn't "have" to be ssl
19:55 <tjgillies> i mean the spec says it does, but afaik, both aaron and i use normal http
21:01 aaronpk_ joined #geoloqi
21:02 tjgillies joined #geoloqi
21:05 tjgillies joined #geoloqi
21:05 donpdonp joined #geoloqi
21:05 Loqi joined #geoloqi
21:08 tjgillies joined #geoloqi
21:08 donpdonp joined #geoloqi
21:08 Loqi joined #geoloqi
21:14 donpdonp joined #geoloqi
21:14 tjgillies joined #geoloqi
21:14 Loqi joined #geoloqi
21:18 Loqi joined #geoloqi
21:18 tjgillies joined #geoloqi
21:18 donpdonp joined #geoloqi
21:18 aaronpk_ joined #geoloqi
22:17 <aaronpk_> jtbandes: I read through the spec and realized that it's possible to do non-ssl communication even with oauth 2
22:17 <jtbandes> ah
22:17 <aaronpk_> the negotiation to get the access token will be SSL because that will happen only once
22:17 <aaronpk_> then it can send data over http with an access token that expires often
22:18 <aaronpk_> and it will periodically request a new access token
22:18 <aaronpk_> it's actually pretty well thought out
22:30 caseorganic joined #geoloqi
23:25 <tjgillies> aaronpk, what api resource are you going to port over to the new version first?