Auth systems/OAuth/IRC log 2013-05-02

May 03 11:02:41 <James_F> Hey.
May 03 11:02:50 <pgehres> Hi
May 03 11:02:52 <csteipp> Good morning/evening all
May 03 11:04:55 <csteipp> Just posting one more thing, and we'll start up :)
May 03 11:07:38 <csteipp> Alright, sorry about that
May 03 11:07:59 <csteipp> More stuff added to https://www.mediawiki.org/wiki/Auth_systems/OAuth in case anyone has time for coding this week
May 03 11:08:22 <csteipp> So SUL: I merged Aaron|home's patch
May 03 11:08:40 <csteipp> I didn't get time to re-look at anomie's patches
May 03 11:08:49 <csteipp> But I should be able to do that tomorrow
May 03 11:09:15 <csteipp> So next week, pgehres, can you keep bugging Reedy about getting the new domain setup?
May 03 11:09:25 <James_F> Is that set for Monday?
May 03 11:09:29 <pgehres> Yeah.
May 03 11:09:44 <anomie> I saw he put in a few patchsets about that today
May 03 11:10:17 <James_F> It's going to be called "loginwiki" in the DB list per my intervention.
May 03 11:10:24 <James_F> Adding value, me?
May 03 11:10:25 <TimStarling> so the pending patches are "(bug 46905) Add "centralauthtoken" to API" and "Add Javascript login check against the central wiki", correct?
May 03 11:10:41 <anomie> Those are mine, yes
May 03 11:10:46 <csteipp> TimStarling: Yep
May 03 11:11:49 <TimStarling> so the first one, the idea is that that will be used for things like commons uploads?
May 03 11:12:00 <csteipp> Yep
May 03 11:13:15 <csteipp> And tomorrow pgehres and I (and anyone else?) are talking to Brandon about the UX
May 03 11:13:37 <TimStarling> so there is some concrete plan to actually use it?
May 03 11:13:50 <TimStarling> it's just just "build it and they will come"?
May 03 11:13:55 <csteipp> Actaully, anomie and Aaron|home, it would be great to have you join us.
May 03 11:13:57 <TimStarling> s/just/not/
May 03 11:14:12 <csteipp> TimStarling: Yeah, mobile is the use case
May 03 11:14:17 <anomie> Well, the mobile people have been complaining about SUL not working
May 03 11:14:23 <James_F> csteipp: Happy to not attend unless you want me. :-)
May 03 11:14:55 <TimStarling> do they have some non-working code already that uses the current system?
May 03 11:14:57 <csteipp> James_F: I assumed you were coming, and it would be nice to have your input
May 03 11:15:03 <anomie> csteipp: At the UX thing? Feel free to add it to my calendar
May 03 11:15:10 <James_F> csteipp: Ah, OK, adding to my calendar now.
May 03 11:15:25 <TimStarling> or is it just at the design stage?
May 03 11:15:33 <csteipp> TimStarling: They're using their redirect code right now
May 03 11:15:39 <csteipp> Which seems to be working
May 03 11:15:54 <pgehres> James_F, anomie, Aaron|home - added you all to the meeting
May 03 11:16:00 <James_F> Thanks!
May 03 11:16:01 <Aaron|home> ok
May 03 11:16:26 <anomie> ok
May 03 11:16:27 <TimStarling> this is in MobileFrontend? or elsewhere?
May 03 11:16:40 <csteipp> Actually, I assumed it was working based on the number of mobile uploads, but awjr pinged me last night about a cookie issue they're having
May 03 11:16:54 <csteipp> I'm pretty sure MF
May 03 11:17:31 <csteipp> Jon put in a redirect patch a few weeks ago
May 03 11:20:28 <csteipp> I can't find the patch atm
May 03 11:22:53 <csteipp> So yeah, post meeting tomorrow, we'll get an opinion on the current UX, and see if Brandon thinks it's ok as is, or if we need to find a way to shorten the javascript check before we go live
May 03 11:23:55 <csteipp> One thing that we probably should start work on now is a way to safely attempt an autologin-like process from the login success page
May 03 11:24:04 <TimStarling> so do the mobile people have any design or requirements document?
May 03 11:24:58 <csteipp> I'm sure they do, but I don't know where
May 03 11:25:14 <TimStarling> ok
May 03 11:25:56 <csteipp> I heard a couple people mention they had a big goal tied to having uploads to commons from the mobile web, so I imagine it's speced out somewhere
May 03 11:28:06 <csteipp> Aaron|home or anomie, would either of you want to take a stab at reworking autologin?
May 03 11:28:37 <anomie> I can take a look tomorrow
May 03 11:28:48 <csteipp> My first thought was if you just opened an iframe to each wiki (instead of loading images with tokens), and allow the javascript check to run, it should handle everything safely
May 03 11:28:51 <anomie> This is basically replacing the images with iframes?
May 03 11:28:56 <csteipp> Yep
May 03 11:29:16 <csteipp> I'm open to other ideas, but I haven't thought up any yet
May 03 11:29:39 <pgehres> csteipp: I think it would be cool to provide feedback on which projects we were able to get cookies for
May 03 11:29:42 <anomie> I might just open an iframe to the iframe-based version of the js check, really
May 03 11:31:05 <csteipp> It may be nice if gave feedback, although then people who may never need it may get confused that something in their login "failed"...
May 03 11:31:25 <pgehres> Don't use the word "failed" :-)
May 03 11:32:28 <pgehres> The server kittens were able to automatically log you into: ...
May 03 11:32:40 <pgehres> Or whatever. Kind of a UX thing
May 03 11:32:59 <csteipp> Yeah, maybe add that to the list of thing to ask Brandon, if we don't run out of time
May 03 11:34:06 <csteipp> Alright, and tomorrow post meeting we'll send out an email to Tim and anyone else who isn't there with the results, because that will likely influence what we actually roll out next week
May 03 11:34:49 <csteipp> Anything else on SUL we need to discuss?
May 03 11:35:12 <pgehres> Nothing technical that I can think of atm, but I am brain-dead
May 03 11:35:19 <anomie> I started looking at the changes to the API classes for handling the OAuth grants today.
May 03 11:35:42 <anomie> Can we get away with never actually making a list of all the possible grants?
May 03 11:35:49 <csteipp> anomie: great! Let's transition officially to oauth then :)
May 03 11:36:40 <pgehres> an update to SUL: basic browser tests are in place, we should add to them and apergos is going to work on SSL in beta labs
May 03 11:36:47 <csteipp> anomie: you mean like query/generate the list somehow when we need it?
May 03 11:37:10 <csteipp> Or allow arbitrary strings that we figure out the meaning to somehow?
May 03 11:37:27 <anomie> csteipp: Because making the list seems like it will require instantiating every registered API module to ask it "what grants do you support?"
May 03 11:37:48 <anomie> Which is fairly expensive. If it's a rare thing to have to do, we could get away with it though.
May 03 11:38:08 <csteipp> anomie: So are you thinking we should have a list that we keep around?
May 03 11:38:27 <anomie> If we make a list, we'd probably want to memcache it
May 03 11:38:50 <csteipp> We can definitely do that
May 03 11:39:17 <anomie> Much like how the API help page (https://en.wikipedia.org/w/api.php) is memcached so it doesn't have to be regenerated all the time; that also requires instantiating every registered API class
May 03 11:43:47 <csteipp> Cool. anomie, would you be up for writing up some notes on how you think we should do the permissions?
May 03 11:44:26 <csteipp> And then we can fine tune it in discussions next week-ish?
May 03 11:44:39 <anomie> In what way? Code-level, or an overview of the general permissions concept?
May 03 11:44:52 <csteipp> Just the general concept
May 03 11:45:11 <csteipp> With as many pointers into the code as you like :)
May 03 11:45:25 <anomie> ok.
May 03 11:45:50 <csteipp> It's just one of the main things that will affect all users, so I want to make sure we have it as well thought out as possible
May 03 11:45:53 * anomie looks for a good place to insert it into Auth_systems/OAuth
May 03 11:46:32 <csteipp> Just append :) (in all seriousness, I'll probably try to clean that page up sometime in the next week too... it's getting long)
May 03 11:47:54 <csteipp> Speaking of stuff on there, I added https://www.mediawiki.org/wiki/Auth_systems/OAuth#Pages_.2F_Basic_data_flow just as we started
May 03 11:48:42 <csteipp> One design decision: I was thinking we could allow pretty much open registration of Clients to anyone, and then admins with permissions can approve
May 03 11:48:51 <csteipp> (or we can have an auto-approve flag somewhere)
May 03 11:49:02 <csteipp> Does that sound sane?
May 03 11:49:21 <anomie> Sounds sane to me, if approval is even needed.
May 03 11:49:45 <Aaron|home> yes
May 03 11:50:44 <csteipp> I think to start we want to. Just in case some legal/security/perf issues come up while we're just starting
May 03 11:51:08 <csteipp> But I imagine longer term, we'll have it open
May 03 11:51:12 <Aaron|home> I don't see a contact address for app registration there
May 03 11:51:47 * csteipp missed that...
May 03 11:52:01 <csteipp> Feel free to update it :)
May 03 11:52:09 <csteipp> Yeah, we do want that I think
May 03 11:52:57 <Aaron|home> and the page with the request queue should easily mark ones with confirmed email addresses (via tokens)
May 03 11:53:06 * Aaron|home is reminded of ConfirmAccount
May 03 11:53:24 <csteipp> That would work
May 03 11:53:42 <csteipp> You mean users who register apps, and also have a confirmed email? Or that we re-confirm it?
May 03 11:54:28 <csteipp> (I can see pros/cons for both ways)
May 03 11:58:22 <Aaron|home> I mean making those ones easy to spot in the queue, although the queue will probably be small anyway
May 03 11:59:37 <anomie> Something else I was thinking of (back on the permissions grants), it would be helpful if the API module can tell the User object basically "pretend the user doesn't have rights X, Y, and Z". So e.g. if the client isn't granted the ability to see deleted revisions, the API can just tell the User object "Pretend you don't have 'deletedtext'" instead of having everything else in MediaWiki having to take options saying whether to allow viewing dele
May 03 11:59:37 <anomie> ted revisions on top of the existing checks for that user right. But does that sound sane?
May 03 12:01:09 <csteipp> By "API", do you mean OAuth interpretting the api? Or the core api?
May 03 12:01:25 <Aaron|home> as in a blacklist of a whitelist of rights?
May 03 12:02:07 <anomie> Core API. OAuth's interaction here is just in telling the API which permissions the client has been granted by the user.
May 03 12:02:15 <Aaron|home> csteipp: I assume the later (when $wgUser is determined via OAuth)
May 03 12:02:19 <anomie> Aaron|home: Yeah, that's probably a good way to put it
May 03 12:02:35 <Aaron|home> a blacklist would be a bit scary of course
May 03 12:03:47 <csteipp> There's a hook for modifying the list of permissions when userCan (iirc) is called. Again iirc, it has the list of all user rights, and the hook could remove from the array, or only allow a subset to be returned.
May 03 12:05:45 <csteipp> Hmm.. actually, I'm not seeing that. I may have imagined it...
May 03 12:05:49 <anomie> UserGetRights? The problem is that that's cached, so if something triggers the rights loading before the API module decides which rights it needs to filter out... Or else, a lot of calls to ->clearInstanceCache()
May 03 12:06:13 <csteipp> That sounds right. Bummer.
May 03 12:10:40 <csteipp> Alright, I don't want to keep everyone too late. Anything else we need to discuss?
May 03 12:11:09 <pgehres> Not from em
May 03 12:11:11 <pgehres> *me
May 03 12:11:47 <csteipp> And anomie, these are exactly the types of things we need to figure out-- I think having the general concept up with technical pointers will help us all thing through the issues. Hopefully we spot most of them before we get too far implementing :)
May 03 12:12:05 <csteipp> s/thing/think/ ...
May 03 12:12:31 <anomie> csteipp: Of course, I only thought of these because I started implementing ;)
May 03 12:12:52 <csteipp> nice :)
May 03 12:12:52 <pgehres> I tend to prefer to ship v3 of my app :-)
May 03 12:13:19 <csteipp> Cool. Meeting adjourned then :)
May 03 12:13:24 <pgehres> cya tmr