[Mailman-Developers] Architecture for extra profile info
Stephen J. Turnbull
stephen at xemacs.org
Fri Apr 19 03:22:38 CEST 2013
Florian Fuchs writes:
> If the instance of the user store does not act as provider, we would either:
>
> 1) effectively require every api user to have an account with some
> other oauth provider.
Most people do.
Sites that care can bring up their own provider. AFAIK that's not
terribly hard, and I doubt that Mailman can make it much easier. But
we shouldn't encourage it. Requiring a specific provider sucks if not
necessary for security reasons; users just end up managing yet another
password and get no benefit. Adding a new provider, even if not
required, is likely to cause the same problem if the user later signs
up with a well-known provider.
The point of OAuth for Mailman is that it's nearly formally equivalent
to the traditional 3-part handshake (request subscription, receive
token by mail to subscribed address, return token thus proving you are
owner of the address), since most OAuth providers are email providers.
Perfect fit.
> or
>
> 2) use some other authentication method.
What's wrong with HTTPS + Basic Auth?
> Anyway, we're talking about something that is absolutely not needed
> for what we want to achieve *right now*, which is a profile data store
> that Postorius/HK/etc can access from localhost (or maybe from an
> internal network. Or IP-restricted through SSL. Or... ?).
OAuth (or Persona, etc) access for subscribers (to Postorius and
HyperKitty) using subscribers' existing OAuth provider is not
*absolutely* needed, but would be a very big plus. Users hate
managing passwords for resources they don't care much about security.
Once we've got that, I would think it's a relatively small step (in
terms of code) to implementing for inter-component communications.
The security audit required might be quite a bit of work, so we might
not recommend deploying the feature in "high" security contexts.
More information about the Mailman-Developers
mailing list