Auth systems/OAuth/IRC log 2013-04-25

Apr 26 11:02:58 	Hey, sorry I'm a few minutes late. All here? Apr 26 11:03:06 	I'm here Apr 26 11:03:08 	I'm here Apr 26 11:03:36 	good enough for topic #1 :) Apr 26 11:03:54 *	Aaron|home lurks Apr 26 11:03:58 	I showed the login on labs to robla today Apr 26 11:04:12 	He was impressed it worked Apr 26 11:04:18 	\o/ Apr 26 11:04:35 	But, he does think the speed that the javascript check runs may be an issue Apr 26 11:04:57 	RobLa and I chatted about it for about 15 minutes and we think we have a solution Apr 26 11:05:17 	Do share Apr 26 11:05:32 	instead of refreshing the page after js exec, populate the user info via JS Apr 26 11:05:36 *	pgehres was typing :-p Apr 26 11:05:54 	possibly even hide the anon stuff until after exec Apr 26 11:06:09 	which then would be a subtle hint to anons to register Apr 26 11:06:29 	"populate the user info" == change skins and load gadgets, user scripts, etc? Apr 26 11:07:00 	there was a certain amount of "screw the skin change" on that first load Apr 26 11:07:19 	but the rest can be lazy loaded, yeah Apr 26 11:07:21 	"hide the anon stuff" == more or less document.body.style.display = 'none'? Apr 26 11:07:53 	no, div#p-personal Apr 26 11:08:20 	so that only that changed subtling after execution Apr 26 11:08:25 	*subtly Apr 26 11:10:17 	I just wonder how quick people will be to complain that the auto-login doesn't pick up their skin, user scripts, changed preferences, and so on. Thinking it's a bug. Apr 26 11:10:17 	My first reaction is I think that is going to confuse people more-- they're going to get to a page that has their username, but may or may not have their chosen skin, and won't have their action menu... it just feels a little wrong to me. Apr 26 11:10:35 	But, I think it's an option Apr 26 11:10:52 	the action menu and watchlist star could also be added after the fact Apr 26 11:11:04 	and someone with skin!=vector could get a refresh Apr 26 11:11:29 	we were going for the 90% solution Apr 26 11:11:38 	So pgehres, I'm not sure if robla also asked, but he suggested involving some UI people. Are you ok pulling them in? Apr 26 11:11:47 	yeah Apr 26 11:11:52 	on my list Apr 26 11:11:55 	Cool Apr 26 11:12:02 	Also stuff like "view source" versus "edit" (or does vector not do that?), and missing edit links, if the page is protected. Apr 26 11:12:28 	"view source" is only on a few wikis IIRC Apr 26 11:12:57 	anomie: people would complain quickly :) Apr 26 11:13:36 	we can always hide the entire page until the JS is done and then refresh :-) Apr 26 11:13:50 	they will complain less about that then the bump Apr 26 11:13:53 	To also make sure that not many people hit this situation, do you think it's also possible to do something like we do with the images now, and login as many browsers as we can on login? Apr 26 11:14:29 	pgehres: you can't cut back on personalized chromes...YOU WILL REGRET THIS! Apr 26 11:14:33 	;) Apr 26 11:14:39 	I think the only safe way is to open an iframe, and then have the js check run from the foreign wiki. Apr 26 11:15:11 	Aaron|home: i don't think you understand how excited robla was about this, I was trying to pull him back ;-) Apr 26 11:15:31 	that's what I get for leaving work early.. Apr 26 11:15:51 	lol Apr 26 11:16:22 	anomie/Aaron|home, any thoughts about if it would be possible, and not too ugly, to open an iframe to all wikis? Apr 26 11:16:48 	What do you mean by "open an iframe to all wikis"? Apr 26 11:17:07 	I assume you means wikis for the domains right? Apr 26 11:17:13 	*he means Apr 26 11:17:21 	Do something on the login success page that also lets us set a cookie on the other wikis Apr 26 11:17:29 	Remember that an iframe is considered a third-party context, so it has the same cookie issues as images do. Apr 26 11:18:31 	Yep, I'm thinking targeting the people who have visited the other sites. Active editors. The people likely to notice the delay when they hit a new project :) Apr 26 11:19:01 	I don't think the iframe has any advantage over the existing image thing for that part of it. Does it? Apr 26 11:19:38 	The security issue with the current images is the only reason I want to get rid of them Apr 26 11:19:46 	They work ok for cookie setting Apr 26 11:19:55 	(for non safari, non-mobile) Apr 26 11:21:27 	Anyway, not something we have to solve right now, but something else to think about. If we make the experience nice for most editors, then not many people will complain about the slow check :) Apr 26 11:22:25 	Btw, for labs, is there any reason the wikis don't have either other their autologin list? Apr 26 11:22:56 	sounds like missing conf? Apr 26 11:22:58 	The icon showing up on login is to the central wiki... I was thinking about adding the other wikis to the array. Any reason not to? Apr 26 11:23:04 	Probably :) Apr 26 11:23:08 	For the image autologin? So we can log into labs and still be logged out on the other wikis for testing the central login. Apr 26 11:23:40 	I just wanted to demo to robla the speed if the user got a cookie from the image, instead of waiting for the js check Apr 26 11:24:05 	CommonSettings.php, lines 1456-1461. Apr 26 11:24:28 	Cool, I'll add that tomorrow. I just didn't know if how it was, was intentional. Apr 26 11:24:36 	anomie: hmm, that makes sense Apr 26 11:24:58 	err, s/log into labs/log into the central domain/ Apr 26 11:25:28 	And yeah, I agree it's useful like that, so I'll take it out after I demo :) Apr 26 11:26:23 	is there a description of the iframe option anywhere? Apr 26 11:26:30 *	Aaron|home is sure how much faster that would be Apr 26 11:27:01 	Aaron|home: You mean using an iframe instead of images? Apr 26 11:27:19 	(as I was talking about above?) Apr 26 11:27:22 	yes Apr 26 11:27:28 	No, not yet Apr 26 11:27:36 	I'll add something... Apr 26 11:28:17 	later. Apr 26 11:28:27 	I can't multitask :) Apr 26 11:29:34 	But as far as testing goes, pgehres is talking with Zelko and Chris M about automating some testing for SUL2. Yay. Apr 26 11:29:55 	And I tested the current labs in a bunch of browsers today. Apr 26 11:30:10 	It's works for both FF 22 and mobile safari. Apr 26 11:30:24 	So mission accomplished, if we can make it a little faster :) Apr 26 11:31:56 	For OAuth stuff, I drew up some preliminary wireframes for the special pages on the train today. I'll get those uploaded tonight. Apr 26 11:32:58 	Aaron|home and anomie, if you guys have time tomorrow, I'd love to start working out the design of the oauth stuff. If you're out of idea for speading up sul2. Apr 26 11:33:06 	I think the only way to actually make it faster is to somehow reduce the number of steps. Apr 26 11:34:38 	anomie: I agree, that would be nice. If you have any more ideas, let me know. Apr 26 11:35:14 *	Aaron|home would have to look at that patch more Apr 26 11:35:23 *	James_F is now known as James_F|Away Apr 26 11:36:29 	We might be able to cut out two of the steps (skip C1, and do L1 on the initial page view) if we wanted to create a session for every anon that viewed a page. But I don't think we want to do that. Apr 26 11:38:17 	That would be nice, but I've assumed it's not possible. TimStarling, can correct me if I'm wrong though. Apr 26 11:40:01 	Alright, anything else we should chat about? Apr 26 11:40:33 	csteipp: one of the goals of this week was getting SUL merge ready, how is that going? Apr 26 11:41:05 	SUL merge? Apr 26 11:41:18 	SULv2 code, sorry, words are hard Apr 26 11:42:18 	I want to test the code without a central wiki, but as is, we could merge-- but the speed is something of a blocker. That's why we need to get it resolved asap. Apr 26 11:42:52 	okay, just wanted to make sure that we'd covered all blockers for that to happen Apr 26 11:43:13 	and then I have a note about P3P for IE Apr 26 11:43:33 	Yep, consider it blocked on the speed of the js login. anomie, aaron and I will be working on it :) Apr 26 11:43:35 	csteipp: what about that redirect login part? maybe that can be merged first Apr 26 11:43:54 	Aaron|home: yeah, we can do that I think Apr 26 11:44:44 	csteipp: Test without a central wiki by commenting out the line setting $wgCentralAuthLoginWiki in CommonSettings.php (line 1480)? Apr 26 11:44:45 	I *think* the IE/p3p is a non issue-- the login is working in IE7 and 8. Apr 26 11:45:01 	I did the P3P thing the other day ;) Apr 26 11:45:05 	Oh, nice! Apr 26 11:45:10 	Awesome Apr 26 11:45:24 	Is that in the patch? Apr 26 11:45:41 	Should be, unless I forgot to git review it. Let me look. Apr 26 11:45:57 	(admits to not having looked at the patch in a few days) Apr 26 11:46:14 	Yeah, it's in there. Apr 26 11:46:25 	cool. Apr 26 11:46:50 	It turns out the page in the iframe doesn't need P3P, but we do need it when setting the central cookies. Apr 26 11:47:32 	And IE10 needs it for setting the cookies on the CORS request, too. Apr 26 11:48:18 	And we'll just hope Microsoft doesn't go and break things in IE11 (talked to Robla about that bit of it on Tuesday) Apr 26 11:48:39 *	csteipp grumbles about MS in general.. Apr 26 11:48:42 	well, if that's it, I made this for everyone earlier in the convo http://cdn.memegenerator.net/instances/400x/37287100.jpg Apr 26 11:48:54 	and thinks about making a scumbag Microsoft Apr 26 11:49:20 	awesome Apr 26 11:49:33 	Cool. Thanks all! Apr 26 11:49:39 	thank you csteipp Apr 26 11:52:01 	csteipp: I noticed that onUserLoadFromSession doesn't set $result except for the "auth ok" case Apr 26 11:52:06 *	pgehres is now known as pgehres|away Apr 26 11:52:42 *	Aaron|home is trying to figure out how global logout actually works fully now Apr 26 11:53:17 	I can see how it stops further auto-login Apr 26 11:54:04 	The cookies (iirc) were all deleted on logout Apr 26 11:55:58 	for other wikis? Apr 26 11:56:53 	it must be stopping the local ones from getting set somewhere Apr 26 11:59:39 *	Aaron|home stares at SpecialUserlogin Apr 26 12:00:19 	Aaron|home: Ah, since they're both on the same top level domain right now, the one centralauth cookie delete is enough Apr 26 12:00:50 	I mean even of WMF sites now Apr 26 12:01:20 	onUserLoadFromSession falls through to local sessions if there was no CA one (I thought it didn't do that before) Apr 26 12:01:48 	Oh, I think the local sessions are never filled right now Apr 26 12:01:53 	(iirc) Apr 26 12:02:14 	Except on the wiki where they actually login Apr 26 12:02:26 <Aaron|home>	they'd have to be, but I can't find code doing that Apr 26 12:02:36 <Aaron|home>	(have to be not filled) Apr 26 12:02:36 	Aaron|home: Possibly where it unsets wsToken and Token in onUserSetCookies? Apr 26 12:03:24 <Aaron|home>	I passed right over that, that's it Apr 26 12:04:59 <Aaron|home>	so the cookies/session are still there be the stored session token is destroyed...that works Apr 26 12:06:26 <Aaron|home>	that username/sessionid cookie that is Apr 26 12:10:03 <Aaron|home>	s/be the/but the