Re: [Mailman-Developers] Re: Future of pipermail?
On Tue, 21 Nov 2000 23:59:47 -0800 Chuq Von Rospach chuqui@plaidworks.com wrote:
At 2:26 AM -0500 11/22/00, Bill Bumgarner wrote:
Anything that is *using* Mailman as just-another-moving-part-among-many faces the memebership management problem and it is nasty,nasty,nasty.
If we end up doing the authentication widget, I want it to ship with a set of modules and/or interfaces. That would include one that does personal home pages, surveys, an interface to mailman, an interface to a web forum, an LDAP interface of some sort for external directory lookup and authentication purposes, and a few other toys.
I have slight allergic reactions here. Yes, I agree that a generic modular authentication model would be extremely useful (and I'd kill for a sufficiently flexible one), and it would be good if Mailman were able to plug into such a thing were it to be available on the local system, I don't see this as a Mailman specific problem, or one that should really be considered part of or rolled into the Mailman design process outside of "we should be able to integrate with one of those if its available, otherwise we punt to our LCD implementation".
With it and a few key tools, you can easily do 90% of Yahoo, minus the big muther sets of data, but when it's done, you're very close to a yahoo portal with clubs, IRC, egroups and some other tools all rolled into a single cohesive beast -- and it'll scale, and it will be extensible through a standard interface.
Which, while a nice problem, is not the problem I belive Mailman is trying to solve. Mailman should of course play nicely with such solutions (yes, plural), but I see considerable loss to be realised if we tie it to a specific implementation or model (eg Zope), and abstracting at just the API level (as versus at the process level) is going to tend to lead you in that direction.
(and what I find scary is I don't see *anything* that is technically a huge stretch. it's all engineering, not magic...
Too true (written as one who has just re-engineered his own auth models). There's no rocket science here, just the normal stack of security model and privacy concerns.
-- J C Lawrence claw@kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--
At 12:11 PM -0800 11/22/00, J C Lawrence wrote:
I have slight allergic reactions here. Yes, I agree that a generic modular authentication model would be extremely useful (and I'd kill for a sufficiently flexible one), and it would be good if Mailman were able to plug into such a thing were it to be available on the local system, I don't see this as a Mailman specific problem, or one that should really be considered part of or rolled into the Mailman design process outside of "we should be able to integrate with one of those if its available, otherwise we punt to our LCD implementation".
that's why I propose this as a separate project -- and why the first thing we'd need to do is define the API, then port the existing subscription system to the API. The end result would be that if you want to use the existing system, you would, but the hooks would be there to move to a more extensive system. I don't for a minute think we want that more extensive system to be the default for mailman, not for any significant amount of time, if ever (any more than I think mailman ought to require Zope, ought to require external templating modules, ought to require...)
So from the point of view of Mailman, the work would be to define and architect the API and get the existing system working with it -- and then work on an external project that'd interface to that API, not replace the existing system.
Which, while a nice problem, is not the problem I belive Mailman is trying to solve.
yup. But it's part of this larger convergence and integration problem. The integration tools need to be created, but I'm not proposing they be mandatory.
Too true (written as one who has just re-engineered his own auth models). There's no rocket science here, just the normal stack of security model and privacy concerns.
ah, who cares about security and privacy, anyway?
But to be honest -- if we can build a single, GOOD authentication widget and get those issues right, doesn't that make it nicer for everyone else, since they can simply write to use the widge and not reinvent the wheel endlessly?
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
The vet said it was behavioral, but I prefer to think of it as genetic. It cuts down on the liability -- Get Fuzzy
How about PAM-- pluggable authentication modules? It seems to have become relatively standard on LInux and BSD and provides a flexible and portable API that provides for versatile plug-n-play authentication across platforms.
I recently used it with Apache and ProFTPD to easily configure both to use the same user/passwd database-- and neither to use the systems existing user/pass system.
PAM modules exist for berkeley DB and MySQL, among various random standard authentication procedures such as Kerberos and /etc/passwd.
It would not be hard to provide a module that makes the system accessible from Python and the applicability would range a lot further than Mailman [make it immediately attractive to others].
(It may be the case that a PAM python module already exists? Haven't looked...)
Even if the implementation is not appropriate, the architecture is certainly interesting and will likely contain ideas that are pertinent to building such an authentication system as Chuq described.
b.bum
participants (3)
-
Bill Bumgarner -
Chuq Von Rospach -
J C Lawrence