mdke at ubuntu.com
Fri Aug 11 10:45:21 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
* Jeff Waugh:
> <quote who="Matthew East">
>> At the moment it seems to me that there are too many community websites,
>> ultimately I'd like to see the Fridge become the main base for them all,
>> gaining some extra sections with separate feeds, and including:
> Planet is kind of a special case though, given the content (personal as well
> as project, plus the content will shift faster and faster as more people are
> added to it) and expectations (every project has a Planet). Perhaps you
> could add a Planet Ubuntu sidebar to The Fridge? Troublesome, because it's
> already sidebar heavy; it might be that clear (more exciting?) linking would
> solve this part of the problem. :-)
I don't really see Planet as a special case myself. I accept that most
projects have a planet, and I wouldn't dream of changing that, but I do
think that it would work equally well as part of the Fridge. Obviously,
the url would still have to do the right thing.
Anyhow, your idea of adding a sidebar to the Fridge is definitely a good
one. Right now the Fridge frontpage is really crowded and not much use
is made of subpages or categories in how it is presented. We could
change that, and allow more room for structuring different types of
articles. I'm not much of a designer so I can't really begin to think
how this might be done effectively.
We should probably set up a bzr repo where people can get the source of
the Fridge to play around with and submit patches.
> (Oh, also, I never made it easy to find out that ITP has a feed - you can
> only see it on the ITP category page after you click on 'more'. That would
> be a nice thing to fix. Some websites have a 'feeds' page, which lists all
> the feeds and formats available - perhaps that'd be useful for The Fridge?)
+1. I'll add to the list of stuff to do.
(from another post)
> * Instead of doing a web form for submitting news, the 'contribute' pages
> (which only admins can see atm) should be made public - but this will
> only really work if the Launchpad authentication stuff is sorted out, or
> if the Drupal anonymous posting UI is fixed (atm you can't say who you
> are or anything).
Ok, I had a chat with a few LP developers today about the possibility of
sorting out LP authentication. Unfortunately, it looks like it is going
to be impossible at present.
Below is the log of the conversation
09:56:59 < mdke> spiv: we've been mooting trying to get launchpad auth
on the fridge (which runs drupal). Is the launchpad side of that quite
straightforward now, or is there something private that needs to be done?
09:58:54 < spiv> mdke: the launchpad side of that is the same as always;
there's an xml-rpc interface (accessible only from inside the data
centre) that can be called to authenticate users. It's what the wikis use.
09:59:34 < spiv> We'll perhaps support something like OpenID eventually,
but for now that's what we have.
09:59:49 < jamesh> should be okay for use by fridge
09:59:55 < jamesh> provided drupal can use it
10:00:06 < mdke> spiv: well, I presume that the fridge runs inside the
DC too. However, it would require an employee to do the work on that?
10:00:06 < spiv> So it depends on how hackable drupal is to authenticate
against an XML-RPC service rather than its normal database.
10:00:44 < spiv> mdke: the interface to code to isn't sensitive, so we
could easily give the specs for what needs to be done to a non-employee
10:00:59 < spiv> (the interface isn't complicated, either)
10:01:01 < mdke> right. That sounds good
10:01:13 < mdke> Ok, I'll look around for someone interested in having a
hack at that
10:01:33 < mdke> thanks
10:02:00 < elmo> for the record: the fridge isn't run inside the DC (as
far as the auth server goes) - it's crackful PHP with an insanely bad
security history, so it's in a DMZ and appears outside the DC to the
10:02:22 < spiv> elmo: Ah, hmm.
10:02:26 < mdke> what are the consequences of that for speaking to the
10:02:42 < mdke> bit more tricky, or downright impossible?
10:03:07 < elmo> don't know, not my call - probably need to talk to SteveA
10:03:26 < mdke> ok, thanks
10:03:27 < spiv> mdke: well, basically, the problem is we have to trust
the fridge to be secure, because if someone can hack it then launchpad
accounts, and thus security-sensitive bugs, package uploads, all sorts
of critical stuff is potentially compromised.
10:03:33 < SteveA> hello elmo. my xchat window flashed in your honour.
10:04:23 < spiv> mdke: This is why OpenID would be nice.
10:04:36 < mdke> ah
10:04:38 < mdke> bugger
10:04:52 < mdke> spiv: ok, so downright impossible for now, maybe
possible in the future?
10:05:05 < jamesh> mdke: sounds like it, yeah.
10:05:22 < mdke> gotcha
10:05:40 < mdke> any idea of timing?
10:05:40 < spiv> mdke: It's probably not feasible for any service that
isn't 100% trustable and 100% administered by Canonical.
10:05:42 < jamesh> with OpenID, the passwords would never be sent to the
10:05:59 < jamesh> and if the person is already logged in to Launchpad,
they wouldn't need to reenter their password
10:06:28 < jamesh> just click yes to a form on Launchpad asking them if
they want to authenticate themselves to fridge.ubuntu.com
10:06:42 < mdke> yeah, something like that would work, because we have a
fridge editor group on LP
10:06:55 < Kinnison> As a user of LP myself, I vote OpenID++ Bug 1169 FTW!
10:06:56 < Ubugtu> Malone bug 1169 in launchpad "Launchpad should
support OpenID" [Medium,Confirmed] http://launchpad.net/bugs/1169
10:07:38 * mdke subscribes
10:09:43 < mdke> I suppose the alternative would be to redo the fridge
using different software
10:15:53 < stub> Not really - the same problems apply. If a system isn't
considered trusted enough to run in our dmz, it isn't trusted enough to
talk to the existing authserver. We just need to bite the bullet and
implement open-id instead of putting it off as a low priority, as use
cases for it popup every month or so.
10:16:18 < mdke> stub: that would be good. I kind of meant "different
software that can be trusted to run in the lan"
10:16:34 < mdke> but, obviously, implementing this open-id thing sounds
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v188.8.131.52 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the sounder