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. _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
