[Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Stephen J. Turnbull <stephen at xemacs.org>:
> Florian Fuchs writes:
>
>  > 5) It should implement an oAuth provider.
>
> I don't see this.  Mailman is an auth consumer.  The only people
> Mailman can provide auth for are the site admins.  Everybody else is
> more or less untrustworthy.
>
> I can see that there are applications where it would be useful to have
> an auth provider bundled with Mailman, but I think implementing it is
> somebody else's job.
>
>  > This could be used for API authenticaion and to log into
>  > Postorius/Hyperkitty
>
> I think generic auth provider is overkill for these purposes, and a
> trap for anybody who thinks we know enough about crypto/security to do
> this stuff well.

I agree it's probably not easy. And, yes, maybe we need someone to
help us with that.

But maybe we can take a moment to think about the usefulness of such a
feature and the possibilities this might open up, rather than
dismissing the use of a certain technology right off the bat. If we're
unsure we can implement this in a secure way, we can still say no to
this. Also, who says such a feature would be enabled by default? We
can add it as an "experts only" thing and leave it up to the admins to
make sure they use it in a secure environment.

I remember several discussions during PyCon(s) and on IRC where
scenarios of different mailman instances talking to each other came
up. Of course that doesn't mean implementing  a generic oAuth provider
is the only answer to this. If there are better and easier solutions,
fine.

Luckily going beyond localhost isn't something we need for the
prototype that Terri suggested to be built for GSoC.

Florian