danielwilmshey and welcome here :)14:02
X-Fadedanielwilms: Hi14:02
danielwilmshi X-Fade14:02
-!- Jaffa [] has joined #maemo-meeting14:02
danielwilmshey...bergie...u could make it...thats nice ;)14:02
bergieyeah, unless I reach my daily bandwidth cap... crappy hotel WiFi :-/14:03
sopihello. that's me ferenc.14:03
bergieanyway, I'm sitting in a RL meeting so my attendance will be limited14:03
danielwilmssopi ahhh...just wanted to ask 14:03
danielwilmsbergie ok14:04
danielwilmsi wanted to start with a small update14:04
danielwilmsthen discuss about how we manage the user data14:04
danielwilmsand then we can discuss the things, which are unclear14:04
danielwilmsis that ok??14:04
sopiyes, fine by me.14:05
X-FadeSure14:05 dont know if everybody has seen the wiki page but the status at the moment is like this:14:05
danielwilmsthe authentication service is up and running and it works quite stable14:06
danielwilmsCAS seems to be a nice thing of software...besides some dependencies and the spring stuff it is ok to set it up14:07
danielwilmsthe wiki is somehow integrated...fought a bit with the php stuff but does not work really smoothly yet...the biggest issue is to allow anonymous readers as well but this does not seem to be to hard14:08
danielwilmsright now I am working on the integration of GForge...cannot really say how much time it will take14:09
sopiabout Gforge: did you check out the code from "garage" ?14:09
sopi( that is)14:10 I took first a clean installation, because I think the authentication was changed in some way, right?14:10
danielwilmssopi...or do you think I should start with that?14:11
-!- tekojo [] has joined #maemo-meeting14:11
sopidanielwilms: a clean installation of v4.5.20 ?14:11
sopidanielwilms: taking our version from garage would make it easier to apply the necessary patches (if any) later on.14:12
sopii am not sure how much code we changed around authentication.14:12
sopibut there are certainly "layout" changes compared to the upstream v4.5.20.14:13
danielwilmsthe wiki is done in a way, that the the link is redirected from the old url to the new one14:13
danielwilmsso it should not change too much14:13
danielwilmsonly add stuff14:13
danielwilmsand then it gives the name it gets from cas to the component14:14
X-Fadedanielwilms: There are auth plugins for mediawiki.14:14
X-FadeSo you can plug in authentication without needing to redirect or hack.14:14
sopiX-Fade: good point. we have that for Gforge auth at the moment.14:14
sopii mean: mediawiki authenticates thru a plugin.14:15
danielwilmsit is not really a hack :) i followed a description cas points to...and the mediawiki plugin for cas seems to be quite a hack :)14:15
X-Fadedanielwilms: Well, we can always clean it up.14:15
X-FadeI think we have larger problems to address first though ;)14:16
danielwilmsthe way it works is similar...and it is not really maintained14:16
danielwilmsin the readme it was like: "and now pray that it works" :D14:16
danielwilmsand phpCAS is pretty much straight forward14:17
danielwilmsX-Fade but if you wanna have a look how it is done we can have a look later on14:18
X-Fadedanielwilms: Sure, mediawiki will not be the hard part.14:18
danielwilmsnope...this was the reason I began with it ;)14:18
danielwilmsbut back to gforge...I can use the version from garage...I guess this would make more sense14:19
danielwilmsthx for the hint sopi14:20
sopidanielwilms: sure. let me know if you need a hand with that.14:21
danielwilmssopi...I will come back to this! :)14:21
danielwilmsthen the user-management...I think this is a bit tricky part...14:22
danielwilmsI would like to abstract the information, the users enters from the application, so that any application can request the basic user-data and use its own user-management like groups and so on14:23
danielwilmsso that we would have a user interface where the user can register and update his/her data14:24
danielwilmsand the applications could 1) use directly ldap to access the data or 2) get the data by a REST endpoint14:25
danielwilmsany opinions on that??14:25
X-FadeAnd you would need to remove all account management links from every service.14:26
X-FadeAnd point them to the central one?14:26
bergiedanielwilms: the idea was that the user management UI would be in Midgard14:26
bergie...using slightly modified version of current profiles there14:27
bergieand then Midgard would sync the stuff to LDAP14:27
X-FadeOr the applications would need to be smart enough to not use a database as backend, but the ldap.14:27
danielwilmsthe idea is that the basic usermanagement would be apart of any specific component14:29
sopidanielwilms: why?14:29
danielwilmsand that every application as such would get the basic user-information from there...because it would make it much more flexible14:29
X-FadeWe would need to hack each application to get the appropriate information from ldap anyway. There is no flexible way about that ;)14:30
sopiyes, I agree with X-Fade. 14:31
danielwilmsbut this is the reason for the proposal :)14:32
X-FadeOn the other hand we would need to describe which service needs what information.14:32
bergiedanielwilms: yes... LDAP would be the "master repository", but on Midgard we already have the editing interface for the data, and probably best opportunities to adapt it to whatever will be needed14:33
X-FadeDo we keep local accounts in the service?14:33
danielwilmsas we have to find a way to get the user-information of a central place i thought this might be the "cleanest" solution and it would make it easier to adopt other services later on to this14:33
X-Fadedanielwilms: You are talking about a simple web form on top of the ldap server.14:33
X-Fadedanielwilms: That can be implemented anywhere?14:34
bergieagain, why do that when we already have quite a rich editing UI for editing person info14:34
bergieinfo that we only need to send to LDAP14:34
danielwilmsX-Fade: it could be implemented everywhere, and yes this would keep the local accounts14:35
X-Fadedanielwilms: How would a local account change when I change anything in ldap?14:35
X-Fadedanielwilms: How does that update end up in the local account?14:35
bergieX-Fade: the "local accounts" must sync from LDAP every now and then14:36
danielwilmsthe username would be unique and stay...the local account only uses the username to create groups or whatever is needed...and if data would be needed, which is entered by the user itself it will be requested from the user management system14:37
X-Fadedanielwilms: Yeah, but that means we need a sync mechanism.14:37
X-Fadedanielwilms: If I change my email in ldap, it should change in mediawiki too14:37
X-FadeAnd it should happen instantly.14:38
X-FadeOtherwise the user browses to his user account in mediawiki and sees the old value still there.14:38
bergieX-Fade: instant is not realistic with the different systems we use, but if we use signals to trigger synchronization, it can be almost instant14:38
X-FadeYou know that is going to give us a lot of bug reports ;)14:38
danielwilmsthis could be done if we would use a service for that14:38
bergiealso, if the account editing UI says "this will take a while", then the user knows what to expect14:38
X-Fadebergie: Yeah, but we see this problem with garage->midgard syncing for instance.14:39
danielwilmsbut the alternative would be to use one ldap for everything and the applications use it directly14:39
X-FadePeople can't start doing things instantly, they have to wait.14:39
bergieX-Fade: garage->midgard is quite silly ATM because it syncs *every account* on every run14:39
bergieif Midgard is the UI we can do this with more granularity14:39
bergiedanielwilms: I don't think making all apps use LDAP directly is realistic14:40
X-Fadebergie: Yeah, but we now have to see that we sync between: garage, midgard,mediawiki, bugzilla and talk without too much delay.14:40
danielwilmsbergie: that was my point14:40
bergieX-Fade: yes, but with Midgard we'd at least know (and get D-Bus signal of) which user was being edited14:41
X-FadePeople don't care about our problems. They see the same layout, so it _has_ to be the same ;)14:41
bergiemaking triggering the syncs easier14:41
danielwilmsbut we could implement it like cas14:41
danielwilmsand the logout14:41
X-Fadebergie: true. we could us dbus to signal an update.14:41
danielwilmsif a user logs out it sends a ping to the services14:41
X-Fadedanielwilms: interesting14:42
danielwilmsthats it...only an endpoint for it would be needed14:42
bergieX-Fade: yep, that is the *other* reason why Midgard would be good editing UI for user info... the other is that there we can control the user experience better than elsewhere14:42
X-Fadedanielwilms: But then we could fire an update ping too? :)14:42
bergiedanielwilms: exactly that kind of ping/signal is what I'm proposing here14:42
danielwilmsso that would be fine with me :)) the only thing we would need to decide if we would do that in midgard or apart from it as a UI for the ldap14:44
bergiedanielwilms: yep. but with Midgard we already have it :-)14:44
bergiethe d-bus signal can easily be "aggregated" to some web service calls that initiate the sync in various systems14:45
X-FadeAnd what would we do with things like this page:
danielwilmsyep...thought about that as well as a simple web service set up14:45
X-FadeAre we allowing people to change their account settings in local service forms?14:46
danielwilmsbergie: but at the moment we are using garage for the user accounts, right??14:46
bergiedanielwilms: for registration, yes14:46
bergiedanielwilms: but after that they may be edited in Midgard14:46 Midgard has more user data than Garage does (accounts in external sites etc)14:46
bergiewhat I propose is that we'd move also registration to Midgard (the component supports that but it is now disabled)14:47
bergie...and make Midgard sync to LDAP + ping other services to sync from LDAP14:47
sopiimho we have to agree on the exact set of user data that is stored in LDAP. all other application specific preferences could be still managed by the applications itself.14:48
danielwilmsbergie: hmmm...havent thought about that but at the moment I don't find any reason against this :)14:48
X-FadeCan blobs be stored in ldap too?14:49
bergiedanielwilms: great, then we can focus on the practicalities :-)14:49
sopiX-Fade had a question about editing certain data in apps.14:49
X-FadeThinking of avatars?14:49
bergieX-Fade: we could just provide standardized avatar URL with a fallback out of Midgard14:49
bergieyou know, or something like that14:50
danielwilmsinitially I thought that we have like all the data, which the user actively enters in a common interface to keep it as an abstraction of the rest14:50
bergiewhich would provide our fallback image if user hasn't posted avatar14:50
X-Fadeyeah, but services like talk would need an avatar too.14:50
bergiedanielwilms: which would also have the advantage that user would need to edit his info in only one place14:50
bergieX-Fade: yes, but they could just link to that URL?14:50
X-FadeSo yeah, we can do it by just linking to a default one .14:51
danielwilmsbergie...yes...this was the thought behind it14:51
bergie+1 from me14:51
bergie*if* we can disable the editing UIs in the other systems, as probably they won't sync back to LDAP14:51 least in the wiki you can14:52
bergieand since our garage is a fork anyway, probably there too ;-)14:52
X-FadeBut you would need to disable only certain things.14:52
sopibergie: yes, but then we need to disable other "user preference" editing as well.14:53
X-FadeFOr wiki, you should not be allowed to change your email. But all other options should still work.14:53
bergiesopi: the prefs could also come from Midgard->LDAP->Garage14:53
sopimight be troublesome to migrate the other "prefs" to LDAP or elsewhere.14:53
X-FadeE-mail me when a page I'm watching is changed14:53
X-FadeE-mail me when my user talk page is changed14:53
X-FadeE-mail me also for minor edits of pages14:53
X-FadeSend me copies of emails I send to other users14:53
X-FadeThese sort of options should really stay local.14:54
danielwilmsX-Fade but this is the point that you could do it in a central place14:54
X-Fadegood luck programming storing these values in ldap.14:54
X-FadeIf you want to touch that, then you are really hacking in the core of the service.14:54
X-Fadewhich is a lot of work :)14:55
danielwilmsnooo..the only information you need for that is the email address...and this you could still store locally14:55
sopiX-Fade: i have to second your opinion. Such change in garage would make the gap even bigger between the upstream GForge.14:55
danielwilmswith a ping which tells when the user updates it14:55
X-Fadedanielwilms: I think just disabling some fields is a lot easier..14:56
-!- tekojo [] has left #maemo-meeting []14:56
danielwilmsX-Fade: ok...but this would need a closer look how it's implemented14:57
X-Fadedanielwilms: There is no way around that.14:57
X-Fadedanielwilms: Either you hack forms or you hack the preferences storage engine.14:57
danielwilmsX-Fade: you are right14:58
danielwilmsso...lets put the things together14:58
danielwilmswhat we need is a central place to edit/register and so on14:59
-!- JimiDini_iphone [] has joined #maemo-meeting14:59
danielwilmsthis should contain a service, which handles the updates for the applications14:59
danielwilmsor better, which pings the others15:00
danielwilmsthe single applications would contain still locally the data15:00
danielwilmsand this service would be realized on top of midgard15:01
X-FadeAnother subject to talk about is account merging.15:03
X-FadeYou can basically have 3 accounts now. garage/midgard, bugzilla and talk.15:03
danielwilmshas bugzilla somehow a "user history"15:04
X-Fadedanielwilms: In what sense?15:04
danielwilmswhat I mean is would it hurt to get a new account?15:04
sopiyes it would.15:04
X-FadeYes, that would hurt.15:04
X-FadeBut username=email15:05
sopiwe got to keep a "bugzilla ID" in the new system, otherwise the bugzilla account merge will be nightmare.15:05
JaffaAll three have email addrs, but garage/midgard is the only one which supports multiple addresses15:05
X-FadeJaffa: Yeah, I meant that you can't use a username in bugzilla as it uses your email address.15:06
X-FadeWe could do an automated run for every account where username and email match, and the remaining people to login to other services through a central form.15:07
X-FadeSo we can merge them that way.15:07
danielwilmsyep...this would be an option...i only hope that talk is not too different15:08
X-Fade* ask remaining people to15:08
danielwilmsas it was separated all the time15:08
X-Fadedanielwilms: username and email are available there.15:08
danielwilmsand I dont know how many matches you can expect there15:08
X-FadeBut there can be username overlap between the 2.15:08
Jaffausernames don't necessarily match ;-)15:08
* Jaffa puts in a feature request for merging 'aflegg' and 'jaffa' at the same time ;-)15:09
danielwilmsi guess this is the big problem with talk15:09
X-FadeJaffa: People with multiple accounts at the same service should be punished.15:09
X-FadeWell, we do that by just throwing away all others ;)15:10
JaffaX-Fade: I've been punished - I'm not getting any of my deserved karma for `aflegg' and have lost his `Oct 2005' join date ;-p15:10
danielwilmsX-Fade they already complained about a new design15:10
Jaffatalk may still need the account for db integrity; but dunno if it has a "locked" feature to prevent log in15:10
X-FadeJaffa: Just kidding.15:10
X-FadeBut yeah, there are multiple problems in a merge. And a 3way merge doesn't make it easier.15:11
X-FadeAnd then there is another big problem. Login once, be logged in everywhere.15:12
JimiDini_iphoneIdeally, we'll need to take one of the services  as basis and let people merge others manually if case is not trivial15:12
sopi..and that should be handled upon the 1st login once the new system is in place..15:13
sopieach application should force this, in a way.15:13
JaffaJimiDini_iphone: agreed. But the UI should probably be better than the current midgard/talk account integration field15:13
sopii see no other ways for automatically merge accounts.15:13
X-FadeCreating a form with 3 login boxes is not that bad.15:14
X-FadeAs long as we only present it once.15:14
JimiDini_iphonesopi: Sounds reasonable15:14
JaffaX-Fade: good idea15:14
X-FadeBut this would mean that you can only have one account per service ;)15:15
JaffaX-Fade: I'm resigned to being odd ;-)15:15
X-FadeJaffa: Well, we might be able to do a search/replace in our database to fix your problem. But yeah :)15:15
sopiX-Fade: wait a sec. can you pls explain step-by-step how the "3 login boxes" idea would work for user "ferenc" for example?15:15
sopilet's say i want to update my bugs in bugzilla.15:16
sopiwhat will i do?15:16
X-Fadesopi: Login box for garge, bugzilla, talk.15:16
sopiso i take the bugzilla box, fill in, and submit?15:16
X-FadeEnter all your usernames and passwords there. Click submit.15:16
sopiah, i see.15:16
X-FadeOn the server read back the responses from all services.15:16
sopiin that case the system will know about my all credentials.15:16
X-FadeAnd request userids.15:16
X-FadeOnce, and we don;t have to store them.15:17
danielwilmsX-Fade sounds like a really good idea15:17
sopiyes, i see. would work.15:17
X-FadeAnd we are a trusted party for all those services anyway.15:17
-!- JimiDini_iphone [] has quit ["Get Colloquy for iPhone!"]15:17
X-FadeIt is not like we ask for your google account etc.15:17
X-FadeIt is just a way for the user to prove he is who he says he is.15:18
X-FadeAnd to look up the correct accounts to match/merge15:18
sopiok. what if an authentication fails, let's say i mistyped by talk password?15:18
danielwilmsand when we do it in this way we dont have to think right now, how cas authenticates the user15:18
X-FadeWould make it easy to merge user foo in garage with bar in talk etc.15:19
X-Fadesopi: Then we would return with an error message? :)15:19
-!- JimiDini_iphone [] has joined #maemo-meeting15:19
danielwilmsok...lets do it in this way15:20
X-Fadedanielwilms: And how to generate cookies for each service.15:20
X-Fadedanielwilms: So you are automatically logged in everywhere..15:20
-!- JimiDini_iphone_ [n=JimiDini@] has joined #maemo-meeting15:20
X-FadeWhich is another big problem, I think.15:20
danielwilmsX-Fade wait15:20
danielwilmsthats not right15:20
danielwilmsI was wrong15:20
* X-Fade is confused now ;)15:21
danielwilmsyou are only automatically logged out, but not logged in...but you dont have to provide your credentials15:21
danielwilmsat least you could implement it in this way15:21
X-Fadedanielwilms: But if I click around in the main navigation, I jump between services.15:22
X-FadeIt would make sense to stay logged in when going from m.o to talk etc.15:22
danielwilmsthis can be decided by the applications itself15:23
X-FadeWe have to do that?15:23
danielwilmsdepends on the implementation15:23
sopibut that would be the point of SSO, no?15:23
X-FadeA user should see everything as one website.15:24
X-FadeSo only needing to login once.15:24
danielwilmsyep...but when you want to have the control for the end-user where to login you could add a login link -> check the cookie -> and being logged in15:24
X-FadeEvery service uses a different cookie.15:25
X-FadeSo that is not going to work.15:25
X-Fade(on diffent hosts too)15:25
X-FadeNotice we have a hack for this problem for garage and when you login to maemo.org15:26
X-FadeWe post the login to garage too, so you are automatically logged in there too.15:26
X-FadeThis is an ugly way to work around that problem.15:27
danielwilmsit would...when you call the can redirect to cas -> if you are looged in cas sends a ticket to the service -> the service validates it and está15:27
danielwilmsotherwise you see the login page of cas and give you credentials15:27
X-FadeOk, well that would work.15:27
danielwilmsand if you want the control you put a link instead of redirecting directly 15:28
X-FadeIf the cas service for each host takes care of that, it is fine by me :)15:29
danielwilmsit does15:29
X-FadeGreat, problem solved! :)15:30
X-FadeSo only authentication implementation for every service and account merge then?15:30
danielwilmsand the last issue i can think of right now is who does what :)15:30
danielwilmsi can take over gforge and make the wiki and cas nicer15:31
danielwilmscould one of you guys have a look into midgard??15:31
X-Fadedanielwilms: JimiDini_iphone_ and bergie will probably do that part.15:32
sopihow about specifying 1st which data to store by CAS and make editable thru Midgard?15:32
danielwilmscas does not store anything15:32
sopiok, LDAP then. sorry.15:32
X-Fadesopi: Good idea.15:32
X-FadeWe might want to add that to the wiki.15:33
danielwilmsfirst we can us ldap for the authentication15:33
sopiX-Fade: ok, who will do the draft?15:33
X-FadeFor every service list what informtion is needed for the account.15:33
sopiX-Fade: ok.15:33
danielwilmsthat sonds good15:33
danielwilmsI will extend the wiki page and you can put more information there15:34
X-FadeI can do a quick draft.15:34
danielwilmsX-Fade ok15:34
danielwilmsor like this15:34
bergieBTW, sorry for idling... there is this other meeting happening in RL :-)
X-Fadedanielwilms: Btw, you can use namespaces under Task:Single_sign-on.15:35
danielwilmsbergie no problem :)15:35
X-Fadedanielwilms: Like ->
danielwilmsahhh...ok :) thx for the hint15:36
X-FadeThat way we keep the info in one place.15:36
danielwilmsyep...definitely better15:37
X-FadeAnd you get nice breadcrumbs.15:37
danielwilmssorry for the mess ;)15:37
danielwilmsthen I will put the status there and add the results from today15:37
danielwilmsand X-Fade you make the draft?15:38
X-FadeI will collect information about what info is needed for every service.15:38
X-FadeAnd put that in the page.15:38
-!- JimiDini_iphone_ [n=JimiDini@] has quit [Read error: 110 (Connection timed out)]15:38
sopiX-Fade: great!15:38
sopihow about deadlines?15:39
danielwilmsgood point15:39
sopiwhat are we supposed to achieve in the May sprint?15:39
danielwilmsI'm on vaccations for 3 weeks from friday on15:39
sopii guess it was to setup the SSO testing environment.15:40
sopisee: is we can start integrating15:40
sopidanielwilms: could you please update the sprint page?15:40
danielwilmssopi: will do that15:41
danielwilmsdo you think guys that we can reach a testable version beginning/mid august15:41
-!- JimiDini_iphone [] has quit [Read error: 113 (No route to host)]15:42
sopii think it is early to say, but let's see what we put to the June and July sprints.15:42
danielwilmsok...I will update my task and the rest you can decide in the next sprint meeting15:43
danielwilmsi'm not in then15:43
sopidanielwilms: did you get account requests for the test environment?15:44
danielwilmsyep...will add it afterwards15:44
danielwilmssopi...i will send you a mail15:44 there anything else to discuss15:45
danielwilmsperhaps we could have one of these sessions in a couple of weeks again15:45
danielwilmsi think it was really productive15:45
sopiyes, for the next session we should definitely know the application specific data and availability of people.15:46
danielwilmsyep...sounds good15:46
danielwilmsok...then...thank you all for discussing here15:47
danielwilmsthe picture got clearer :)15:47
sopidanielwilms: thanks to you for the good 1st proposal and the test setup!15:47
danielwilmsthx...and i like the task ;)15:48
danielwilmsbye bye all!15:48
sopisee you! 15:48

Generated by 2.7 by Marius Gedminas - find it at!