Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > In my opinion, the normal use case doesn't even need the generality
 > of "domains".

I'm not going to argue with you.  Let's go get some code written.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Steve,

In my opinion, the normal use case doesn't even need the generality of 
"domains".
Now that we are talking about only the few percent remaining installations, I 
have to seriously ask how many of those will not be handled by "power users"?

My concern is that, in your effort to "protect" the less sophisticated, you are 
excluding some very few, but extremely "powerful" users.   I share the goal of 
"world domination". I don't want to exclude anyone if we can avoid it.

Richard

On Apr 29, 2013, at 11:57 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> There are two aspects of using a "generic tree". The first is some
>> customization of the tree to fit the installation's delegation
>> model. Here, I would suggest that "sample base installations"
> 
> Once again, you're making an argument based on theory that nobody
> disagrees with, certainly not me, and not even attempting to address
> my request for use cases.
> 
> We're not making progress.  Let's just agree to disagree, and accept
> that there's a rather high probability that we can't work together.
> In commenting, I'll play the loyal opposition, and we can hope other
> developers will keep me honest.
> 
> Regards,
> Steve
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > There are two aspects of using a "generic tree". The first is some
 > customization of the tree to fit the installation's delegation
 > model. Here, I would suggest that "sample base installations"

Once again, you're making an argument based on theory that nobody
disagrees with, certainly not me, and not even attempting to address
my request for use cases.

We're not making progress.  Let's just agree to disagree, and accept
that there's a rather high probability that we can't work together.
In commenting, I'll play the loyal opposition, and we can hope other
developers will keep me honest.

Regards,
Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> So you have at least three layers. Do you really think that it is
>> more difficult to implement a general recursive tree than it is to
>> implement those layers?
> 
> No.  What I think is difficult is to implement a general recursive tree
> *and* an API for expressing properties of nodes that make them
> equivalent to the specialized hierarchy *and* a usable interface for
> specifying and managing those properties by non-programmer users
> (including admins).

There are two aspects of using a "generic tree". The first is some 
customization of the tree to fit the installation's delegation model. Here, I 
would suggest that "sample base installations" be made available so that the 
installation of a workable tree structure is nothing more than copying a 
supplied configuration base. "Power users" should be able to understand the 
structure and customize it to fit their particular situation.

The other aspect is "how to display" them, particularly because of inheritance 
within the tree.
I don't see "display the tree of lists" as a problem. There are a number of 
reasonable implementations available for adoption.
IMHO, the key to displaying particular the individual parameters is to use a 
consistent presentation style and "focusing" on a particular node in the tree.

That style can be driven by css using class selectors on each individual item.

As for "domain" vs "list", I view them as just two versions of the same thing 
-- namely a node with a dictionary of properties.

By limiting access permission, even though they are present (in a virtual 
sense), and by modeling each list as having all of the properties of itself and 
the MM-domain which contains it, we can use one mechanism to handle the both 
the domain administrator and the list administrator. The only distinction is 
the point of focus.

>> Another case for generality is permissions. I don't propose to know
>> all of the parameters that will be associated with a list.
> 
> You're pushing on a string here.  I'm not opposed to generality in
> general. ;-)  What's more important to me than whether you know all of
> the parameters that will be associated with a list :-) is that I'm
> pretty sure I don't want Postorius's views to know.

Postorius need only know about those items that should be viewed or modified 
once the system is running.

>  That leads to ugly and unmaintainable code.

Or you can treat them in a generic manner, even make them "discoverable", and 
attach the appropriate ACL information.  :)
This is, in effect, the approach that django takes with its "Model" and "Admin" 
constructs.

One reason that I advocate attaching the parameters to the list-tree nodes as a 
dictionary is so that it is easy to add or delete items without having to 
change the data transfer structure.

> I also don't want users to be seeing data they don't need to see, or
> shouldn't see, and they mustn't be able to change parameters they
> shouldn't change.

Agreed. One purpose of a list hierarchy is to make it easier to specify and 
maintain these attributes.

>  These requirements can be fulfilled in a number of
> ways, including customization by extension modules.  For example,
> there could be (extensible) lists of parameters attached to each role,
> a list for each permission.
> 
> I think that's kind of fragile; better to attach an ACL to each
> permission.  (I think that's basically what you have in mind, too.)


___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > So you have at least three layers. Do you really think that it is
 > more difficult to implement a general recursive tree than it is to
 > implement those layers?

No.  What I think is difficult is to implement a general recursive tree
*and* an API for expressing properties of nodes that make them
equivalent to the specialized hierarchy *and* a usable interface for
specifying and managing those properties by non-programmer users
(including admins).

 > Another case for generality is permissions. I don't propose to know
 > all of the parameters that will be associated with a list.

You're pushing on a string here.  I'm not opposed to generality in
general. ;-)  What's more important to me than whether you know all of
the parameters that will be associated with a list :-) is that I'm
pretty sure I don't want Postorius's views to know.  That leads to
ugly and unmaintainable code.

I also don't want users to be seeing data they don't need to see, or
shouldn't see, and they mustn't be able to change parameters they
shouldn't change.  These requirements can be fulfilled in a number of
ways, including customization by extension modules.  For example,
there could be (extensible) lists of parameters attached to each role,
a list for each permission.

I think that's kind of fragile; better to attach an ACL to each
permission.  (I think that's basically what you have in mind, too.)

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 11:59 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:

> My point is that IMHO it's flexible *enough*.
> 
>> I'm advocating that we attach the roles (whatever they may be) to
>> an entire collection of lists.
> 
> I know what you're advocating, and I agree with the general theory of
> constructing for flexibility.  I just don't see a need for it.

One point that I had overlooked is that you have already acknowledged an 
additional "layer" between "domain" and "list".
So you have at least three layers. Do you really think that it is more 
difficult to implement a general recursive tree than it is to implement those 
layers?

Another case for generality is permissions. I don't propose to know all of the 
parameters that will be associated with a list. In fact, I am sure that they 
will change over time.  There has already been expressed a desire to have 
plug-in extensions (which might add some additional parameters of their own). 
However, from the view of the admin UI, all parameters share the common 
characteristic that they either can, or cannot, be altered by the . Using 
the generic abstraction that every parameter is a case of the Parameter class, 
and subclassing that to provide commonly seen variations (for example, 
"boolean") allows us implement a flexible structure that does not require 
handler recoding as the set of parameters changes.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > You seem to be missing the point that "one size fits all", or in
 > this case, one hierarchy, is not a flexible strategy.

Sorry, that's false, and there's plenty of evidence in the archives
that I've acknowledged that point.

But "flexible" is not an absolute, not even if you're discussing
female gymnasts.  My point is that IMHO it's flexible *enough*.

 > I'm advocating that we attach the roles (whatever they may be) to
 > an entire collection of lists.

I know what you're advocating, and I agree with the general theory of
constructing for flexibility.  I just don't see a need for it.

 > Actually, by establishing a flexible hierarchy, it may be possible
 > to eliminate some of the functionally similar roles. For example, a
 > "Domain Administrator" might be nothing more than a "List
 > Administrator" attached to a higher node in the tree of Lists.

Sure.  That's the main point of a generic model, sharing code to
handle cases that are similar enough to handle with the same code.

However, I don't think it's true that they're that similar.  By the
principle of subsidiarity, there are things that a List Administrator
does that a Domain Administrator normally shouldn't do (authorizing
moderators).  But there are others that both should be able to do
(clearing queues of broken messages, removing legally objectionable
messages from archives).

So to handle both attributes that are subject to subsidiarity and
those that aren't, you need as much code as in the current model,
*plus* in your model you need to make the code generic *and* provide
rules for the existing use cases.  That just doesn't sound like a
bargain to me in the absence of a few plausible *and concrete* use
cases that require more flexibility.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Steve,

Here I agree with you.

It is useful for MM to be able to accept enterprise information when it is 
available.
OAuth is a mechanism that will be useful for some enterprises.
To the general public, being able to use enterprise identification from common 
sources such as Google or Twitter, is a "friendly" way identify a user and 
allow them to log into a MM system.

Within a MM installation, OAuth could be used in a more robust distributed 
implementation. However for our purposes, much simpler schemes such as Basic or 
Digest Auth is more than adequate for the intercommunication between components 
such as "core", "postorius", a message store, etc.

Richard

On Apr 28, 2013, at 11:07 PM, "Stephen J. Turnbull"  wrote:

> Xu Wang writes:
> 
>> As oauth supported google's userinfo API, one need to present a valid
>> google's oauth access token to get access.
>> s/google/mailman/g  on above statement, it will be true too.
> 
> I disagree, in the sense that Google (as an OAuth provider) is in the
> business of *providing* enterprise workflows such as AppEngine.
> That's why they need to be an OAuth provider.  Mailman is a support
> function for workflows (enterprise or otherwise).
> 
> So it's not a "Mailman" token.  It's an  token, and the
> enterprise, not Mailman, should be the provider.  If Mailman provides,
> then we have to take responsibility for foreseeing enterprise needs.
> 
> If we go Wacky's route and make everything as generic as possible, we
> may need the power of OAuth to handle all that genericity.  (We may
> also then need another 5 years to release Mailman 3)  But if we
> stick to the current role-based authorization model with a small fixed
> set of roles, then OpenID-like workflows (whether implemented via
> OAuth protocol or otherwise) should be enough.
> 
> If a site demands more control over authentication than public OpenID
> providers can afford, then Basic Auth over HTTPS fits into the "user
> has role" authorization model as well as OpenID does.  I don't see a
> need for Mailman to provide an authentication provider, and there are
> serious downsides to the proliferation of authentication providers.
> 
> Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Xu Wang writes:

 > As oauth supported google's userinfo API, one need to present a valid
 > google's oauth access token to get access.
 > s/google/mailman/g  on above statement, it will be true too.

I disagree, in the sense that Google (as an OAuth provider) is in the
business of *providing* enterprise workflows such as AppEngine.
That's why they need to be an OAuth provider.  Mailman is a support
function for workflows (enterprise or otherwise).

So it's not a "Mailman" token.  It's an  token, and the
enterprise, not Mailman, should be the provider.  If Mailman provides,
then we have to take responsibility for foreseeing enterprise needs.

If we go Wacky's route and make everything as generic as possible, we
may need the power of OAuth to handle all that genericity.  (We may
also then need another 5 years to release Mailman 3)  But if we
stick to the current role-based authorization model with a small fixed
set of roles, then OpenID-like workflows (whether implemented via
OAuth protocol or otherwise) should be enough.

If a site demands more control over authentication than public OpenID
providers can afford, then Basic Auth over HTTPS fits into the "user
has role" authorization model as well as OpenID does.  I don't see a
need for Mailman to provide an authentication provider, and there are
serious downsides to the proliferation of authentication providers.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> The "root" of the tree covers all of the lists.  Under that top
>> node, we might create nodes for "Customer Plans", for example,
>> "Bronze", "Silver", "Gold" and "Platinum".  Each of these nodes
>> would specify some limits that applies to the level of service.
> 
> But here the limits apply to *principals*[1], not lists, AFAICS.

That is the case in my hypothetical example. However, the mechanism applies to 
any property of the lists such as a default value for some user preference.  In 
my example, the property is, perhaps, "Administrator can/cannot create a new 
list"
Equally, the content of a "Greeting Message" or the "Default Language", or any 
other property can be treated in the same manner.

> I could see this organization being usable in a case where ...

> It's not obvious to me that your way of doing things is better for
> this use-case.  If it's not plausible that it's better (I make no
> claim that it's not at this point), it fails to justify an experiment
> with a generic organization for lists.

You seem to be missing the point that "one size fits all", or in this case, one 
hierarchy, is not a flexible strategy.
By having a generic structure and allowing each installation to customize the 
hierarchy to fix their individual need, we provide a mechanism that better 
suits the needs of a larger group of installations.

>> Another right is the ability to permit the administrator to
>> associate additional persons to nodes within their portion of the
>> tree.  By doing so, that administrator "delegates" the ability to
>> perform certain operations to this added person.
> 
> This is more plausible as a use-case, since the "certain nodes" need
> not be all the nodes for that administrator.  OTOH, we already have
> "list owner" and "moderator" roles, and those *are* attached to each
> list.  It's not clear to me that we need to provide for adding
> additional roles, but I'll keep it in mind.

I'm advocating that we attach the roles (whatever they may be) to an entire 
collection of lists.
The purpose of a hierarchical structure, whether one fixed structure or a 
generic recursive one, is to provide a mechanism to
assist the "principal" in managing a number of lists that have common 
properties.

Actually, by establishing a flexible hierarchy, it may be possible to eliminate 
some of the functionally similar roles. For example, a "Domain Administrator" 
might be nothing more than a "List Administrator" attached to a higher node in 
the tree of Lists.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:
 > 
 > On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull  wrote:
 > > The rest of your post is just a reiteration of your religious
 > > belief that generic is good.
 > 
 > Call it "religion" if you wish. It is based on DECADES of
 > experience,

So are most religions, but for some reason they all have exceptions
where the Power chooses not to perform miracles.

 > many of which involved reworking existing code to
 > handle some changed conditions.

Of course you do.  Anybody with five years of experience has run into
that.  But with decades of experience, surely you've also run into
projects that never saw the light of day because the implementers
overengineered Grand Designs which didn't address user requirements.

 > Where is your design to handle the delegation of (restricted)
 > permissions to alter list settings, create new lists, add
 > moderators or administrators, etc.?

Mailman 2.1.  I've seen no real reason to suppose we need more.  What
people repeatedly request on Mailman channels (in my, eminently
fallible, recollection) is more *power* for existing administrator
roles (viewing logs), more power for the user role (searching
archives), and more intuitive UIs for both.  Barry's design for
Mailman 3 addresses those needs by making it a heck of a lot easier
to experiment with additional UIs.

An example of a use case I don't like is the "Like" buttons (or
something like that) the HyperKitty guys are putting in.  Nobody has
requested them on Mailman channels that I can recall.  But social
networks are booming, and any visit to YouTube will provide evidence
that people do use those "Like" buttons, and comment on them.  I have
no ground to stand on there.  I'm sure those buttons will be
appreciated and used by lots of subscribers.  That use case is valid,
whatever my personal feeling is.

But I've never seen (IMEFR) a request for more flexibility in
constructing an administrative organization for a Mailman site.

 > I am, at least, proposing a framework which would be able to
 > address these issues.

My point is, "Don't tell me about theoretical issues.  What use cases
are you addressing?"  If users aren't going to use your framework,
there's no point in building it.

 > This sounds as if you are using the "But you haven't actually built
 > the entire system, therefore I can dismiss anything that you
 > propose as a design concept" excuse to dismiss any ideas that are
 > "Not Invented Here"

You're not listened if that's what it sounds like to you.  I haven't
once asked you for running code.  I've asked you for examples of what
Real Users[tm] might want to run the proposed code for.

If you want to build it with your own resources, I have no problem
with that.  If you want me to help, or if you want me to support your
design to other developers (including GSoC interns), I need to know
what it's for, besides addressing issues that I do perceive in
software engineering theory, but not in Mailman practice.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

Well, it is about how a third party web application can get user's profile
data from google as oauth client, like OpenID,  it's little help on the
access control of a third party RESTful API.

As oauth supported google's userinfo API, one need to present a valid
google's oauth access token to get access.
s/google/mailman/g  on above statement, it will be true too.

If we are talking about enable OpenID or get user's profiles from google,
facebook, tweeter, etc. as an OAuth client in postorius, it should not be a
big deal because the client libs are readily available from those
providers, but it is different from claiming
mailman's api supports OAuth.


On Sun, Apr 28, 2013 at 6:47 PM, Richard Wackerbarth wrote:

> My understanding of the use of oAuth to provide "login" information from
> Google, Twitter, etc. is based on the following description provided by
> Google.
>
> Below is a trivial example of how to use Google's OAuth 2.0 endpoint to
> gain access to a Google API. It's a Python web application running on App
> Engine. The flow of the example is fairly straightforward:
>
>1. When the application loads, it shows the you a "Login" link.
>2. When you click that link, you are asked to login to Google and
>asked to release basic account information to the application (user
>consent).
>3. If you grant consent, the application receives an access token.
>4. Once it has the access token, the application presents the access
>token to the Google API that provides basic account information (
>https://www.googleapis.com/oauth2/v1/userinfo)
>5. The application renders the basic account information in a simple
>table.
>
> In particular, a user grants our server the permission to access some
> information pertaining to the user as it is stored by Google and accessed
> through their API for the purpose.
>
> Based on that information, our server grants permission to the user thus
> identified and based on authorization data stored in our system. Once we
> have identified the user, our system can use tokens such as session keys,
> or other mechanisms, to maintain the association.
>
> Richard
>
> On Apr 28, 2013, at 2:42 PM, Xu Wang  wrote:
>
> On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull  >wrote:
>
> Xu Wang writes:
>
> On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
>
> step...@xemacs.org>
>
> wrote:
>
> Xu Wang writes:
>
> The problem is how do you "confirm ownership of the subscribed
> address" when a request coming with an access token.
>
>
> You don't.  That was done when the OAuth ID was linked to the address,
> using the usual 3-step handshake (submit the association, receive an
> email containing a secret, confirm ownership by replying with the
>
> secret).
>
>
> I'm not sure what you mean by "OAuth ID".
>
>
> In the case of Mailman's use cases, it will typically be an email
> address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID
> provider.  Often, but not necessarily, it will be the subscribed address.
>
>
> OpenID is about authentication. OAuth is about authorisation.
> What are we talking about here? Support to OpenID or support to OAuth or
> both?
>
> As a resource server, the API need to validate the access token but
>
> how to validate the access token is not part of OAuth.
>
>
> This is some of the excess complexity (if you prefer, "enterprise
> readiness") in OAuth 2.0.  In Mailman usage, the resource that the
> consumer gets access to will be a user ID.  Eg, I might be "user:
> stephen; name: Stephen Turnbull; email: step...@xemacs.org;
> email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
> fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
> OpenID: stephenjturnb...@gmail.com".  So when I login via OpenID
> (which uses the OAuth v1 protocol AFAIK),
>
>
> No OpenID does not uses OAuth protocol.
>
>
> the provider (GMail) asks me
> to verify who I am by presenting my credential (most users will think
> of this as "getting the login screen"), and in turn it testifies to
> the client that I own that email at GMail, and the consumer (eg, the
> HyperKitty app) then looks it up, identifies me, logs me in as
> "stephen", and gives me a cookie (session auth token).  The
> authentication *is* the validation here.
>
>
> Mailman can't use GMail as OAuth provider to protect mailman's own resource
> as a general authorization solution.
>
> OAuth v2 envisions more complex scenarios where the client may present
>
> the same token repeatedly, or consumers might hang on to them and
> present them to the resource owner repeatedly, or even pass them on to
> other consumers.  In those cases, yes, there will need to be
> validation etc going on.  For example, the token might be a (ID, URI,
> expiration-date) tuple encrypted with the resource owner's private
> key.  Being able to decrypt and getting a syntactically correct,
> unexpired tuple would then be validation of an authorization to fetch
> that URI.  (In this particular cas

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > The "root" of the tree covers all of the lists.  Under that top
 > node, we might create nodes for "Customer Plans", for example,
 > "Bronze", "Silver", "Gold" and "Platinum".  Each of these nodes
 > would specify some limits that applies to the level of service.

But here the limits apply to *principals*[1], not lists, AFAICS.
Sure, you can record them on the lists, but you'll still have to check
the principal's ID/authorization (presumably site admins can do
anything they want, even to a list owned by a Bronze customer who
can't do it for himself.  Note how you repeatedly write "[principal]
be allowed":

 > Let us assume that the Bronze service plan allows the customer to
 > have only lists set up by the Provider staff.  That user might
 > still be allowed to set other parameters, for example, the
 > subscription policy and the"welcome message".  Under the Silver
 > Plan, a customer might be allowed to set up new lists within their
 > own email-domain.
 > 
 > In both of these cases, a subordinate node would be created under
 > the appropriate "plan" node for the list(s) of that customer.  And
 > under those nodes, we would find various individual lists.

I could see this organization being usable in a case where a customer
wants to have some Bronze-plan lists and some Gold-plan lists.
However, I could also abstract "customer" as a principal which is a
group of accounts with a common billing address.  Then accounts would
be authorized, and the customer would log in as an account-user as
appropriate, rather than log in as a customer-user.  The user
interface could provide a su-like way to switch accounts of a single
customer, and/or a sudo-like way to work with "foreign" accounts.

It's not obvious to me that your way of doing things is better for
this use-case.  If it's not plausible that it's better (I make no
claim that it's not at this point), it fails to justify an experiment
with a generic organization for lists.

 > Another right is the ability to permit the administrator to
 > associate additional persons to nodes within their portion of the
 > tree.  By doing so, that administrator "delegates" the ability to
 > perform certain operations to this added person.

This is more plausible as a use-case, since the "certain nodes" need
not be all the nodes for that administrator.  OTOH, we already have
"list owner" and "moderator" roles, and those *are* attached to each
list.  It's not clear to me that we need to provide for adding
additional roles, but I'll keep it in mind.



Footnotes: 
[1]  A generic term covering users, groups of users, accounts, and in
general "entities that can be authorized".

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

My understanding of the use of oAuth to provide "login" information from 
Google, Twitter, etc. is based on the following description provided by Google.

Below is a trivial example of how to use Google's OAuth 2.0 endpoint to gain 
access to a Google API. It's a Python web application running on App Engine. 
The flow of the example is fairly straightforward:
When the application loads, it shows the you a "Login" link.
When you click that link, you are asked to login to Google and asked to release 
basic account information to the application (user consent).
If you grant consent, the application receives an access token.
Once it has the access token, the application presents the access token to the 
Google API that provides basic account information 
(https://www.googleapis.com/oauth2/v1/userinfo)
The application renders the basic account information in a simple table.
In particular, a user grants our server the permission to access some 
information pertaining to the user as it is stored by Google and accessed 
through their API for the purpose.

Based on that information, our server grants permission to the user thus 
identified and based on authorization data stored in our system. Once we have 
identified the user, our system can use tokens such as session keys, or other 
mechanisms, to maintain the association.

Richard

On Apr 28, 2013, at 2:42 PM, Xu Wang  wrote:

> On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull 
> wrote:
> 
>> Xu Wang writes:
>>> On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
>> step...@xemacs.org>
>>> wrote:
 Xu Wang writes:
 
> The problem is how do you "confirm ownership of the subscribed
> address" when a request coming with an access token.
 
 You don't.  That was done when the OAuth ID was linked to the address,
 using the usual 3-step handshake (submit the association, receive an
 email containing a secret, confirm ownership by replying with the
>> secret).
>>> 
>>> I'm not sure what you mean by "OAuth ID".
>> 
>> In the case of Mailman's use cases, it will typically be an email
>> address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID
>> provider.  Often, but not necessarily, it will be the subscribed address.
>> 
>> 
> OpenID is about authentication. OAuth is about authorisation.
> What are we talking about here? Support to OpenID or support to OAuth or
> both?
> 
>> As a resource server, the API need to validate the access token but
>>> how to validate the access token is not part of OAuth.
>> 
>> This is some of the excess complexity (if you prefer, "enterprise
>> readiness") in OAuth 2.0.  In Mailman usage, the resource that the
>> consumer gets access to will be a user ID.  Eg, I might be "user:
>> stephen; name: Stephen Turnbull; email: step...@xemacs.org;
>> email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
>> fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
>> OpenID: stephenjturnb...@gmail.com".  So when I login via OpenID
>> (which uses the OAuth v1 protocol AFAIK),
> 
> No OpenID does not uses OAuth protocol.
> 
> 
>> the provider (GMail) asks me
>> to verify who I am by presenting my credential (most users will think
>> of this as "getting the login screen"), and in turn it testifies to
>> the client that I own that email at GMail, and the consumer (eg, the
>> HyperKitty app) then looks it up, identifies me, logs me in as
>> "stephen", and gives me a cookie (session auth token).  The
>> authentication *is* the validation here.
>> 
> 
> Mailman can't use GMail as OAuth provider to protect mailman's own resource
> as a general authorization solution.
> 
> OAuth v2 envisions more complex scenarios where the client may present
>> the same token repeatedly, or consumers might hang on to them and
>> present them to the resource owner repeatedly, or even pass them on to
>> other consumers.  In those cases, yes, there will need to be
>> validation etc going on.  For example, the token might be a (ID, URI,
>> expiration-date) tuple encrypted with the resource owner's private
>> key.  Being able to decrypt and getting a syntactically correct,
>> unexpired tuple would then be validation of an authorization to fetch
>> that URI.  (In this particular case I'm thinking of "any valid user is
>> OK".)  This does require prior coordination between the provider and
>> the resource owner on token format and exchange of keys.
>> 
>> But AFAICS Mailman's currently envisioned applications don't require
>> this complexity.
>> 
> 
> As you put it,  mailman don't have to support OAuth, but if it dose, it's
> better stick to the protocol.
> 
> 
>> Do you have any ideas for Mailman that might require something more
>> fine-grained than just "this user is logged in"?
>> 
> 
> I'm new to mailman and have a very limited knowledge about what  kind of
> "fine-grained" authorization it may need other than authentication. (read:
> Xu had no clue ...)
> 
> From the api implementation point of view, a role base aut

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull  wrote:
> The rest of your post is just a reiteration of your religious belief that 
> generic is good.

Call it "religion" if you wish. It is based on DECADES of experience, many of 
which involved reworking existing code to handle some changed conditions.

> I know the theory, but without use cases I will devote my efforts
> elsewhere, and ignore complaints that my code or my advisee's code is
> insufficiently general or that it ignores a theoretical design that
> has no code or use case to back it up.


Where is your design to handle the delegation of (restricted) permissions to 
alter list settings, create new lists, add moderators or administrators, etc.?

I am, at least, proposing a framework which would be able to address these 
issues.

This sounds as if you are using the "But you haven't actually built the entire 
system, therefore I can dismiss anything that you propose as a design concept" 
excuse to dismiss any ideas that are "Not Invented Here"
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I am thinking of "delegation" in the context of administering list properties 
and preferences.

Assume a hierarchy of lists handled by one (or more) servers that comprise a MM 
system.

Various "persons" could be assigned authority to make changes that affect lists 
within portions of the tree.
those changes might in things such as setting the default language or the 
ability to create a new list.

In the virtual hosting scenario, provides a number of possible opportunities to 
illustrate how this might be used.

The "root" of the tree covers all of the lists.
Under that top node, we might create nodes for "Customer Plans", for example, 
"Bronze", "Silver", "Gold" and "Platinum".
Each of these nodes would specify some limits that applies to the level of 
service.
Let us assume that the Bronze service plan allows the customer to have only 
lists set up by the Provider staff.
That user might still be allowed to set other parameters, for example, the 
subscription policy and the"welcome message".
Under the Silver Plan, a customer might be allowed to set up new lists within 
their own email-domain.

In both of these cases, a subordinate node would be created under the 
appropriate "plan" node for the list(s) of that customer.
And under those nodes, we would find various individual lists.

Now, within our permissions system, we would grant the customer administrator 
permissions to alter certain parts of the list parameters. In my example case, 
the right to create new lists would not be granted to the customers in the 
Bronze plan, but would be granted to those in the Silver plan.

Another right is the ability to permit the administrator to associate 
additional persons to nodes within their portion of the tree.
By doing so, that administrator "delegates" the ability to perform certain 
operations to this added person.

Note: I am not trying to present the complete set of details, only trying to 
indicate how such a framework might be utilized.

The reason that a generic mechanism has value is that the same type of 
"permissions" logic is utilized for any parameter describing the list behavior. 
Whether you are selecting the default user preference to "receive digest" or 
specifying the email address or website URL through which someone can 
"unsubscribe", except for the filtering on permissible data values, the 
mechanisms needed to handle an input form are very similar.


Richard

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> Yes, initially generating a more generic structure than the ad hoc
>> one in place (which doesn't even attempt to address delegation)
> 
> Aha!  Something that looks like a concrete use case!  But what is
> "delegation"?  I mean, "who delegates what to whom?  And why does
> Mailman need to address it?  What code needs to be written to address
> it?
> 
> The rest of your post is just a reiteration of your religious belief
> that generic is good.
> 
> I know the theory, but without use cases I will devote my efforts
> elsewhere, and ignore complaints that my code or my advisee's code is
> insufficiently general or that it ignores a theoretical design that
> has no code or use case to back it up.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Xu Wang writes:

 > No OpenID does not uses OAuth protocol.

My mistake.

Let's talk about what Mailman needs, then.  OpenID (or an equivalent
based on a more general system) is all that Mailman needs as far as I
can see.  AIUI, the resources that can be accessed or mutated, in
order of frequency of use, are

1. Moderation queues.  Moderators need access.  List owners grant
   access on the basis of identity of the moderator.

2. Subscriptions.  Subscribers and list owners need access.
   Subscribers usually own the subscribed address and have a privacy
   (no spam) right.  (In employment and education cases, subscribers
   may have restricted rights, but ID == authorization holds.)  List
   owners are delegated authority from site (or vhost) admin.  They
   may have "legal" (or "precedent") rights to the subscriber list and
   archives.  Either way, ID is authorization.

3. Lists.  List owners need access.  List owners are delegated
   authority from site (or vhost) admin.  ID is authorization.

4. Virtual hosts (vhosts).  A namespace for lists based on a domain
   name (DNS MX).  Delegated by site admins.  ID is authorization.

5. Site (collection of vhosts).  A physical system.  Delegated to site
   admin from outside.  ID is authorization.

Corner cases: (1) People with multiple roles may prefer to have to
re-login (or "su") use "higher" privilege.  "su" or "sudo" mechanisms
can address this.  (2) Delegators may wish to de-authorize
delegatees.  An ID-based authorization means some lag.  This can be
mitigated by granting authorization with short expiration, but that
has its issues too.

 > Mailman can't use GMail as OAuth provider to protect mailman's own
 > resource as a general authorization solution.

Evidently it can't use it at all, if OpenID isn't based on OAuth (and
the OAuth protocol exposed to GMail users).

 > As you put it,  mailman don't have to support OAuth, but if it dose, it's
 > better stick to the protocol.

I don't see how anything general I said doesn't stick to protocol.

*Validation* is a syntactic operation.  Contacting the resource owner
and asking "is this token one of yours?" is one way to validate.
(Traditional 3-way handshake for validating mail addresses when
subscribing is exactly this.)  But using encryption or signatures is
another way.

 > I'm new to mailman and have a very limited knowledge about what
 > kind of "fine-grained" authorization it may need other than
 > authentication. (read: Xu had no clue ...)
 > 
 > >From the api implementation point of view, a role base authorization can
 > be bundled in, which allows admin or resource owner to associate user with
 > roles and roles with endpoints/methods.

AFAICS this is all we need, see above.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Yes, initially generating a more generic structure than the ad hoc
 > one in place (which doesn't even attempt to address delegation)

Aha!  Something that looks like a concrete use case!  But what is
"delegation"?  I mean, "who delegates what to whom?  And why does
Mailman need to address it?  What code needs to be written to address
it?

The rest of your post is just a reiteration of your religious belief
that generic is good.

I know the theory, but without use cases I will devote my efforts
elsewhere, and ignore complaints that my code or my advisee's code is
insufficiently general or that it ignores a theoretical design that
has no code or use case to back it up.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull wrote:

> Xu Wang writes:
>  > On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
> step...@xemacs.org>
>  > wrote:
>  > > Xu Wang writes:
>  > >
>  > >  > The problem is how do you "confirm ownership of the subscribed
>  > >  > address" when a request coming with an access token.
>  > >
>  > > You don't.  That was done when the OAuth ID was linked to the address,
>  > > using the usual 3-step handshake (submit the association, receive an
>  > > email containing a secret, confirm ownership by replying with the
> secret).
>  >
>  > I'm not sure what you mean by "OAuth ID".
>
> In the case of Mailman's use cases, it will typically be an email
> address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID
> provider.  Often, but not necessarily, it will be the subscribed address.
>
>
OpenID is about authentication. OAuth is about authorisation.
What are we talking about here? Support to OpenID or support to OAuth or
both?

 > As a resource server, the API need to validate the access token but
>  > how to validate the access token is not part of OAuth.
>
> This is some of the excess complexity (if you prefer, "enterprise
> readiness") in OAuth 2.0.  In Mailman usage, the resource that the
> consumer gets access to will be a user ID.  Eg, I might be "user:
> stephen; name: Stephen Turnbull; email: step...@xemacs.org;
> email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
> fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
> OpenID: stephenjturnb...@gmail.com".  So when I login via OpenID
> (which uses the OAuth v1 protocol AFAIK),

No OpenID does not uses OAuth protocol.


> the provider (GMail) asks me
> to verify who I am by presenting my credential (most users will think
> of this as "getting the login screen"), and in turn it testifies to
> the client that I own that email at GMail, and the consumer (eg, the
> HyperKitty app) then looks it up, identifies me, logs me in as
> "stephen", and gives me a cookie (session auth token).  The
> authentication *is* the validation here.
>

Mailman can't use GMail as OAuth provider to protect mailman's own resource
as a general authorization solution.

OAuth v2 envisions more complex scenarios where the client may present
> the same token repeatedly, or consumers might hang on to them and
> present them to the resource owner repeatedly, or even pass them on to
> other consumers.  In those cases, yes, there will need to be
> validation etc going on.  For example, the token might be a (ID, URI,
> expiration-date) tuple encrypted with the resource owner's private
> key.  Being able to decrypt and getting a syntactically correct,
> unexpired tuple would then be validation of an authorization to fetch
> that URI.  (In this particular case I'm thinking of "any valid user is
> OK".)  This does require prior coordination between the provider and
> the resource owner on token format and exchange of keys.
>
> But AFAICS Mailman's currently envisioned applications don't require
> this complexity.
>

As you put it,  mailman don't have to support OAuth, but if it dose, it's
better stick to the protocol.


> Do you have any ideas for Mailman that might require something more
> fine-grained than just "this user is logged in"?
>

I'm new to mailman and have a very limited knowledge about what  kind of
"fine-grained" authorization it may need other than authentication. (read:
Xu had no clue ...)

>From the api implementation point of view, a role base authorization can
be bundled in, which allows admin or resource owner to associate user with
roles and roles with endpoints/methods.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 11:15 AM, Stephen J. Turnbull  
wrote:

> Richard Wackerbarth writes:
>> Note that "core" doesn't NEED the structure (of list heiarchy) to function.
> in deciding on design principles we need to evaluate simplicity, 
> practicality, etc
> from the point of view of the people involved.
Agreed.

> I think the tried and true hierarchy (site -> virtual hosts -> lists) matches 
> some a
> natural hierarchy in administrative responsibility and user understanding of 
> this corner of the Web.
That matches ONE organizational hierarchy. There is no reason that you cannot 
use a more general structure and still follow that organizational structure.

>  That makes it easier to think about requirements and write code to satisfy 
> them.
Not necessarily.


>> The structure can be imposed by having the interface agent impose
>> constraints on the members of a group of lists and mapping an
>> operation on the group into that operation on each of its members.
> 
> Yes, and we'll have to create a language to express those constraints
> and an interpreter to enforce them, *and* create objects like "site"
> == Mailman instance and "vhost" out of the abstract groups.  Costs,
> benefits, which is bigger?
> 
>> If we use a MPTT key
> 
> "Ministry of Posts, Telegraph, and Telephone"?  "mildly paranoic teletype"?

Modified Preorder Tree Traversal

> Sites and virtual hosts have attributes besides lists (websites, the 
> "mailman" list, owner and admin
> addresses, ...).  There should be objects that correspond to those concepts 
> to carry those attributes.

I think that I view it differently.  EVERY list has, for example, an "admin 
address". If there is only one list, to the user(administrator) that attribute 
belongs to the (only) list.  It is only when you have a collection of lists 
that share a common value that a hierarchy adds value. In that case, by 
defining a default value to the node representing the collection and specifying 
"inherit from parent" in all of the sub-nodes, you can, administratively 
simplify the maintenance of the value to be used in each instance.

>> The only real issue is how we would express constraints that get delegated.
>> 
>> But we need to address that issue for any structure that we establish.
> 
> True, but it's not a question of need to or not, it's a question of
> costs and benefits.  Generic code is more expensive to create and
> maintain in many cases.  I suspect it will be here, as well.

Yes, initially generating a more generic structure than the ad hoc one in place 
(which doesn't even attempt to address delegation) is a bit more expensive for 
the first few parameters. However, in the log run I suspect that it won't be 
more expensive. Creating a single, reusable mechanism for the specification of 
delegation of authority will actually produce an easier-to-maintain scheme. 
And, ad hoc approaches are notorious for becoming unmaintainable.

>  Without use cases for the generality, it's hard to see the benefits.  When 
> do you expect the generality to be of use?
> 
>> Virtual hosting is the primary example of the need for a
>> hierarchical administrative structure. However, it can also be
>> useful in corporate structures where the email address space might
>> be partitioned in a quite different manner.

There is no need to make a distinction between the levels in your list 
hierarchy tree.
Treating each level as a specific case of a generic structure allows reuse of a 
common code base.

>> From a design perspective, the "core" message handler should be
>> distinct from the configuration administrator.
>> 
>> Message handling uses the current value of various configuration
>> parameters. It need not, and should not be concerned with the
>> mechanics related to the setting or modification of those
>> parameters.
>> 
>> Since these parameters seldom change, an effective caching
>> mechanism would address access performance issues.
> 
> I have no clue what you're trying to express here.

This is addressing the modularity of the system, separating functionality and 
utilizing particular views of the stored data rather than dictating how the 
data is stored and manipulated.

>  I don't see any performance issues, except that programmers whose brains 
> have exploded
> from cognitive overload tend not to produce double-digit KLOC/hour.
> My concern is entirely whether the design you propose simplifies the
> job of meeting the common requirement of creating a (1 to 3 level)
> hierarchical organization of lists (the third level being the children
> of umbrella lists), or serves important use cases without
> significantly complexifying the job of serving the common case.

I argue that it simplifies the case that you mention because it provides a 
uniform way to deal with all of the aspects, especially the delegation aspects 
which are not addressed in the present scheme.

> I don't see a simplification for the reasons expressed above.
> 
> What are the use cases for a mor

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Being able to "write URIs by hand" is a violation of the HAL design
 > because it locks the interface into a particular implementation.

Sorry, that's an un-Pythonic way to think.  If HAL really requires
URIs that only a machine can deal with, let's junk it.  "If the
implementation is hard to explain, it's a bad idea."

But I really don't think HAL requires that.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Groupings of lists simply provides a "shorthand" for the
 > description of characteristics which are common to the group.

You don't need to teach Grandma how to suck intensional
vs. extensional Python eggs.

 > > Such flexibility has benefits and costs.  How many of our users will
 > > need/want this flexibility?  (Genuine question.  I personally don't
 > > want it, so it's hard for me to estimate.)
 > 
 > The advantage in using the generic structure is that it does not
 > impose any pre-supposed structure on the collection of lists.

Ie, the advantage of being generic is that it's generic.

 > Note that "core" doesn't NEED the structure to function.

Of course not, the only structure we NEED is a tape that's lightyears
long, and a finite automaton that Turing designed in the 40s IIRC.
Sorry for the sarcasm (well, a little bit sorry), but in deciding on
design principles we need to evaluate simplicity, practicality, etc
from the point of view of the people involved.

The question is whether structure makes the program easier for users
to use and for developers to create and maintain.  I think the tried
and true hierarchy (site -> virtual hosts -> lists) matches some a
natural hierarchy in administrative responsibility and user
understanding of this corner of the Web.  That makes it easier to
think about requirements and write code to satisfy them.

 > The structure can be imposed by having the interface agent impose
 > constraints on the members of a group of lists and mapping an
 > operation on the group into that operation on each of its members.

Yes, and we'll have to create a language to express those constraints
and an interpreter to enforce them, *and* create objects like "site"
== Mailman instance and "vhost" out of the abstract groups.  Costs,
benefits, which is bigger?

 > If we use a MPTT key

"Ministry of Posts, Telegraph, and Telephone"?  "mildly paranoic teletype"?

 > as the list/list-group identifier, we get the generic hierarchy as
 > a byproduct.

No, that's not enough.  Sites and virtual hosts have attributes
besides lists (websites, the "mailman" list, owner and admin
addresses, ...).  There should be objects that correspond to those
concepts to carry those attributes.

 > The only real issue is how we would express constraints that get
 > delegated.
 > 
 > But we need to address that issue for any structure that we
 > establish.

True, but it's not a question of need to or not, it's a question of
costs and benefits.  Generic code is more expensive to create and
maintain in many cases.  I suspect it will be here, as well.  Without
use cases for the generality, it's hard to see the benefits.  When do
you expect the generality to be of use?

 > Virtual hosting is the primary example of the need for a
 > hierarchical administrative structure. However, it can also be
 > useful in corporate structures where the email address space might
 > be partitioned in a quite different manner.
 > 
 > From a design perspective, the "core" message handler should be
 > distinct from the configuration administrator.
 >
 > Message handling uses the current value of various configuration
 > parameters. It need not, and should not be concerned with the
 > mechanics related to the setting or modification of those
 > parameters.
 > 
 > Since these parameters seldom change, an effective caching
 > mechanism would address access performance issues.

I have no clue what you're trying to express here.  I don't see any
performance issues, except that programmers whose brains have exploded
from cognitive overload tend not to produce double-digit KLOC/hour.
My concern is entirely whether the design you propose simplifies the
job of meeting the common requirement of creating a (1 to 3 level)
hierarchical organization of lists (the third level being the children
of umbrella lists), or serves important use cases without
significantly complexifying the job of serving the common case.

I don't see a simplification for the reasons expressed above.

What are the use cases for a more generic structure?


___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 2:15 AM, Stephen J. Turnbull  wrote:

> Xu Wang writes:
>> The problem is how do you  "confirm ownership of the subscribed address"
>> when a request coming with an access token.
> 
> You don't.  That was done when the OAuth ID was linked to the address,
> using the usual 3-step handshake (submit the association, receive an
> email containing a secret, confirm ownership by replying with the secret).

In many installations, the linking may not require the email handshake.
An installation may choose to "trust" that the third party issuing the access 
credential has already performed sufficient vetting of the association.

I'm thinking of things like BrowserID credentials or Google/Twitter/Facebook 
issued credentials.

However, that is a local "policy" whose decision involves a tradeoff between 
the level of assurance and the ease in establishing the association.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 10:36 AM, Stephen J. Turnbull  wrote:
> Richard Wackerbarth writes:
>> Primary Key == An identifier of the server's choice that identifies
>> a unique instance of the specified resource.  It is important to
>> note that the client CANNOT rely on any particular scheme for
>> mapping other keys to this identifier.
> 
> That's true for resources that were added after the client was
> written, but there's no reason I can see why we shouldn't make it easy
> for people to write URIs by hand if they know something about Mailman.

Being able to "write URIs by hand" is a violation of the HAL design because it 
locks the interface into a particular implementation. The design principal is 
that "things will change".

Although there is an advantage in having URIs that convey semantic value, (for 
example using a "short name" to designate one of the lists on the server), we 
should leave that mapping to some configuration aspect of the particular 
installation.

Remember that the REST URIs are intended to be mechanisms for automated agents 
to access resources. They are not intended to be the substitute for a user's 
search interface.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> It is not necessary to have more than a flat collection of lists.
> 
> I don't know how it will be represented, but we *do* need to support
> virtual hosting, where the mailman administrator delegates site
> administration to the owner of the virtual host.

A list is a first class object. Each list has its own set of parameters which 
characterize it.
One portion of those characteristics is the administrative permissions 
associated with the creation and alteration of the list.

Groupings of lists simply provides a "shorthand" for the description of 
characteristics which are common to the group.

>> In fact, that approach has the advantage that each list can be
>> allowed to have individual configuration parameters. At the
>> present, he has attached the "base web URL" to the
>> email_domain. Instead, I would like to have the ability to set that
>> on a per-list basis.
> 
> I think that's reasonable.
> 
>> Rather than defining a specific structure, I would substitute a
>> more generic structure defining collections of lists. This tree
>> could be configured to represent any organizational hierarchy that
>> the installation desires.
> 
> Such flexibility has benefits and costs.  How many of our users will
> need/want this flexibility?  (Genuine question.  I personally don't
> want it, so it's hard for me to estimate.)

The advantage in using the generic structure is that it does not impose any 
pre-supposed structure on the collection of lists.
Note that "core" doesn't NEED the structure to function. The structure can be 
imposed by having the interface agent impose constraints on the members of a 
group of lists and mapping an operation on the group into that operation on 
each of its members.

If we use a MPTT key as the list/list-group identifier, we get the generic 
hierarchy as a byproduct.

The only real issue is how we would express constraints that get delegated.

But we need to address that issue for any structure that we establish.

Virtual hosting is the primary example of the need for a hierarchical 
administrative structure. However, it can also be useful in corporate 
structures where the email address space might be partitioned in a quite 
different manner.

>From a design perspective, the "core" message handler should be distinct from 
>the configuration administrator.
Message handling uses the current value of various configuration parameters. It 
need not, and should not be concerned with the mechanics related to the setting 
or modification of those parameters.

Since these parameters seldom change, an effective caching mechanism would 
address access performance issues.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Xu Wang writes:

 > The problem is how do you  "confirm ownership of the subscribed address"
 > when a request coming with an access token.

You don't.  That was done when the OAuth ID was linked to the address,
using the usual 3-step handshake (submit the association, receive an
email containing a secret, confirm ownership by replying with the secret).

 > In another words, unless your are the provider, how do you validate
 > the access token issued by a provider at the resource endpoint?

I'm not sure what you mean.  In the security context (as others),
"validate" means mostly "check the syntax".  But a valid token is
assumed to be authentic (otherwise the provided has been suborned).

Remember, a provider does not *authorize* anything.  A provider offers
a channel of communication to the resource owner, who does the
authorization.  Ie, provider tells owner "client tells me consumer
wants to access the X Files", and on success returns a token to the
client indicating "I've confirmed that you are indeed talking to the
owner, and by the way, *she* says it's OK to let consumer look at
them."

 > > Why?  The whole point of the OAuth protocol is that the authentication
 > > is delegated to an OAuth client, which contacts the provider, and if
 > > successful returns a token to the customer.  The customer then
 > > interprets that token as it likes.  The tokens have a specific,
 > > well-known form, so the authentication subsystem is completely
 > > independent of the application API.
 > >
 > I may misunderstood you, but OAuth doesn't specify the format or
 > content of the access token. It is left to the implementation of a
 > provider. This is true for both OAuth 1.a and OAuth 2.

I'd have to look again to be 100% sure, but I'm pretty sure that what
the provider returns is well-defined.  What the client gives to the
application is application-defined.

 > To control the access of a resource,  a provider have to authenticate both
 > client and the resource owner, issue an access token if authenticated
 > resource owner authorized the resource access for a specific client
 > (authenticated by a client id and a secret).  When the access token coming
 > with a request at the API, only the provider or an agent of the provider
 > knows what it is.

Again IIRC, the provider doesn't know what the token is.  The *client*
does.  The provider just passes a message saying "Access to the X
Files, which you own, have been requested.  Is that OK?"

In practice, the common case is that consumer == owner, so effectively
the message boils down to, "Click OK if you are you".

 > What I'm saying is that if OAuth is supported, mailman will be a part of
 > provider because it holds and protects the user's data.

OAuth providers don't know about the protected data.  OAuth consumers
do.  The provider-client combination only offers a communication
channel.  That's what is so elegant about the OAuth concept.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

On Sat, Apr 27, 2013 at 4:27 AM, Richard Wackerbarth wrote:

> I think that we are advocating the same approach.
> Your example is better tailored to actual MM resources and can be
> substituted for the one that I referenced.
> Note: I am "speaking" conceptually. The actual hard design of the details
> would be the scope of work for a GSoC project.
> The easiest way to present all of the details is to actually create a
> reference implementation. :)
>
> Totally agreed.

To be clear, what I gave was only some random test data of a testing data
schema from an early stage prototype for the purpose of concepture
discussion . Neither to be the real use case nor to be a substitution
of any existing working components.

I started with MySQL, but after playing around a bit, I do think a NoSQL
database is a good fit for this project. It will simplify the task quite a
bit.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

On Sat, Apr 27, 2013 at 6:34 AM, Richard Wackerbarth wrote:

>
> On Apr 27, 2013, at 8:19 AM, "Stephen J. Turnbull" 
> wrote:
>
> > Richard Wackerbarth writes:
> >
> >>> "ABCDEFG" is what?  The list?
> >>
> >> Yes. But note that it is some pk provided by the list store.
> >
> > "pk" ?
>
> Primary Key == An identifier of the server's choice that identifies a
> unique instance of the specified resource.
> It is important to note that the client CANNOT rely on any particular
> scheme for mapping other keys to this identifier.
>
> 
> https://server.example.com/mailman/attribute/posting_address/test_list@example.comwould
>  return the URI representing the list
> >>>
> >>> Why have you changed the order of components here?
> >>
> >> Because I don't know the pk for the list. I wish to look it up.
> >
> > So "attribute/posting_address/test_l...@example.com" is a query that
> > means "give me a way to indicate this list"?
>
> Yes
>
> > These URIs are pretty ugly.  Surely we can do better?
>
> Perhaps we can. But we need to conform to the HAL framework style.
>
> As I understand it, the consumer understands the semantics of various
> links, but the actual links are "discovered" as a part of previous queries
> and not "constructed".  As such, the links depend more on the ease of
> implementation rather than their "beauty".
>
> Perhaps Xu has experience and can enlighten us.
>
>
The rules of good endpoint is very simple.
 * For first-class resources
   collections endpoint:

 e.g. http://list.mailman.org/api/v1/users
   document endpoint:
/
 e.g.
http://list.mailman.org/api/v1/users/ID1234567/
 * Don't use path as tools of deep query, use query string for
query
 e.g.
http://list.mailman.org/api/v1/users/?subscriptions="mailing_list_abc";
 * Use hyperlinks for references between first-class resources
in documents:
 e.g. curl
localhost:5000/api/v1/users/?max_results=2 | python -mjson.tool
{
"_items": [
{
"_id": "517b88e4f84a4b15f756a1af",
"_links": {
"self": {
"href":
"localhost:5000/api/v1/users/517b88e4f84a4b15f756a1af/",
"title": "user"
}
}, ...
},
{
"_id": "517b88e4f84a4b15f756a1b0",
"_links": {
"self": {
"href":
"localhost:5000/api/v1/users/517b88e4f84a4b15f756a1b0/",
"title": "user"
}
},
...
],
"_links": {
"next": {
"href": "localhost:5000/api/v1/users/?max_results=2&page=2",
"title": "next page"
},
"parent": {
"href": "localhost:5000/api/v1",
"title": "home"
},
"self": {
"href": "localhost:5000/api/v1/users/",
"title": "users"
}
}
}
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull wrote:

> Xu Wang writes:
>
>  > For OAuth , you need to
>  > implement token based auth in API, as well as a provider service
>  > because there is no open OAuth provider service for third party API
>  > out there :-(
>
> No, we don't *need* to implement *anything*.  We implement what we
> want to.  That's the nature of a volunteer project.
>

Loud and clear.


>
> I'm recommending against becoming a provider because I think it's too
> hard to provide the enterprise-strength implementation you focus on.
> The client side is much easier.
>

Agreed.


>  > In my view, OAuth really belongs to an enterprise system, rather
>  > than a specific api or one application. It requires a existing
>  > robust web-based auth system on the provider's site.
>
> It very much depends on how accurate the identification of the client
> needs to be.  For an open subscription service where the only thing
> you really need to do is confirm ownership of the subscribed address,
> any provider the user trusts is good enough.
>

The problem is how do you  "confirm ownership of the subscribed address"
when a request coming with an access token. In another words, unless your
are the provider, how do you validate the access token issued by a
provider at the resource endpoint?


>  > This will also make the API less "independent" because it is depending
> on
>  > the provider service and provider's auth system.
>
> Why?  The whole point of the OAuth protocol is that the authentication
> is delegated to an OAuth client, which contacts the provider, and if
> successful returns a token to the customer.  The customer then
> interprets that token as it likes.  The tokens have a specific,
> well-known form, so the authentication subsystem is completely
> independent of the application API.
>
>
I may misunderstood you, but OAuth doesn't specify the format or content of
 the access token. It is left to the implementation of a provider. This is
true for both OAuth 1.a and OAuth 2.

To control the access of a resource,  a provider have to authenticate both
client and the resource owner, issue an access token if authenticated
resource owner authorized the resource access for a specific client
(authenticated by a client id and a secret).  When the access token coming
with a request at the API, only the provider or an agent of the provider
knows what it is.

What I'm saying is that if OAuth is supported, mailman will be a part of
provider because it holds and protects the user's data.


> There does need to be coupling to the UI, to provide a channel to the
> OAuth provider.
>
>  > Only if there is a strong 3-legged auth use case, should one push to
> this
>  > controversy route.
>
> I don't see 3-legged auth as the killer app for OAuth here.  Rather, I
> see convenience for subscribers as the main feature, although it might
> also be useful for moderators and other admins.
>
> Stev
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Primary Key == An identifier of the server's choice that identifies
 > a unique instance of the specified resource.  It is important to
 > note that the client CANNOT rely on any particular scheme for
 > mapping other keys to this identifier.

That's true for resources that were added after the client was
written, but there's no reason I can see why we shouldn't make it easy
for people to write URIs by hand if they know something about Mailman.

 > > These URIs are pretty ugly.  Surely we can do better?
 > 
 > Perhaps we can. But we need to conform to the HAL framework style.

Well, I haven't studied it carefully, but the examples on Mike Kelly's
pages are pretty enough.

 > As I understand it, the consumer understands the semantics of
 > various links, but the actual links are "discovered" as a part of
 > previous queries and not "constructed".  As such, the links depend
 > more on the ease of implementation rather than their "beauty".

>From the consumer's point of view, yes, the links are discovered.  But
the producer constructs them.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > It is not necessary to have more than a flat collection of lists.

I don't know how it will be represented, but we *do* need to support
virtual hosting, where the mailman administrator delegates site
administration to the owner of the virtual host.

 > In fact, that approach has the advantage that each list can be
 > allowed to have individual configuration parameters. At the
 > present, he has attached the "base web URL" to the
 > email_domain. Instead, I would like to have the ability to set that
 > on a per-list basis.

I think that's reasonable.

 > Rather than defining a specific structure, I would substitute a
 > more generic structure defining collections of lists. This tree
 > could be configured to represent any organizational hierarchy that
 > the installation desires.

Such flexibility has benefits and costs.  How many of our users will
need/want this flexibility?  (Genuine question.  I personally don't
want it, so it's hard for me to estimate.)

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 8:19 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>>> "ABCDEFG" is what?  The list?
>> 
>> Yes. But note that it is some pk provided by the list store.
> 
> "pk" ?

Primary Key == An identifier of the server's choice that identifies a unique 
instance of the specified resource.
It is important to note that the client CANNOT rely on any particular scheme 
for mapping other keys to this identifier.

 https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
  would return the URI representing the list
>>> 
>>> Why have you changed the order of components here?
>> 
>> Because I don't know the pk for the list. I wish to look it up.
> 
> So "attribute/posting_address/test_l...@example.com" is a query that
> means "give me a way to indicate this list"?

Yes

> These URIs are pretty ugly.  Surely we can do better?

Perhaps we can. But we need to conform to the HAL framework style.

As I understand it, the consumer understands the semantics of various links, 
but the actual links are "discovered" as a part of previous queries and not 
"constructed".  As such, the links depend more on the ease of implementation 
rather than their "beauty".

Perhaps Xu has experience and can enlighten us.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > > "ABCDEFG" is what?  The list?
 > 
 > Yes. But note that it is some pk provided by the list store.

"pk" ?

 > >> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
 > >>  would return the URI representing the list
 > > 
 > > Why have you changed the order of components here?
 > 
 > Because I don't know the pk for the list. I wish to look it up.

So "attribute/posting_address/test_l...@example.com" is a query that
means "give me a way to indicate this list"?

These URIs are pretty ugly.  Surely we can do better?
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > > Ah so you don't mean what I wrote above, you want to represent
 > > preferences as a table with
 > > 
 > >row = preference-owning-entity att_name att_key

 > Correct. But isn't it
 > 
 > row = preference-owning-entity att_name att_value

Yes.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth  wrote:

> Additionally, I would generalize the grouping of lists into a hierarchical 
> tree that represents the enterprise organization rather than aspects of the 
> internet namespace.

Stephen,

Barry has introduced a small amount of hierarchy into the grouping of lists. 
(E.g. The domain)
Within that hierarchy, he at least alludes to the delegation of authority to 
list owners.

It is not necessary to have more than a flat collection of lists. In fact, that 
approach has the advantage that each list can be allowed to have individual 
configuration parameters. At the present, he has attached the "base web URL" to 
the email_domain. Instead, I would like to have the ability to set that on a 
per-list basis. There is no structural constraint that requires lists to share  
such common values, but I do acknowledge that it is expedient for the system to 
be able to generate the list specific value by some algorithm that is applied 
to a class of lists.

Rather than defining a specific structure, I would substitute a more generic 
structure defining collections of lists. This tree could be configured to 
represent any organizational hierarchy that the installation desires. Various 
persons could then be granted administrative rights over particular subtrees. 
Algorithmic constraints can be assigned to a collection insuring that each list 
therein complies with the enterprise schema.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Xu Wang writes:

 > For OAuth , you need to
 > implement token based auth in API, as well as a provider service
 > because there is no open OAuth provider service for third party API
 > out there :-(

No, we don't *need* to implement *anything*.  We implement what we
want to.  That's the nature of a volunteer project.

I'm recommending against becoming a provider because I think it's too
hard to provide the enterprise-strength implementation you focus on.
The client side is much easier.

 > The provider service has to implement application registration,
 > user auth, token validation and distribution (for oauth 1a, access
 > token need to be pushed to or shared with API).

Yes, if I understand you correctly.

 > In my view, OAuth really belongs to an enterprise system, rather
 > than a specific api or one application. It requires a existing
 > robust web-based auth system on the provider's site.

It very much depends on how accurate the identification of the client
needs to be.  For an open subscription service where the only thing
you really need to do is confirm ownership of the subscribed address,
any provider the user trusts is good enough.

 > This will also make the API less "independent" because it is depending on
 > the provider service and provider's auth system.

Why?  The whole point of the OAuth protocol is that the authentication
is delegated to an OAuth client, which contacts the provider, and if
successful returns a token to the customer.  The customer then
interprets that token as it likes.  The tokens have a specific,
well-known form, so the authentication subsystem is completely
independent of the application API.

There does need to be coupling to the UI, to provide a channel to the
OAuth provider.

 > Only if there is a strong 3-legged auth use case, should one push to this
 > controversy route.

I don't see 3-legged auth as the killer app for OAuth here.  Rather, I
see convenience for subscribers as the main feature, although it might
also be useful for moderators and other admins.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I, and I think Stephen, are advocating the use of oAuth as a "login" method. 
Just as BrowserID provides a third party identifier, Google, Twitter, Facebook, 
etc. provide similar service through oAuth protocols. MM should be configurable 
to accept those, or other enterprise-provided identifiers.

On Apr 27, 2013, at 2:42 AM, Xu Wang  wrote:

> For OAuth , you need to implement token
> based auth in API, as well as a provider service because there is no open
> OAuth provider service for third party API out there :-(
> 
> The provider service has to implement  application registration, user auth,
> token validation and distribution (for oauth 1a, access token need to be
> pushed to or shared with API).
> 
> In my view, OAuth really belongs to an enterprise system, rather than a
> specific api or one application. It requires a existing robust web-based
> auth system on the provider's site.
> 
> This will also make the API less "independent" because it is depending on
> the provider service and provider's auth system.
> 
> With that said, the API could have a plugin that support  "token-based"
> authorization, with an out-of-band token distribution/validation and
> management service, whatever it would be.
> 
> Only if there is a strong 3-legged auth use case, should one push to this
> controversy route.
> 
> Xu Wang
> 
> 
> On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull 
> wrote:
> 
>> Abhilash Raj writes:
>> 
>>> Hi all,
>>> I wrote a brief summary[1] of this thread.
>> 
>> You've misinterpreted or mistyped a couple things I wrote:
>> 
>> I'm not against OAuth in general, just against Mailman being an OAuth
>> *provider*, or bundling one, because we can't support it properly.
>> Users should get auth stuff from somebody whose primary interest is
>> security stuff.
>> 
>> When I write authentication and authorization should be avoided, I
>> don't mean Mailman doesn't authenticate and authorize users.  I mean
>> the implementation should be delegated to robust, well-tested modules
>> or external applications (eg, Apache) whereever possible.
>> 
>> The last quote needs to be fleshed out.  "This practice" refers to not
>> exposing keys and other secrets to the whole application, including
>> cooperating processes.  If authentication can be done in one place and
>> an internal session or one-time authorization be granted, that's what
>> should be done, rather than exposing user credentials to other parts
>> of the application to do their own authentication and authorization.
>> 
>> In making such a summary, I think it would be better to organize by
>> topic.  Eg, a partial outline:
>> 
>> REST API for extended user profiles
>>  Authorization
>>Trusting local connections
>>HTTP Basic
>>OAuth
>>- Recommended for "outside world" [Florian]
>>- Advocates including an OAuth provider as a non-default,
>>  experts-only option [Florian]
>>- Opposes bundling an OAuth provider [Stephen]
>>- OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>>  now? [Stephen]
>>- Don't need an OAuth provider to share authorizations (in fact,
>>  at least in OAuth 2.0, providers don't provide sharing at all)
>>  [Stephen]
>>- Implementing OAuth provider doesn't provide the benefits of
>>  OAuth (ie, add an OAuth provider means users have yet another
>>  set of credentials to manage) [Stephen]
>>- OAuth architecture = provider + client + consumer [Richard]
>>- Agrees to Mailman as OAuth consumer, not provider [Richard]
>>- OAuth may be overengineering, at first [Barry]
>>  Database schemas
>>  Database implementations
>>  Wire Protocol
>> etc...
>> 
>> Also, in that format it's easy to reorganize:
>> 
>> REST API for extended user profiles
>>  Authorization
>>Trusting local connections
>>HTTP Basic
>>OAuth
>>- OAuth architecture = provider + client + consumer [Richard]
>>- Use client in Mailman?
>>  - Recommended for "outside world" [Florian]
>>  - Agrees to Mailman as OAuth consumer, not provider [Richard]
>>  - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>>now? [Stephen]
>>  - OAuth may be overengineering, at first [Barry]
>>- Use provider in Mailman?
>>  - Advocates including an OAuth provider as a non-default,
>>experts-only option [Florian]
>>  - Opposes bundling an OAuth provider [Stephen, Richard]
>>  - Implementing OAuth provider doesn't provide the benefits of
>>OAuth (ie, add an OAuth provider means users have yet another
>>set of credentials to manage) [Stephen]
>>  - Don't need an OAuth provider to share authorizations (in fact,
>>at least in OAuth 2.0, providers don't provide sharing at all)
>>[Stephen]
>>  Database schemas
>>  Database implementations
>>  Wire Protocol
>> etc...
>> 
>> By the way, don't go out of your way to reorganize what you've already
>> done, except as it's us

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I think that we are advocating the same approach.
Your example is better tailored to actual MM resources and can be substituted 
for the one that I referenced.
Note: I am "speaking" conceptually. The actual hard design of the details would 
be the scope of work for a GSoC project.
The easiest way to present all of the details is to actually create a reference 
implementation. :)

On Apr 27, 2013, at 3:21 AM, Xu Wang  wrote:

> Here is an example of what it might look like for "user" resource returned
> by the api (without any auth):
> 
> curl http://localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/
> HTTP/1.0 200 OK
> Content-Type: application/json
> Content-Length: 1232
> Cache-Control: max-age=20,must-revalidate
> Expires: Sat, 27 Apr 2013 08:07:04 GMT
> ETag: 8252e88a72eea8fd4c93aa57435a3857f618d5d1
> Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
> Date: Sat, 27 Apr 2013 08:03:44 GMT
> 
> {
>"_id": "517b5560f84a4b13d239fc59",
>"_links": {
>"collection": {
>"href": "localhost:5000/api/v1/users/",
>"title": "users"
>},
>"parent": {
>"href": "localhost:5000/api/v1",
>"title": "home"
>},
>"self": {
>"href":
> "localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
>"title": "user"
>}
>},
>"created": "Sat, 27 Apr 2013 04:34:40 UTC",
>"email": "swesg...@baqlwrzxqfjpofpy.nl",
>"firstname": "wtegrglnub",
>"lastname": "bjsbvjrn",
>"roles": "level_3",
>"subscriptions": [
>{
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc56/",
>"options": {
>"option_0": "qifqk",
>"option_1": "qyqyx",
>"option_2": "dirkf",
>"option_3": "yjrtv",
>"option_4": "mljew"
>},
>"ref": "517b5560f84a4b13d239fc56",
>"title": "mailing list"
>},
>{
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc58/",
>"options": {
>"option_0": "aixqy",
>"option_1": "triwy",
>"option_2": "aponq",
>"option_3": "xmorj",
>"option_4": "szmig"
>},
>"ref": "517b5560f84a4b13d239fc58",
>"title": "mailing list"
>},
>{
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
>"options": {
>"option_0": "ltops",
>"option_1": "bojfl",
>"option_2": "qjsyl",
>"option_3": "ndtof",
>"option_4": "diass"
>},
>"ref": "517b5560f84a4b13d239fc54",
>"title": "mailing list"
>}
>],
>"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
> }
> 
> and let's follow the last of mailing list link in the users.subscriptions:
> 
> $ curl -i 'localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/'
> 
> HTTP/1.0 200 OK
> Content-Type: application/json
> Content-Length: 711
> Cache-Control: max-age=20,must-revalidate
> Expires: Sat, 27 Apr 2013 08:05:00 GMT
> ETag: eea6cfa4fc6311a1ea3c5c4189597ab962369d34
> Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
> Date: Sat, 27 Apr 2013 08:04:40 GMT
> 
> {
>"_id": "517b5560f84a4b13d239fc54",
>"_links": {
>"collection": {
>"href": "localhost:5000/api/v1/mlists/",
>"title": "mlists"
>},
>"parent": {
>"href": "localhost:5000/api/v1",
>"title": "home"
>},
>"self": {
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
>"title": "mailing list"
>}
>},
>"address": "auxri...@rdrfzfmvluylkegy.ca",
>"created": "Sat, 27 Apr 2013 04:34:40 UTC",
>"description":
> "krtejcbwmedzftdvjwagmbqkkiajubnzezxstahexvkrjncecdwsyfjlbobgjuxevwgflxlnemqtqcjz",
>"option": {
>"option_0": "vwmum"
>},
>"owners": [
>{
>"href":
> "localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
>"name": "wtegrglnub bjsbvjrn",
>"ref": "517b5560f84a4b13d239fc59",
>"title": "user"
>}
>],
>"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
> }
> 
> 
> 
> On Sat, Apr 27, 2013 at 1:00 AM, Xu Wang  wrote:
> 
>> Here is my take on the basic system requirements and design issues:
>> 
>> System Components:
>>   * A RESTful 
>> API
>>  -
>> a mini-server that servers restful calls.
>>   * A persistent store - a schemaless or relaxed datasource, e.g. Mongodb
>>   * An authn/authz service to support api authn/authz and account
>> management
>>   options for authn:
>>- no auth, open to localhost, off load the AC to clients.
>>- base 
>> auth,
>> username/pw

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 2:42 AM, "Stephen J. Turnbull"  
wrote:

> Richard Wackerbarth writes:
> 
>> https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
>> returns the email address to which subscription requests should be
>> sent.
> 
> "ABCDEFG" is what?  The list?

Yes. But note that it is some pk provided by the list store. It may not have 
any recognizable relationship to other characteristics of the list ( such as a 
"common name" or FQDN )
> 
> I think the short prefix /mailman/ should be reserved for traditional
> and anonymous requests.  /mailman/rest_api/ or some such for the
> REST API.

I don't disagree. I would reserve /.well_known/mailman/ as an access point that 
delivers the "root" of the REST API tree and, otherwise, make no assumption 
about the location of it in URI space.

> 
>> https://server.example.com/mailman/list/ABCDEFG/attributes
> 
> This is what you mean by self-documenting?

No. This is an access point for the document. If fetched as JSON or XML, it 
would be machine parseable. If fetched as HTML/text, it would be human readable.

>  Presumably it returns not only the attribute names, but their ranges (types) 
> and docstrings?
> 
>> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
>>  would return the URI representing the list
> 
> Why have you changed the order of components here?

Because I don't know the pk for the list. I wish to look it up.
> 
>> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
>>  might return test_list-j...@example.com
> 
> Huh?  This isn't a syntax error?

Probably is syntactically incorrect. The email address would need to be URL 
escaped.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 12:51 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>> subscription - the binding of an email address to a list.
> 
> Also preferences are bound here.  (This is not the only kind of thing
> that preferences can be bound to, but experience shows that we need
> per-subscription preferences.)

Complete agreement.

> 
>> First, rather than having multiple attributes and preferences as
>> "columns" in a table, I would portray them as multiple rows in a
>> table where the attribute names are a key that is used to select
>> the corresponding value.
> 
> I have no clue what that sentence means, but I suppose that you mean
> that the current representation is something like (in mock-ABNF)
> 
>member := address fullname *attribute
> 
> and you want to change that to
> 
>member := address fullname preferences
>preferences := *attribute
> 
>> Additionally, I would generalize the grouping of lists into a
>> hierarchical tree that represents the enterprise organization
>> rather than aspects of the internet namespace.
> 
> Example?
> 
>> By treating the preferences as a table of key-value pairs, we can
>> easily extend the list of elements with plug-in modules without
>> having to change the data handling or display mechanisms.
> 
> Ah so you don't mean what I wrote above, you want to represent
> preferences as a table with
> 
>row = preference-owning-entity att_name att_key

> 
> ?

Correct. But isn't it

row = preference-owning-entity att_name att_value
?

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

Here is an example of what it might look like for "user" resource returned
by the api (without any auth):

curl http://localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 1232
Cache-Control: max-age=20,must-revalidate
Expires: Sat, 27 Apr 2013 08:07:04 GMT
ETag: 8252e88a72eea8fd4c93aa57435a3857f618d5d1
Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
Date: Sat, 27 Apr 2013 08:03:44 GMT

{
"_id": "517b5560f84a4b13d239fc59",
"_links": {
"collection": {
"href": "localhost:5000/api/v1/users/",
"title": "users"
},
"parent": {
"href": "localhost:5000/api/v1",
"title": "home"
},
"self": {
"href":
"localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
"title": "user"
}
},
"created": "Sat, 27 Apr 2013 04:34:40 UTC",
"email": "swesg...@baqlwrzxqfjpofpy.nl",
"firstname": "wtegrglnub",
"lastname": "bjsbvjrn",
"roles": "level_3",
"subscriptions": [
{
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc56/",
"options": {
"option_0": "qifqk",
"option_1": "qyqyx",
"option_2": "dirkf",
"option_3": "yjrtv",
"option_4": "mljew"
},
"ref": "517b5560f84a4b13d239fc56",
"title": "mailing list"
},
{
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc58/",
"options": {
"option_0": "aixqy",
"option_1": "triwy",
"option_2": "aponq",
"option_3": "xmorj",
"option_4": "szmig"
},
"ref": "517b5560f84a4b13d239fc58",
"title": "mailing list"
},
{
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
"options": {
"option_0": "ltops",
"option_1": "bojfl",
"option_2": "qjsyl",
"option_3": "ndtof",
"option_4": "diass"
},
"ref": "517b5560f84a4b13d239fc54",
"title": "mailing list"
}
],
"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
}

and let's follow the last of mailing list link in the users.subscriptions:

 $ curl -i 'localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/'

HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 711
Cache-Control: max-age=20,must-revalidate
Expires: Sat, 27 Apr 2013 08:05:00 GMT
ETag: eea6cfa4fc6311a1ea3c5c4189597ab962369d34
Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
Date: Sat, 27 Apr 2013 08:04:40 GMT

{
"_id": "517b5560f84a4b13d239fc54",
"_links": {
"collection": {
"href": "localhost:5000/api/v1/mlists/",
"title": "mlists"
},
"parent": {
"href": "localhost:5000/api/v1",
"title": "home"
},
"self": {
"href":
"localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
"title": "mailing list"
}
},
"address": "auxri...@rdrfzfmvluylkegy.ca",
"created": "Sat, 27 Apr 2013 04:34:40 UTC",
"description":
"krtejcbwmedzftdvjwagmbqkkiajubnzezxstahexvkrjncecdwsyfjlbobgjuxevwgflxlnemqtqcjz",
"option": {
"option_0": "vwmum"
},
"owners": [
{
"href":
"localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
"name": "wtegrglnub bjsbvjrn",
"ref": "517b5560f84a4b13d239fc59",
"title": "user"
}
],
"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
}



On Sat, Apr 27, 2013 at 1:00 AM, Xu Wang  wrote:

> Here is my take on the basic system requirements and design issues:
>
> System Components:
>* A RESTful 
> API
>  -
> a mini-server that servers restful calls.
>* A persistent store - a schemaless or relaxed datasource, e.g. Mongodb
>* An authn/authz service to support api authn/authz and account
> management
>options for authn:
> - no auth, open to localhost, off load the AC to clients.
> - base 
> auth,
> username/pwd, requires https and minimum client effort.
> - HMAC 
> auth,
> requires clients to sign the requests with shared secrets, e.g. oauth1 and
> AWS S3 auth. Needs out-of-band secretes and token management and
> distribution.
>options for authz (privileges are http methods combined with
> endpoint/scope):
> - role based, i.e. privileges are associated with role, work
> with base auth.
> - owner based,  i.e. privileges are associated with user, work
> with base auth.
> - token based, i.e

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

Here is my take on the basic system requirements and design issues:

System Components:
   * A RESTful 
API
-
a mini-server that servers restful calls.
   * A persistent store - a schemaless or relaxed datasource, e.g. Mongodb
   * An authn/authz service to support api authn/authz and account
management
   options for authn:
- no auth, open to localhost, off load the AC to clients.
- base
auth,
username/pwd, requires https and minimum client effort.
- HMAC
auth,
requires clients to sign the requests with shared secrets, e.g. oauth1 and
AWS S3 auth. Needs out-of-band secretes and token management and
distribution.
   options for authz (privileges are http methods combined with
endpoint/scope):
- role based, i.e. privileges are associated with role, work
with base auth.
- owner based,  i.e. privileges are associated with user, work
with base auth.
- token based, i.e. privileges are associated with token, see
OAuth  and HMAC
auth

Resource/Data model servered by API:
* TBD,  means data model changes "as-we-go".
   A few initial data type should be given as a start point, or as
examples:
 - users
 - mailing_lists
 - subscriptions
 - user_profiles
 - accounts
 etc.
* data presentation should be HATEOAS
 enabled.
* content-type, applicaion/json, xml, html, etc.
* etag should be used to support caching control and concurrency
control.
* each resource servered by the api may have a simple validation
schema, i.e. in some sort of DSL.

Implementation Consideration:
* Small footprint.
* The API mechanism should decoupled with the resource data model to
allow maximum flexibility.
* Due to the decoupling of API and the resource data model, the API may
only have limited support  for advanced or customized quires.
* It is a "garbage-in, garbage-out" service, i.e. no or minmum data
manipulation by the service. E.g. if you post in a clear texted password
with user's data, it will stay clear in the database, and return back as
plain text when someone gets.
* Service oriented, i.e runs as an independent first-class service.
* DRY, use other good open source packages whenever possible.
* In Python :-)

Relations to other system components:
* Open... and RESTful


On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull wrote:

> Abhilash Raj writes:
>
>  > Hi all,
>  > I wrote a brief summary[1] of this thread.
>
> You've misinterpreted or mistyped a couple things I wrote:
>
> I'm not against OAuth in general, just against Mailman being an OAuth
> *provider*, or bundling one, because we can't support it properly.
> Users should get auth stuff from somebody whose primary interest is
> security stuff.
>
> When I write authentication and authorization should be avoided, I
> don't mean Mailman doesn't authenticate and authorize users.  I mean
> the implementation should be delegated to robust, well-tested modules
> or external applications (eg, Apache) whereever possible.
>
> The last quote needs to be fleshed out.  "This practice" refers to not
> exposing keys and other secrets to the whole application, including
> cooperating processes.  If authentication can be done in one place and
> an internal session or one-time authorization be granted, that's what
> should be done, rather than exposing user credentials to other parts
> of the application to do their own authentication and authorization.
>
> In making such a summary, I think it would be better to organize by
> topic.  Eg, a partial outline:
>
> REST API for extended user profiles
>   Authorization
> Trusting local connections
> HTTP Basic
> OAuth
> - Recommended for "outside world" [Florian]
> - Advocates including an OAuth provider as a non-default,
>   experts-only option [Florian]
> - Opposes bundling an OAuth provider [Stephen]
> - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>   now? [Stephen]
> - Don't need an OAuth provider to share authorizations (in fact,
>   at least in OAuth 2.0, providers don't provide sharing at all)
>   [Stephen]
> - Implementing OAuth provider doesn't provide the benefits of
>   OAuth (ie, add an OAuth provider means users have yet another
>   set of credentials to manage) [Stephen]
> - OAuth architecture = provider + client + consumer [Richard]
> - Agrees to Mailman as OAuth consumer, not provider [Richard]
> - OAuth may be overengineering, at first [Barry]
>   Database schemas
>   Database implementations

Re: [Mailman-Developers] Architecture for extra profile info

[Xu Wang]

For OAuth , you need to implement token
based auth in API, as well as a provider service because there is no open
OAuth provider service for third party API out there :-(

The provider service has to implement  application registration, user auth,
token validation and distribution (for oauth 1a, access token need to be
pushed to or shared with API).

In my view, OAuth really belongs to an enterprise system, rather than a
specific api or one application. It requires a existing robust web-based
auth system on the provider's site.

This will also make the API less "independent" because it is depending on
the provider service and provider's auth system.

With that said, the API could have a plugin that support  "token-based"
authorization, with an out-of-band token distribution/validation and
management service, whatever it would be.

Only if there is a strong 3-legged auth use case, should one push to this
controversy route.

Xu Wang


On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull wrote:

> Abhilash Raj writes:
>
>  > Hi all,
>  > I wrote a brief summary[1] of this thread.
>
> You've misinterpreted or mistyped a couple things I wrote:
>
> I'm not against OAuth in general, just against Mailman being an OAuth
> *provider*, or bundling one, because we can't support it properly.
> Users should get auth stuff from somebody whose primary interest is
> security stuff.
>
> When I write authentication and authorization should be avoided, I
> don't mean Mailman doesn't authenticate and authorize users.  I mean
> the implementation should be delegated to robust, well-tested modules
> or external applications (eg, Apache) whereever possible.
>
> The last quote needs to be fleshed out.  "This practice" refers to not
> exposing keys and other secrets to the whole application, including
> cooperating processes.  If authentication can be done in one place and
> an internal session or one-time authorization be granted, that's what
> should be done, rather than exposing user credentials to other parts
> of the application to do their own authentication and authorization.
>
> In making such a summary, I think it would be better to organize by
> topic.  Eg, a partial outline:
>
> REST API for extended user profiles
>   Authorization
> Trusting local connections
> HTTP Basic
> OAuth
> - Recommended for "outside world" [Florian]
> - Advocates including an OAuth provider as a non-default,
>   experts-only option [Florian]
> - Opposes bundling an OAuth provider [Stephen]
> - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>   now? [Stephen]
> - Don't need an OAuth provider to share authorizations (in fact,
>   at least in OAuth 2.0, providers don't provide sharing at all)
>   [Stephen]
> - Implementing OAuth provider doesn't provide the benefits of
>   OAuth (ie, add an OAuth provider means users have yet another
>   set of credentials to manage) [Stephen]
> - OAuth architecture = provider + client + consumer [Richard]
> - Agrees to Mailman as OAuth consumer, not provider [Richard]
> - OAuth may be overengineering, at first [Barry]
>   Database schemas
>   Database implementations
>   Wire Protocol
> etc...
>
> Also, in that format it's easy to reorganize:
>
> REST API for extended user profiles
>   Authorization
> Trusting local connections
> HTTP Basic
> OAuth
> - OAuth architecture = provider + client + consumer [Richard]
> - Use client in Mailman?
>   - Recommended for "outside world" [Florian]
>   - Agrees to Mailman as OAuth consumer, not provider [Richard]
>   - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
> now? [Stephen]
>   - OAuth may be overengineering, at first [Barry]
> - Use provider in Mailman?
>   - Advocates including an OAuth provider as a non-default,
> experts-only option [Florian]
>   - Opposes bundling an OAuth provider [Stephen, Richard]
>   - Implementing OAuth provider doesn't provide the benefits of
> OAuth (ie, add an OAuth provider means users have yet another
> set of credentials to manage) [Stephen]
>   - Don't need an OAuth provider to share authorizations (in fact,
> at least in OAuth 2.0, providers don't provide sharing at all)
> [Stephen]
>   Database schemas
>   Database implementations
>   Wire Protocol
> etc...
>
> By the way, don't go out of your way to reorganize what you've already
> done, except as it's useful to you.  Gradually improve it as it helps
> you to recall discussion.
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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-d

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
 > returns the email address to which subscription requests should be
 > sent.

"ABCDEFG" is what?  The list?

I think the short prefix /mailman/ should be reserved for traditional
and anonymous requests.  /mailman/rest_api/ or some such for the
REST API.

 > https://server.example.com/mailman/list/ABCDEFG/attributes

This is what you mean by self-documenting?  Presumably it returns not
only the attribute names, but their ranges (types) and docstrings?

 > https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
 >  would return the URI representing the list

Why have you changed the order of components here?

 > https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
 >  might return test_list-j...@example.com

Huh?  This isn't a syntax error?

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Abhilash Raj writes:

 > Hi all,
 > I wrote a brief summary[1] of this thread.

You've misinterpreted or mistyped a couple things I wrote:

I'm not against OAuth in general, just against Mailman being an OAuth
*provider*, or bundling one, because we can't support it properly.
Users should get auth stuff from somebody whose primary interest is
security stuff.

When I write authentication and authorization should be avoided, I
don't mean Mailman doesn't authenticate and authorize users.  I mean
the implementation should be delegated to robust, well-tested modules
or external applications (eg, Apache) whereever possible.

The last quote needs to be fleshed out.  "This practice" refers to not
exposing keys and other secrets to the whole application, including
cooperating processes.  If authentication can be done in one place and
an internal session or one-time authorization be granted, that's what
should be done, rather than exposing user credentials to other parts
of the application to do their own authentication and authorization.

In making such a summary, I think it would be better to organize by
topic.  Eg, a partial outline:

REST API for extended user profiles
  Authorization
Trusting local connections
HTTP Basic
OAuth 
- Recommended for "outside world" [Florian]
- Advocates including an OAuth provider as a non-default,
  experts-only option [Florian]
- Opposes bundling an OAuth provider [Stephen]
- OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
  now? [Stephen]
- Don't need an OAuth provider to share authorizations (in fact,
  at least in OAuth 2.0, providers don't provide sharing at all)
  [Stephen]
- Implementing OAuth provider doesn't provide the benefits of
  OAuth (ie, add an OAuth provider means users have yet another
  set of credentials to manage) [Stephen]
- OAuth architecture = provider + client + consumer [Richard]
- Agrees to Mailman as OAuth consumer, not provider [Richard]
- OAuth may be overengineering, at first [Barry]
  Database schemas
  Database implementations
  Wire Protocol
etc...

Also, in that format it's easy to reorganize:

REST API for extended user profiles
  Authorization
Trusting local connections
HTTP Basic
OAuth 
- OAuth architecture = provider + client + consumer [Richard]
- Use client in Mailman?
  - Recommended for "outside world" [Florian]
  - Agrees to Mailman as OAuth consumer, not provider [Richard]
  - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
now? [Stephen]
  - OAuth may be overengineering, at first [Barry]
- Use provider in Mailman?
  - Advocates including an OAuth provider as a non-default,
experts-only option [Florian]
  - Opposes bundling an OAuth provider [Stephen, Richard]
  - Implementing OAuth provider doesn't provide the benefits of
OAuth (ie, add an OAuth provider means users have yet another
set of credentials to manage) [Stephen]
  - Don't need an OAuth provider to share authorizations (in fact,
at least in OAuth 2.0, providers don't provide sharing at all)
[Stephen]
  Database schemas
  Database implementations
  Wire Protocol
etc...

By the way, don't go out of your way to reorganize what you've already
done, except as it's useful to you.  Gradually improve it as it helps
you to recall discussion.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > subscription - the binding of an email address to a list.

Also preferences are bound here.  (This is not the only kind of thing
that preferences can be bound to, but experience shows that we need
per-subscription preferences.)

 > First, rather than having multiple attributes and preferences as
 > "columns" in a table, I would portray them as multiple rows in a
 > table where the attribute names are a key that is used to select
 > the corresponding value.

I have no clue what that sentence means, but I suppose that you mean
that the current representation is something like (in mock-ABNF)

member := address fullname *attribute

and you want to change that to

member := address fullname preferences
preferences := *attribute

 > Additionally, I would generalize the grouping of lists into a
 > hierarchical tree that represents the enterprise organization
 > rather than aspects of the internet namespace.

Example?

 > By treating the preferences as a table of key-value pairs, we can
 > easily extend the list of elements with plug-in modules without
 > having to change the data handling or display mechanisms.

Ah so you don't mean what I wrote above, you want to represent
preferences as a table with

row = preference-owning-entity att_name att_key

?
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Abhilash,

Thanks for the summary.

Let me add a bit about what I think we should present in this interface.

First, it should be RESTful and self documenting.

The format of information delivered will be controlled by the http Accept: 
header
The standard representation for communication between various modules of the MM 
system (core, user-manager,webUI, etc.) will be "application/hal+json"


https://server.example.com/mailman/list/ABCDEFG/attribute/join_address returns 
the email address to which subscription requests should be sent.

https://server.example.com/mailman/list/ABCDEFG/attributes

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
 would return the URI representing the list

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
 might return test_list-j...@example.com


See https://gist.github.com/hjr3/2289546 (an E-commerce platform specification) 
to get a representative idea of the json formatting.

I envision the simplified model to have the following core resources:

user -  A person
address - An email address each address is owned by one person
credential - An authentication binding associating a user with an identifier 
such as username/password, browserid, or oAuth

list - A mailing list. Lists have attributes that apply to the list and also 
have a set of preferences which supplies defaults for subscription preferences

subscription - the binding of an email address to a list.

attributes - a dictionary of the parameters that characterize the list

preferences - a dictionary of the parameters that apply to a subscription

I am suggesting two primary differences from the MM core style of 
representation.
First, rather than having multiple attributes and preferences as "columns" in a 
table, I would portray them as multiple rows in a table where the attribute 
names are a key that is used to select the corresponding value.

Additionally, I would generalize the grouping of lists into a hierarchical tree 
that represents the enterprise organization rather than aspects of the internet 
namespace.

By treating the preferences as a table of key-value pairs, we can easily extend 
the list of elements with plug-in modules without having to change the data 
handling or display mechanisms.

Richard

On Apr 26, 2013, at 7:00 PM, Abhilash Raj  wrote:

> Hi all,
> I wrote a brief summary[1] of this thread. Its in the form of notes sorted
> according to participants and a small summary at the end( showing off
> whatever I could understand reading the thread twice from head to toe ).
> However I might have misunderstood ( or not understood at all ) or missed a
> few things, forgive me for that.
> 
> [1]: https://gist.github.com/maxking/5471211
> 
> Thanks,
> Abhilash
> 
> 
> On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda  wrote:
> 
>> So... What have we decided? :)
>> 
>> From my fuzzy "I read my email on a plane after delta woke me up at 3am to
>> tell me my flight was cancelled" level of recollection
>> 
>> The few things I we actually agreed on:
>> 
>> - We like the idea of a rest interface.
>> 
>> - That interface/API should probably be decided now and relatively
>> permanently
>> 
>> - then implementation details can be changed later as necessary (so it
>> doesn't matter if we start with Django or whether mailman-user reads from
>> mailman-core or vice versa, as long as it gets done and fulfills the
>> promises of the API)
>> 
>> - something something oauth something
>> 
>> Can someone sketch out what that REST interface will look like as an
>> actual architectural document that we can comment on?  I don't care who
>> does this; we just need somewhere to start, so any subscriber to this list
>> can probably summarize the emails into a useful document.
>> 
>> Terri
>> 
>> 
>> 
>> __**_
>> Mailman-Developers mailing list
>> Mailman-Developers@python.org
>> 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/raj.abhilash1%**40gmail.com
>> 
>> Security Policy: http://wiki.list.org/x/QIA9
>> 
> 
> 
> 
> -- 
> Abhilash Raj
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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/rkw%40dataplex.net
> 
> Security Policy: http:

Re: [Mailman-Developers] Architecture for extra profile info

[Abhilash Raj]

Hi all,
I wrote a brief summary[1] of this thread. Its in the form of notes sorted
according to participants and a small summary at the end( showing off
whatever I could understand reading the thread twice from head to toe ).
However I might have misunderstood ( or not understood at all ) or missed a
few things, forgive me for that.

[1]: https://gist.github.com/maxking/5471211

Thanks,
Abhilash


On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda  wrote:

> So... What have we decided? :)
>
> From my fuzzy "I read my email on a plane after delta woke me up at 3am to
> tell me my flight was cancelled" level of recollection
>
> The few things I we actually agreed on:
>
> - We like the idea of a rest interface.
>
> - That interface/API should probably be decided now and relatively
> permanently
>
> - then implementation details can be changed later as necessary (so it
> doesn't matter if we start with django or whether mailman-user reads from
> mailman-core or vice versa, as long as it gets done and fulfills the
> promises of the API)
>
> - something something oauth something
>
> Can someone sketch out what that REST interface will look like as an
> actual architectural document that we can comment on?  I don't care who
> does this; we just need somewhere to start, so any subscriber to this list
> can probably summarize the emails into a useful document.
>
>  Terri
>
>
>
> __**_
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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/raj.abhilash1%**40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>



-- 
Abhilash Raj
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Terri Oda]

So... What have we decided? :)

From my fuzzy "I read my email on a plane after delta woke me up at 3am 
to tell me my flight was cancelled" level of recollection


The few things I we actually agreed on:

- We like the idea of a rest interface.

- That interface/API should probably be decided now and relatively 
permanently


- then implementation details can be changed later as necessary (so it 
doesn't matter if we start with django or whether mailman-user reads 
from mailman-core or vice versa, as long as it gets done and fulfills 
the promises of the API)


- something something oauth something

Can someone sketch out what that REST interface will look like as an 
actual architectural document that we can comment on?  I don't care who 
does this; we just need somewhere to start, so any subscriber to this 
list can probably summarize the emails into a useful document.


 Terri


___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Barry Warsaw writes:

 > but also remember how much pain we had at the sprint trying to get Postorius
 > and HyperKitty deployed together (how's that coming by the way?).

I got mail from Yarko, does that help? :-)

I hope to get back to that this week, now that I've initialized my
classes.  Dunno if Yarko has done anything, or if anyone else is
working on it.

 > Eventually OAuth is a good idea and I'm not aware of anything else
 > that fits the bill as well, for authenticated scripting of REST
 > APIs.  But we probably don't need it for now.

We don't *need* anything we don't already have :-), but I'd like to
see OAuth and Persona for subscribers.

 > One important requirement is that for any data that is kept in both the core
 > and the user database, we must have a way of keeping them in sync.  The
 > easiest way of doing that I think is to allow two way communication between
 > them so that if data changes in the core (e.g. an address gets verified by
 > reply instead of link-click), the core can inform the user database of this
 > event.

This isn't going to fly for enterprise usage.  I mean, you can inform
the enterprise DB, but it's highly unlikely to do anything useful with
the information.  I think in the core "user" has to be a rather
abstract class, which provides links to profile information (perhaps
in a Mailman-supplied component, or in an enterprise DB, or both[1]),
and to list-related information.

Footnotes: 
[1]  UI note: if both, enterprises may want "official" information to
be visually distinguished from "unofficial" information.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Barry Warsaw writes:

 > It's also probably true that few people actually use the email command
 > interface - heck even I rarely use it.

Emacs and (some) Debian folks do, though.  It's not random, there are
whole constituencies (small) out there for this feature.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:
 > On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull  wrote:
 > > Richard Wackerbarth writes:

 > >> Since we consider the user manager to be a part of the MM complex,
 > >> what have we gained by hiding the underlying credential from the
 > >> web interface?
 > > 
 > > Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
 > > SHOULD level) this practice.
 > 
 > RFC 6749 addresses the implementation of an OAuth authorization
 > system.
 > 
 > In this context, SHOULD refers to the implementation of this RFC.
 > 
 > It does not imply that other authorization schemes also need to
 > meet those same criteria.

True, but logically irrelevant: it does not mean that the
recommendations of the RFC are irrelevant in the design of
authorization schemes.

OAuth has reasons for recommending that you avoid passing user-
supplied credentials around.  These include (among others I haven't
the imagination to supply here, I'm sure)

(1) privacy of the user (the component the user wants access to may
have no need to know who the user is)
(2) security of the user credentials (leaking the auth token does not
allow an attacker to access all resources the user is authorized
for)
(3) the accessed component doesn't know the importance of the user
credentials (the user may have used the same password in several
systems, or the user may have very high privileges in other parts
of this system), increasing the risk involved in (2).

I see no reason to suppose Mailman is not subject to these
considerations.  (3) is certainly relevant, as I know that I am
simultaneously a site owner, a list owner, a moderator, and a
subscriber for some lists.

There is a plausible workflow in which a user (who happens to be a
list owner) who is browsing the archives is given a subscriber-level
token, and when they decide to access a list admin page, they need to
re-authenticate to upgrade their authorization to list owner.  If they
then access a non-admin page, or they time out before accessing
another admin page, the owner-level token is downgraded to a
subscriber token.  (This is like sudo on POSIX systems.)

I'm not arguing that Mailman should default to such a workflow, but I
think we should be able to support it.  Passing around user
credentials makes it harder to audit such a workflow.

 > As for security, exposing the authorization server to direct
 > Internet access is, in itself, a security weak point.

I wouldn't say necessarily "weak", but it certainly expands the attack
surface that needs to be defended.  That's why I don't want to include
an auth server implemented by security amateurs (us!)

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

On Apr 19, 2013, at 10:22 AM, Stephen J. Turnbull wrote:

> > 2) use some other authentication method.
>
>What's wrong with HTTPS + Basic Auth?

Oh, one thing about HTTPS + Basic Auth.  Right now, MM3 core has only one
admin user and password for access to its REST API.  So it can't be used to
authenticate individual users, only the "root" user of the REST API.

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

On Apr 18, 2013, at 09:39 PM, Florian Fuchs wrote:

>I think in this case it makes sense to spend a more time on the API as
>seen from the outside (urls, methods, json responses) than the actual
>implementation. If the API is good, it's totally acceptable if the
>underlying implementation will be redesigned later.

+1

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

On Apr 18, 2013, at 10:26 AM, Terri Oda wrote:

>I thinks case, case we have to be *much* more conservative about
>dependencies.  I think Django would be right out as a dependency for Mailman
>core, for example.  Plus, we're going to have to care a lot more about speed
>and all.

Definitely.  However (and I'm not saying it has to be this way ;) if the user
database were a Django app, and there were REST APIs that the core could call
to do updates, then when something in the core changes, an event would get
triggered that would make the RESTish call to update the user database.
Similarly, when something in the user database changes that the core needs to
know about, it would call the core's REST API to make that change.

We would have to design something that would be robust enough to deal with
failures, but I think it could be done.

>2. The user module reads from mm-core and augments it.
>
>This gives us the ability to supplement mm-core without impeding speed.  We
>discussed possibly filling in the blanks with respect to things like the user
>preferences (which are currently set by membership, by user and by email
>address... but a lot of those return an empty set when queried if nothing is
>set directly there...) so this is maybe something we already want.
>
>Conceptually, #1 is probably easier because everything will be in one place,
>but if we do #2 right, we can make it just as conceptually easy for
>HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  That
>does mean in case 2 that Mailman Extraneous User Stuff is going to depend on
>Mailman Core, though.

Which I think is fine for now.  Without the core, what do you have? :)

>a) It doesn't add any dependencies to Mailman core.

>b) It doesn't require big changes in Mailman Core.  Given that core is pretty
>much ready to release, now would be a bad time for changes, and I'm just not
>sure we can justify that amount of work for the types of features that will
>be built on the extraneous user stuff.

>c) It will be much easier to rip this out and replace it when we better
>understand our actual needs.  (e.g. Right now, I think a case could be made
>that a quick mock-up in django would be fine, but I suspect that requiring
>django for some potential applications would border on ridiculous)

>We're probably going to be running around with a bit of a hack job for the
>user database in the near future (either done by a student who needs it in a
>hurry or done by one of the core devs to support a student who needs it in a
>hurry) so while I don't like to design on the assumption it's going to go
>wrong, I think in this case planning for a redesign might be prudent because
>it's pretty clear we don't actually know all our requirements.

+1

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

My main suggestion for now is to be very careful and not over-engineer the
user database component.  Provide something minimal that fits the bill and has
a minimum of security, e.g. basic-auth over localhost, and possibly https.

For now, I think it would be fine as a Django app if that makes things easier,
but also remember how much pain we had at the sprint trying to get Postorius
and HyperKitty deployed together (how's that coming by the way?).

OTOH, do the easiest thing that will allow our GSoC students to succeed but
that doesn't box us in later.  E.g. providing a REST API makes sense, and it's
okay if there aren't fancy UI to change the schema (unless it's easy using
Django).

Eventually OAuth is a good idea and I'm not aware of anything else that fits
the bill as well, for authenticated scripting of REST APIs.  But we probably
don't need it for now.

One important requirement is that for any data that is kept in both the core
and the user database, we must have a way of keeping them in sync.  The
easiest way of doing that I think is to allow two way communication between
them so that if data changes in the core (e.g. an address gets verified by
reply instead of link-click), the core can inform the user database of this
event.  Eventually, we can think about how the core would just share that
information or delegate to the user database, but for now, and for the GSoC
students, it's probably overkill.

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

On Apr 19, 2013, at 07:18 AM, Richard Wackerbarth wrote:

>Are you starting to come around to the concept that I have been advocating
>for a long time?

It's always been part of my thinking, and it's most evident in the use of
interfaces internally.  Time will tell whether we've accomplished that or
not.

However, it's also important to realize that probably the vast majority of
users who roll their own just install what we give them and go (well, most
likely with their stack of distro patches).  So I think in that case, it still
makes sense for the core to provide, by default, a minimally useful user
database, as it does today.

>I ask that you consideration the following as it applies to that view: First,
>as viewed from the other side (the enterprise, etc.), your same concerns
>apply to accessing their "user". For example, when you store the user
>password, how do they assure availability and consistency?

It's a great question, which I cannot answer.  My opinion is that we have to
let such enterprise users drive that development, while we give them an
architecture that supports their use cases.

>Second, particularly if you separate the administration functions, "core"
>message handling should, at most, rarely care about the "user"
>information. The subscription information, which seldom changes, should
>contain sufficient information to handle the time-critical task of message
>dispatch.

Our users (specifically IUser) is extremely minimal.  A user consists of a
display name, a password[1], an id, and a "created on" date.  There are some
additional methods or properties which are just convenient APIs for queries
and membership updates, but really it's not much more than a way to collate a
set of registered addresses under one unit.

-Barry

[1] With Persona, we can *probably* get rid of the password.  It's only going
to be used to do authenticated email commands, but it sucks for security.
It's also probably true that few people actually use the email command
interface - heck even I rarely use it.  It's important to keep, but I think it
would be better to base that on OpenPGP rather than plain text passwords.


signature.asc
Description: PGP signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Barry,

Are you starting to come around to the concept that I have been advocating for 
a long time?

In particular, rather than "owning" the user information, "core" simply views 
it.

I assume that you are reluctant to store "foreign keys" to external databases 
because you worry that consistency might be broken when another process alters 
the database.

I ask that you consideration the following as it applies to that view:
First, as viewed from the other side (the enterprise, etc.), your same concerns 
apply to accessing their "user". For example, when you store the user password, 
how do they assure availability and consistency?

Second, particularly if you separate the administration functions, "core" 
message handling should, at most, rarely care about the "user" information. The 
subscription information, which seldom changes, should contain sufficient 
information to handle the time-critical task of message dispatch.

Richard
 
On Apr 18, 2013, at 8:20 PM, Barry Warsaw  wrote:

> Terri, thanks for kicking off this discussion!
> 
> On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:
> 
>> On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
>>> Main comment: Sounds like LDAP to me.
> 
>> Actually, this is a really important comment.  I was sort of wondering that
>> too when I started writing the description.  LDAP is a moderately frequently
>> requested feature already.  Would it make sense to use that probably rather
>> than rest, or make a rest framework that talked to ldap under the hood?
> 
> I agree that this is a really interesting suggestion.
> 
> What's interesting to me about it is that this acknowledges that
> administrative control of this extra user information may fall to folks not at
> all directly involved in mailing list administration.
> 
> You can imagine that a company would already have their LDAP database of
> additional user information, from postal addresses, to phone numbers, to IRC
> handles, pictures and icons, birthdays, etc.  Further, I can imagine that if
> that company were to be running MM3 and HyperKitty, they'd probably not want
> to duplicate that information in multiple databases, they'd just want to pull
> the pictures and IRC nicks out of LDAP.  For their purposes, their LDAP
> database *is* their user database.
> 
> Of course, some of that information may also be used in part or in whole for
> the core, e.g. display names (which actually are useful in places, such as
> crafting the From header for a virgin notification).
> 
> Now, at least conceptually, I've always thought about the user database as one
> of the three pillars of information in the core, the other two being the list
> database and the message store.  This is why for example subscriptions do not
> just link a foreign key for the mlist to a foreign key to the address, because
> this would not allow for separation of these two pillars[1].
> 
> Furthermore, the use of interfaces internally is meant to allow for
> alternative implementations of the lowest database layer of these pillars,
> without affecting any functionality above it.  So let's say even in the core,
> user passwords, display names, and preferences were kept in LDAP.  An
> alternative implementation of user.py would pull the data in from there and as
> long as it satisfied the syntactic and semantic APIs of the IUser interface,
> everything else in MM3 would continue to work.
> 
> You could extend this to the idea expressed elsewhere that the core could use
> this external user database.  Why not?  The external user database could be
> accessible over REST or a via a database server, etc.  We'd need an
> implementation of the underlying data objects that could talk to this user
> database and satisfy the interfaces, and that should be all you'd need.
> Making it performant enough for the core is just an engineering exercise
> .
> 
> -Barry
> 
> [1] Whether any of this works or has the right separation is another matter
> entirely. ;)  For example, looking at it now, I'm not so sure Members
> shouldn't be part of the MailingList pillar rather than the user database
> pillar.
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> Since we consider the user manager to be a part of the MM complex,
>> what have we gained by hiding the underlying credential from the
>> web interface?
> 
> Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
> SHOULD level) this practice.

RFC 6749 addresses the implementation of an OAuth authorization system.

In this context, SHOULD refers to the implementation of this RFC.

It does not imply that other authorization schemes also need to meet those same 
criteria.

As for security, exposing the authorization server to direct Internet access 
is, in itself, a security weak point.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Barry Warsaw writes:

 > What's interesting to me about it is that this acknowledges that
 > administrative control of this extra user information may fall to
 > folks not at all directly involved in mailing list administration.

I think this is crucial to World Domination^W^WMailman 3 uptake.

 > Now, at least conceptually, I've always thought about the user
 > database as one of the three pillars of information in the core,
 > the other two being the list database and the message store.

I like this conceptual division, but I admit I haven't thought too
carefully about what goes where (eg, you mention Members).
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Since we consider the user manager to be a part of the MM complex,
 > what have we gained by hiding the underlying credential from the
 > web interface?

Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
SHOULD level) this practice.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

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
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

Terri, thanks for kicking off this discussion!

On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:

>On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
>> Main comment: Sounds like LDAP to me.

>Actually, this is a really important comment.  I was sort of wondering that
>too when I started writing the description.  LDAP is a moderately frequently
>requested feature already.  Would it make sense to use that probably rather
>than rest, or make a rest framework that talked to ldap under the hood?

I agree that this is a really interesting suggestion.

What's interesting to me about it is that this acknowledges that
administrative control of this extra user information may fall to folks not at
all directly involved in mailing list administration.

You can imagine that a company would already have their LDAP database of
additional user information, from postal addresses, to phone numbers, to IRC
handles, pictures and icons, birthdays, etc.  Further, I can imagine that if
that company were to be running MM3 and HyperKitty, they'd probably not want
to duplicate that information in multiple databases, they'd just want to pull
the pictures and IRC nicks out of LDAP.  For their purposes, their LDAP
database *is* their user database.

Of course, some of that information may also be used in part or in whole for
the core, e.g. display names (which actually are useful in places, such as
crafting the From header for a virgin notification).

Now, at least conceptually, I've always thought about the user database as one
of the three pillars of information in the core, the other two being the list
database and the message store.  This is why for example subscriptions do not
just link a foreign key for the mlist to a foreign key to the address, because
this would not allow for separation of these two pillars[1].

Furthermore, the use of interfaces internally is meant to allow for
alternative implementations of the lowest database layer of these pillars,
without affecting any functionality above it.  So let's say even in the core,
user passwords, display names, and preferences were kept in LDAP.  An
alternative implementation of user.py would pull the data in from there and as
long as it satisfied the syntactic and semantic APIs of the IUser interface,
everything else in MM3 would continue to work.

You could extend this to the idea expressed elsewhere that the core could use
this external user database.  Why not?  The external user database could be
accessible over REST or a via a database server, etc.  We'd need an
implementation of the underlying data objects that could talk to this user
database and satisfy the interfaces, and that should be all you'd need.
Making it performant enough for the core is just an engineering exercise
.

-Barry

[1] Whether any of this works or has the right separation is another matter
entirely. ;)  For example, looking at it now, I'm not so sure Members
shouldn't be part of the MailingList pillar rather than the user database
pillar.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > I have no problem with, and actually encourage, that we act as a
 > consumer of oAuth credentials.

+1

 > However, the issue here is whether we should be provider of oAuth
 > credentials (which might then be presented to some outside, totally
 > unrelated, entity.

-1

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Perhaps I didn't understand you.  I thought that you were
 > advocating the omission of any channels other than "shell" and
 > "localhost".

I'm saying that we should make appropriate Mailman components be OAuth
clients (subject to site policy, per component), but try to avoid
providing *any* authentication ourselves (localhost relies on existing
shell access mechanisms via OS or SSH etc, HTTP Basic auth relies on
Apache or other webserver, OAuth we'll have to build in, but the
actual authentication is done by 3rd party providers).  I suppose
we'll have to provide moderation-by-password-in-headers and the
traditional triple-handshake-by-mail for backward compatibility.

Ah - I missed a very important channel: secure mail via OpenPGP.  We
need something like that (but again, the actual auth/auth process is
done by GPG or PGP, we just rely on the token (signature) provided as
a valid identification of a user).

 > I was trying to point out that HTTPS, oAuth, etc. should be equally
 > viable (and they don't REQUIRE that the components reside on the
 > shame host).

I don't think anybody is opposed to exploring distributed
architecture, and that implies securing inter-component
communications.  The question is how much of the security architecture
we should provide ourselves.  I advocate restricting that to the bare
minimum, by which I mean "we don't *do* anything we don't *need* to do
ourselves", not "we don't reimplement functionality that is available
in Python packages or 3rd-party libraries we can wrap".



___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

What I am suggesting is that we use the JSON format and URLs that are generated 
by this combination.
If you later decide to implement it in a different framework, you can still use 
the same external representation.

On Apr 18, 2013, at 4:33 PM, Florian Fuchs  wrote:

> 2013/4/18 Richard Wackerbarth :
>> Yes, yes. Please re-invent the wheel once again.
>> 
>> And while you are at it, you might just remove the dependancies on zope and 
>> storm, etc.
>> 
>> I think that you are missing the point that, at this time, this is intended 
>> to provide the capabilities that MM-core chooses not to implement.
>> Those website components (HK and Postorius) are being driven by Django and 
>> you only make it more difficult to implement them when choose a different 
>> schema to model/present the data.
> 
> I don't want to re-invent the wheel and I don't advocate dismissing
> Django. Django is probably perfect for the prototype. It might also be
> perfect for the final thing. But we don't know what database we're
> gonna use in the end (which determines if the Django ORM still fits),
> or if we'll use many HTML templates etc. If we end up not using many
> of the things that make Django great, we might wanna think about if we
> want to use it. And might still come to the conclusion that we do. All
> I'm saying is: The environment for such an app could be a little
> different to Postorius/HK, so let's spend some thought on it. Is this
> such a bad idea?
> 
> Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Richard Wackerbarth :
> Yes, yes. Please re-invent the wheel once again.
>
> And while you are at it, you might just remove the dependancies on zope and 
> storm, etc.
>
> I think that you are missing the point that, at this time, this is intended 
> to provide the capabilities that MM-core chooses not to implement.
> Those website components (HK and Postorius) are being driven by Django and 
> you only make it more difficult to implement them when choose a different 
> schema to model/present the data.

I don't want to re-invent the wheel and I don't advocate dismissing
Django. Django is probably perfect for the prototype. It might also be
perfect for the final thing. But we don't know what database we're
gonna use in the end (which determines if the Django ORM still fits),
or if we'll use many HTML templates etc. If we end up not using many
of the things that make Django great, we might wanna think about if we
want to use it. And might still come to the conclusion that we do. All
I'm saying is: The environment for such an app could be a little
different to Postorius/HK, so let's spend some thought on it. Is this
such a bad idea?

Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 1:54 PM, Florian Fuchs  wrote:

> 2013/4/18 Richard Wackerbarth :
>> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
>> kerberos, etc.) were protocols whereby one system (the provider) furnishes 
>> credentials for a second system (the client) to some third system (the 
>> consumer).
>> 
>> By configuration, the consumer trusts that the provider has verified the 
>> client's identity and furnished appropriate credentials.
>> Thus, when the client presents credentials in an interaction with the 
>> consumer, the consumer provides services on the basis of the credentials.
>> 
>> If we assume that we distribute the MM implementation to include more than 
>> the two (core and web UI) systems by having, for example, a user manager, 
>> there might be an argument for passing around such credentials.
> 
> I was primarily thinking about the (future) authenticated REST API in
> Postorius. In that scenario a third party web app that we don't know
> would request an access token from the user profile store (provider)
> as well a user's email address. It would then use that access token
> for requests to the Postorius API (consumer).
> 
> 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.
> 
> or
> 
> 2) use some other authentication method.
> 
> 
> 1) is odd in my opinion. Mailman is free software. And there are not
> too many oauth providers that match that philosophy.
> 2) would be totally great if we found something that doesn't require a
> user to provide his credentials to said 3rd party app.

Look at what happens now.  The user contacts Postorius and presents either some 
oAuth/BrowserID-style credential or it presents a username/password. In 
exchange, Postorius issues a local credential (session key).

When the username/password path is chosen, Postorius acts as an agent for the 
user and verifies the login. In this case, Postorius must "see" the underlying 
credential (username/password pair) to be able to present it to the 
authenticator.  In the oAuth path, Postorius never sees the underlying 
credential, but exchanges the presented one for its local credential.

Since we consider the user manager to be a part of the MM complex, what have we 
gained by hiding the underlying credential from the web interface?

Therefore, I would suggest that we need to be able to accept third-party 
(oAuth) credentials and also locally presented ones.
I don't see where we gain an advantage by exposing the authenticator as a 
separate oAuth provider.


> I don't know. Maybe I'm missing something. And of course I agree with
> Stephen: If it's too hairy in terms of security, we should not do it.
> 
> 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... ?).
> 
> Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Yes, yes. Please re-invent the wheel once again.

And while you are at it, you might just remove the dependancies on zope and 
storm, etc.

I think that you are missing the point that, at this time, this is intended to 
provide the capabilities that MM-core chooses not to implement.
Those website components (HK and Postorius) are being driven by Django and you 
only make it more difficult to implement them when choose a different schema to 
model/present the data.

On Apr 18, 2013, at 2:29 PM, Florian Fuchs  wrote:

> 2013/4/18 Richard Wackerbarth :
>> On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:
>>> 3) It doesn't need Django.
>>> Since it will not deliver any HTML (except an oAuth login form -- see
>>> 5.) and it doesn't need to be integrated into any existing web site,
>>> we can choose a more light-weight framework.
>> 
>> Here I take exception. Dismissing Django is a restriction that unnecessarily 
>> affects the ease of implementation and, in the common case, complicates the 
>> integration of the functionality.
>> 
>> Although it could be implemented without Django, it could also be 
>> implemented as a Django "app".
>> An instance of a django server can then serve the functionality.  As an 
>> alternative, where appropriate, this "app" would directly "drop in" to an 
>> instance of Postorius or an enterprise website.
>> 
>> One of the advantages of Django is that it can be used as a rapid 
>> prototyping mechanism. Simplified interfaces to the data are "free" and more 
>> elaborate ones can be added in an incremental fashion.
>> Also, rather than writing custom modules for things such as authentication 
>> and REST interfaces, there is the large community of third-party extensions 
>> which readily integrate to provide that functionality.
> 
> It's not that I don't want to use Django. I just wanted to point out
> that we won't need much of it for a pure JSON API. OTOH adding a new
> dependency by using another framework is probably not a good idea
> either. So if we want to keep the number of dependencies low, the
> alternative would probably be to use no framework at all and use
> restish for the, well, REST stuff (or whatever library the core will
> be using in the future).
> 
> Florian
> 
>> I would advocate that this "User" module make it appear as if stores the 
>> entire "record" for the user.
>> In the implementation, it could actually store parts of the user information 
>> in multiple databases (one of which could be the MM-core).
> 
> +1

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 2:39 PM, Florian Fuchs  wrote:

> 2013/4/18 Terri Oda :
>> We're probably going to be running around with a bit of a hack job for the
>> user database in the near future (either done by a student who needs it in a
>> hurry or done by one of the core devs to support a student who needs it in a
>> hurry) so while I don't like to design on the assumption it's going to go
>> wrong, I think in this case planning for a redesign might be prudent because
>> it's pretty clear we don't actually know all our requirements.
> 
> I think in this case it makes sense to spend a more time on the API as
> seen from the outside (urls, methods, json responses) than the actual
> implementation. If the API is good, it's totally acceptable if the
> underlying implementation will be redesigned later.

I agree and I would advocate that that API model be based on the interface that 
you can readily get from
a django database model and the django-rest-framework.

There is a big advantage to being able to readily edit the model and have the 
corresponding changes to the interface automatically generated. Since HK and 
Postorius already use Django, you are not adding any significant dependancies. 
And you can leverage a existing code base for the implementation details.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Terri Oda :
> We're probably going to be running around with a bit of a hack job for the
> user database in the near future (either done by a student who needs it in a
> hurry or done by one of the core devs to support a student who needs it in a
> hurry) so while I don't like to design on the assumption it's going to go
> wrong, I think in this case planning for a redesign might be prudent because
> it's pretty clear we don't actually know all our requirements.

I think in this case it makes sense to spend a more time on the API as
seen from the outside (urls, methods, json responses) than the actual
implementation. If the API is good, it's totally acceptable if the
underlying implementation will be redesigned later.

Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Terri Oda]

On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:

Main comment: Sounds like LDAP to me.
Actually, this is a really important comment.  I was sort of wondering 
that too when I started writing the description.  LDAP is a moderately 
frequently requested feature already.  Would it make sense to use that 
probably rather than rest, or make a rest framework that talked to ldap 
under the hood?


 Terri

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Richard Wackerbarth :
> On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:
>> 3) It doesn't need Django.
>> Since it will not deliver any HTML (except an oAuth login form -- see
>> 5.) and it doesn't need to be integrated into any existing web site,
>> we can choose a more light-weight framework.
>
> Here I take exception. Dismissing Django is a restriction that unnecessarily 
> affects the ease of implementation and, in the common case, complicates the 
> integration of the functionality.
>
> Although it could be implemented without Django, it could also be implemented 
> as a Django "app".
> An instance of a django server can then serve the functionality.  As an 
> alternative, where appropriate, this "app" would directly "drop in" to an 
> instance of Postorius or an enterprise website.
>
> One of the advantages of Django is that it can be used as a rapid prototyping 
> mechanism. Simplified interfaces to the data are "free" and more elaborate 
> ones can be added in an incremental fashion.
> Also, rather than writing custom modules for things such as authentication 
> and REST interfaces, there is the large community of third-party extensions 
> which readily integrate to provide that functionality.

It's not that I don't want to use Django. I just wanted to point out
that we won't need much of it for a pure JSON API. OTOH adding a new
dependency by using another framework is probably not a good idea
either. So if we want to keep the number of dependencies low, the
alternative would probably be to use no framework at all and use
restish for the, well, REST stuff (or whatever library the core will
be using in the future).

Florian

> I would advocate that this "User" module make it appear as if stores the 
> entire "record" for the user.
> In the implementation, it could actually store parts of the user information 
> in multiple databases (one of which could be the MM-core).

+1
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Richard Wackerbarth :
> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
> kerberos, etc.) were protocols whereby one system (the provider) furnishes 
> credentials for a second system (the client) to some third system (the 
> consumer).
>
> By configuration, the consumer trusts that the provider has verified the 
> client's identity and furnished appropriate credentials.
> Thus, when the client presents credentials in an interaction with the 
> consumer, the consumer provides services on the basis of the credentials.
>
> If we assume that we distribute the MM implementation to include more than 
> the two (core and web UI) systems by having, for example, a user manager, 
> there might be an argument for passing around such credentials.

I was primarily thinking about the (future) authenticated REST API in
Postorius. In that scenario a third party web app that we don't know
would request an access token from the user profile store (provider)
as well a user's email address. It would then use that access token
for requests to the Postorius API (consumer).

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.

or

2) use some other authentication method.


1) is odd in my opinion. Mailman is free software. And there are not
too many oauth providers that match that philosophy.
2) would be totally great if we found something that doesn't require a
user to provide his credentials to said 3rd party app.

I don't know. Maybe I'm missing something. And of course I agree with
Stephen: If it's too hairy in terms of security, we should not do it.

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... ?).

Florian
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:26 AM, Terri Oda  wrote:

> On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
>> On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:
>> 
>>> 1) It should be self-contained.
>>> Meaning: It should not depend on any
>>> mailman/mailman.client/postorius/hyperkitty packages.
>> Agreed
> 
> I agree about not needing postorious/hyperkitty, but I think a case could be 
> made that interdependence with mailman core and mailman client might make 
> sense.

Clearly, if you are going to follow (2) below, you will need to interface to 
MM-core for the portion that is stored there.

>> I would advocate that this "User" module make it appear as if stores the 
>> entire "record" for the user.
>> In the implementation, it could actually store parts of the user information 
>> in multiple databases (one of which could be the MM-core).
>> 
>> This would also allow the option of having the MM-core become a client of 
>> this User module, just as it now relies on an external message store.

Notice that I indicate that this is an option.  Although, in the long run, I 
think it is the right way to go, getting there can be a migration and not 
something that needs to happen all at once.
> 
> Two options occur to me:
> 
> 1. The user module is what mm-core uses for all user stuff.
> 
> I thinks case, case we have to be *much* more conservative about 
> dependencies.  I think Django would be right out as a dependency for Mailman 
> core, for example.

I thought that we were viewing this as a service accessed through a REST 
interface. MM core need never know if it is implemented using Django or FORTRAN 
or ...

Why is depending on some part of Django prohibited when core uses zope, storm, 
... ?
Dependencies are just dependencies. As long as they are stable and readily 
available, why not use those that are useful?

>  Plus, we're going to have to care a lot more about speed and all.

Much of the user information is not needed in the message handler (where speed 
is a consideration).

Functions such as administration-by-mail that need to access the information 
are much less critical.
Further, I will argue that those functions should be factored out of the "core" 
and exist as separate components.

> 2. The user module reads from mm-core and augments it.
> 
> This gives us the ability to supplement mm-core without impeding speed.  We 
> discussed possibly filling in the blanks with respect to things like the user 
> preferences (which are currently set by membership, by user and by email 
> address... but a lot of those return an empty set when queried if nothing is 
> set directly there...) so this is maybe something we already want.
> 
> Conceptually, #1 is probably easier because everything will be in one place, 
> but if we do #2 right, we can make it just as conceptually easy for 
> HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  That 
> does mean in case 2 that Mailman Extraneous User Stuff is going to depend on 
> Mailman Core, though.
> 
> My preference is #2:

I would agree except to the extent that Postorius references the user 
information.
I believe that all user data should be accessed from the same source. I 
consider it poor design for the consumer of data to have to keep track of where 
particular parts of the data are stored.

> a) It doesn't add any dependencies to Mailman core.
> b) It doesn't require big changes in Mailman Core.  Given that core is pretty 
> much ready to release, now would be a bad time for changes, and I'm just not 
> sure we can justify that amount of work for the types of features that will 
> be built on the extraneous user stuff.
> c) It will be much easier to rip this out and replace it when we better 
> understand our actual needs.   (e.g. Right now, I think a case could be made 
> that a quick mock-up in django would be fine, but I suspect that requiring 
> django for some potential applications would border on ridiculous)
> 
> We're probably going to be running around with a bit of a hack job for the 
> user database in the near future (either done by a student who needs it in a 
> hurry or done by one of the core devs to support a student who needs it in a 
> hurry) so while I don't like to design on the assumption it's going to go 
> wrong, I think in this case planning for a redesign might be prudent because 
> it's pretty clear we don't actually know all our requirements.
> 
> Terri
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 12:21 PM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
>> On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  
>> wrote:
>> 
>>> Richard Wackerbarth writes:
>> 
 There is no reason why alternate channels [to a connection from
 localhost authorized by the OS] cannot be substituted as long as a
 means of identification (such as shared secrets) is utilized.
>>> 
>>> Sure, but didn't you notice the elephant in the room as you swept it
>>> under the rug?  The implementation of "alternate channels" matters *a
>>> lot*, and it's not trivial.
>> 
>> Just because something is important or non-trivial to implement
>> properly does not imply that it is difficult for us to utilize it.
>> Rather than developing our own, we can, and should, leverage the
>> efforts of "the professionals" and use the tools that they provide
>> (such as https and oAuth, etc.).
>> 
>> Certainly, the proper administration of each, and every, host is an
>> essential element to prevent access "on the coat tails" of the
>> trusted agents. But that also applies to the "localhost"
>> implementation.
> 
> I don't understand what you're advocating, your comments are way too
> general.
> 
> My position is that secure authentication and authorization is a hard
> problem, and we should avoid doing that as much as possible (partly
> because as far as I know none of us are experts).  No channels that
> few sites will use, ditto OAuth providers.  Concentrate on a couple of
> channels with specific, well-understood, universal (or at least very
> common) use cases.
> 
> The channels I have in mind are (1) shell access, (2) Basic Auth over
> HTTPS for people who need to control access fairly tightly, and (3)
> OAuth and/or Persona clients allowing authentication by any of a
> number of public providers for user (especially subscriber)
> convenience.  I'm not wedded to any of those (except (1), for obvious
> reasons), but I don't think it's a good idea to extend the list if we
> can avoid it.

Perhaps I didn't understand you.  I thought that you were advocating the 
omission of any channels other than "shell" and "localhost".
I was trying to point out that HTTPS, oAuth, etc. should be equally viable (and 
they don't REQUIRE that the components reside on the shame host).
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
>> persona, kerberos, etc.) were protocols whereby one system (the
>> provider) furnishes credentials for a second system (the client) to
>> some third system (the consumer).
> 
> That's correct.
> 
>> If we assume that we distribute the MM implementation to include
>> more than the two (core and web UI) systems by having, for example,
>> a user manager, there might be an argument for passing around such
>> credentials.
> 
> But the does provide a user manager, and the "extra profile info" is
> in fact intended to be a user manager external to the core.
> 
>> Thus, although we need some level of authentication of the agent,
>> there is no need for third party credentials such as those
>> implemented in oAuth.
> 
> The point is that in many cases we would like to dispense with the
> agent authentication process altogether, and let a third party manage
> that.  This is perfectly acceptable in the case of open subscription
> lists where we simply want to ensure that only the subscriber can
> change their subscriptions.  For example, a person subscribing a Gmail
> account to use that account's credentials rather than creating new
> owns inside of Mailman -- which we trust only because the person
> demonstrates in a roundabout way that they can access that mailbox.
> OAuth allows us to make that check directly in real time.

I have no problem with, and actually encourage, that we act as a consumer of 
oAuth credentials.
However, the issue here is whether we should be provider of oAuth credentials 
(which might then be presented to some outside, totally unrelated, entity.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:
 > On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  
 > wrote:
 > 
 > > Richard Wackerbarth writes:
 > 
 > >> There is no reason why alternate channels [to a connection from
 > >> localhost authorized by the OS] cannot be substituted as long as a
 > >> means of identification (such as shared secrets) is utilized.
 > > 
 > > Sure, but didn't you notice the elephant in the room as you swept it
 > > under the rug?  The implementation of "alternate channels" matters *a
 > > lot*, and it's not trivial.
 > 
 > Just because something is important or non-trivial to implement
 > properly does not imply that it is difficult for us to utilize it.
 > Rather than developing our own, we can, and should, leverage the
 > efforts of "the professionals" and use the tools that they provide
 > (such as https and oAuth, etc.).
 > 
 > Certainly, the proper administration of each, and every, host is an
 > essential element to prevent access "on the coat tails" of the
 > trusted agents. But that also applies to the "localhost"
 > implementation.

I don't understand what you're advocating, your comments are way too
general.

My position is that secure authentication and authorization is a hard
problem, and we should avoid doing that as much as possible (partly
because as far as I know none of us are experts).  No channels that
few sites will use, ditto OAuth providers.  Concentrate on a couple of
channels with specific, well-understood, universal (or at least very
common) use cases.

The channels I have in mind are (1) shell access, (2) Basic Auth over
HTTPS for people who need to control access fairly tightly, and (3)
OAuth and/or Persona clients allowing authentication by any of a
number of public providers for user (especially subscriber)
convenience.  I'm not wedded to any of those (except (1), for obvious
reasons), but I don't think it's a good idea to extend the list if we
can avoid it.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:

>> There is no reason why alternate channels [to a connection from
>> localhost authorized by the OS] cannot be substituted as long as a
>> means of identification (such as shared secrets) is utilized.
> 
> Sure, but didn't you notice the elephant in the room as you swept it
> under the rug?  The implementation of "alternate channels" matters *a
> lot*, and it's not trivial.

Just because something is important or non-trivial to implement properly does 
not imply that it is difficult for us to utilize it.
Rather than developing our own, we can, and should, leverage the efforts of 
"the professionals" and use the tools that they provide (such as https and 
oAuth, etc.).

Certainly, the proper administration of each, and every, host is an essential 
element to prevent access "on the coat tails" of the trusted agents. But that 
also applies to the "localhost" implementation.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
 > persona, kerberos, etc.) were protocols whereby one system (the
 > provider) furnishes credentials for a second system (the client) to
 > some third system (the consumer).

That's correct.

 > If we assume that we distribute the MM implementation to include
 > more than the two (core and web UI) systems by having, for example,
 > a user manager, there might be an argument for passing around such
 > credentials.

But the does provide a user manager, and the "extra profile info" is
in fact intended to be a user manager external to the core.

 > Thus, although we need some level of authentication of the agent,
 > there is no need for third party credentials such as those
 > implemented in oAuth.

The point is that in many cases we would like to dispense with the
agent authentication process altogether, and let a third party manage
that.  This is perfectly acceptable in the case of open subscription
lists where we simply want to ensure that only the subscriber can
change their subscriptions.  For example, a person subscribing a Gmail
account to use that account's credentials rather than creating new
owns inside of Mailman -- which we trust only because the person
demonstrates in a roundabout way that they can access that mailbox.
OAuth allows us to make that check directly in real time.

I suppose that what Florian is thinking is that some owners want
*closed* subscription processes, and therefore want to control the
authentication process themselves.  I agree that that is a valid and
likely (if unusual) use case.  I just think it's better for such users
to go find a provider implementation themselves, rather than offer
them something that I know *I* can't properly design or review, and
haven't seen credentials from anyone else on the team that they can do
it, either.

 > There is no reason why alternate channels [to a connection from
 > localhost authorized by the OS] cannot be substituted as long as a
 > means of identification (such as shared secrets) is utilized.

Sure, but didn't you notice the elephant in the room as you swept it
under the rug?  The implementation of "alternate channels" matters *a
lot*, and it's not trivial.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Terri Oda]

On 13-04-18 8:03 AM, Richard Wackerbarth wrote:

On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:


1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.

Agreed


I agree about not needing postorious/hyperkitty, but I think a case 
could be made that interdependence with mailman core and mailman client 
might make sense.

I would advocate that this "User" module make it appear as if stores the entire 
"record" for the user.
In the implementation, it could actually store parts of the user information in 
multiple databases (one of which could be the MM-core).

This would also allow the option of having the MM-core become a client of this 
User module, just as it now relies on an external message store.


Two options occur to me:

1. The user module is what mm-core uses for all user stuff.

I thinks case, case we have to be *much* more conservative about 
dependencies.  I think Django would be right out as a dependency for 
Mailman core, for example.  Plus, we're going to have to care a lot more 
about speed and all.


2. The user module reads from mm-core and augments it.

This gives us the ability to supplement mm-core without impeding speed.  
We discussed possibly filling in the blanks with respect to things like 
the user preferences (which are currently set by membership, by user and 
by email address... but a lot of those return an empty set when queried 
if nothing is set directly there...) so this is maybe something we 
already want.


Conceptually, #1 is probably easier because everything will be in one 
place, but if we do #2 right, we can make it just as conceptually easy 
for HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  
That does mean in case 2 that Mailman Extraneous User Stuff is going to 
depend on Mailman Core, though.


My preference is #2:
a) It doesn't add any dependencies to Mailman core.
b) It doesn't require big changes in Mailman Core.  Given that core is 
pretty much ready to release, now would be a bad time for changes, and 
I'm just not sure we can justify that amount of work for the types of 
features that will be built on the extraneous user stuff.
c) It will be much easier to rip this out and replace it when we better 
understand our actual needs.   (e.g. Right now, I think a case could be 
made that a quick mock-up in django would be fine, but I suspect that 
requiring django for some potential applications would border on ridiculous)


We're probably going to be running around with a bit of a hack job for 
the user database in the near future (either done by a student who needs 
it in a hurry or done by one of the core devs to support a student who 
needs it in a hurry) so while I don't like to design on the assumption 
it's going to go wrong, I think in this case planning for a redesign 
might be prudent because it's pretty clear we don't actually know all 
our requirements.


 Terri

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Florian Fuchs writes:

 > 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.

I'm not dismissing the use; I'm saying an authentication provider is
out of scope for Mailman, for several reasons.

An auth client is something we clearly need.  The mail auth we use
(plain text passwords) is clearly weak, and we need to improve that.
Web auth is probably OK for most sites if we use HTTP Basic Auth over
HTTPS.  OAuth (or "social auth" or Persona) is clearly a major
convenience for users, and probably significantly increases security
all by itself (no need for Post-Its with the Mailman password you
almost never use on your monitor bezel).  Both HTTPS+BasicAuth and
OAuth have the advantage that Mailman can delegate the handling of
transmission of secrets over the Internet to professions.  Given that
HTTPS+BasicAuth is probably good enough for most of our users, and
most of the rest will want to use Google/Yahoo/whatever rather than
YAP, where's the need for a provider?

And I *am* thinking about the possibilities implementing a provider
opens up.  Namely, the possibility that we'll distribute buggy code.
:-P

 > 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.

The OAuth2 protocol spec (RFC 6749) makes obscure reference to "scope"
and tokens acceptable to multiple resource servers.  But I don't think
sharing authorizations is something that a provider deals with.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:

> Hi,
> 
> some first thoughts on it:
> 
> 1) It should be self-contained.
> Meaning: It should not depend on any
> mailman/mailman.client/postorius/hyperkitty packages.

Agreed

> 2) Like the core, it should implement a Python-based webserver.
> It doesn't need to run on Ports 80/443, so we don't have to care about
> one of the popular web servers already listening to those ports.
> Also, we definitely don't want admins to have to follow another "how
> to setup mailman.users with Apache/mod_wsgi" howto.
> It should just run if someone says "start" (Maybe it can even hook
> into $ bin/mailman start? I know, that contradicts item 1. ...).

Where it runs is something that should be easily configurable as a part of 
installation.
To simplify installation, I would advocate that all of the MM subsystem 
interfaces become self-documentating.
By doing so, much of the configuration could be done through a "discovery" 
mechanism.

That would provide an easy way to have modular plug-in extensions.
It would also provide a way for Postorius to automatically adapt to the 
addition of configuration settings or user fields.

> 3) It doesn't need Django.
> Since it will not deliver any HTML (except an oAuth login form -- see
> 5.) and it doesn't need to be integrated into any existing web site,
> we can choose a more light-weight framework.

Here I take exception. Dismissing Django is a restriction that unnecessarily 
affects the ease of implementation and, in the common case, complicates the 
integration of the functionality.

Although it could be implemented without Django, it could also be implemented 
as a Django "app".
An instance of a django server can then serve the functionality.  As an 
alternative, where appropriate, this "app" would directly "drop in" to an 
instance of Postorius or an enterprise website.

One of the advantages of Django is that it can be used as a rapid prototyping 
mechanism. Simplified interfaces to the data are "free" and more elaborate ones 
can be added in an incremental fashion.
Also, rather than writing custom modules for things such as authentication and 
REST interfaces, there is the large community of third-party extensions which 
readily integrate to provide that functionality.

> 4) Adding new content types for user records should be easy, but
> clearly defined.
> We don't know what information applications need to store. Icons,
> essays, avatars, IRC handles, Twiter names, ...
> So we might think about using a schema-less database, but: We don't
> want to make it possible to just manipulate the result JSON and POST
> it back to the resource, possible deleting things other apps need. So
> adding new information types should be a separate process.
> 
> 5) It should implement an oAuth provider.
> This could be used for API authenticaion and to log into
> Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
> We won't need this for a first prototype though. For now we're
> probably fine with 6)
> 
> 6) Like the core it should be accessible with BasicAuth from localhost.
> Ideally, in the future, it should be accessible both via BasicAuth
> from localhost and via oAuth from the outside world...
> 
> Please correct me where I'm being stupid!
> 
> Florian

> 2013/4/18 Terri Oda :
>> Background for folk new to this discussion:
>> 
>> Currently, all user information is stored in Mailman core, but it's minimal:
>> a real name, a set of email addresses, subscription info, and preferences.
>> Barry suggests that it should stay minimal: only the things Mailman needs to
>> know to correctly deliver mail (which actually doesn't include "real name"
>> but let's leave that as a legacy item for the moment)

I would advocate that this "User" module make it appear as if stores the entire 
"record" for the user.
In the implementation, it could actually store parts of the user information in 
multiple databases (one of which could be the MM-core).

This would also allow the option of having the MM-core become a client of this 
User module, just as it now relies on an external message store.

>> It's pretty likely that future features of Mailman will want to attach extra
>> information to users.  Some of it will be social-y stuff like user icons for
>> HyperKitty to display in the archives. Other things include metrics like
>> "when did this person last post to the list?" or "how many posts have they
>> made over the lifetime of this list?"  One thing I know of is that Systers
>> requires a short essay for all new subscribers, explaining why they want to
>> join the list.   (And they're considering porting this feature to Postorius,
>> which means we potentially want an answer to "where will the extra profile
>> data get stored?" before their students start coding.)
>> 
>> So...
>> 
>> I think we've sort of agreed that it would be best if whatever we built just
>> had a rest interface and hyperkitty/postorius/whatever would talk to it
>> thr

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
kerberos, etc.) were protocols whereby one system (the provider) furnishes 
credentials for a second system (the client) to some third system (the 
consumer).

By configuration, the consumer trusts that the provider has verified the 
client's identity and furnished appropriate credentials.
Thus, when the client presents credentials in an interaction with the consumer, 
the consumer provides services on the basis of the credentials.

If we assume that we distribute the MM implementation to include more than the 
two (core and web UI) systems by having, for example, a user manager, there 
might be an argument for passing around such credentials.

However, the design that has been followed thus far does not have the client 
communicating directly with the consumer system. Instead, the web UI interacts 
as an agent for the client. In this model, we have implicitly trusted the agent 
to properly represent the client and also screen client requests in accordance 
with system policy. Thus, although we need some level of authentication of the 
agent, there is no need for third party credentials such as those implemented 
in oAuth.

A connection on "localhost" is a form of credential. Trusting that the OS 
design restricts access to the connection, and trusting the applications 
running on that host provides a level of identification and trust.

There is no reason why alternate channels cannot be substituted as long as a 
means of identification (such as shared secrets) is utilized.
In those cases, the security of the communication channel and the 
trustworthiness of the agent system need to be considered. However, in a 
logical sense, the interaction is the same as one using the localhost channel.


On Apr 18, 2013, at 4:27 AM, Florian Fuchs  wrote:

> 2013/4/18 Stephen J. Turnbull :
>> 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 authentication 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
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

2013/4/18 Stephen J. Turnbull :
> 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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Main comment: Sounds like LDAP to me.

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.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[Florian Fuchs]

Hi,

some first thoughts on it:

1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.

2) Like the core, it should implement a Python-based webserver.
It doesn't need to run on Ports 80/443, so we don't have to care about
one of the popular web servers already listening to those ports.
Also, we definitely don't want admins to have to follow another "how
to setup mailman.users with Apache/mod_wsgi" howto.
It should just run if someone says "start" (Maybe it can even hook
into $ bin/mailman start? I know, that contradicts item 1. ...).

3) It doesn't need Django.
Since it will not deliver any HTML (except an oAuth login form -- see
5.) and it doesn't need to be integrated into any existing web site,
we can choose a more light-weight framework.

4) Adding new content types for user records should be easy, but
clearly defined.
We don't know what information applications need to store. Icons,
essays, avatars, IRC handles, Twiter names, ...
So we might think about using a schema-less database, but: We don't
want to make it possible to just manipulate the result JSON and POST
it back to the resource, possible deleting things other apps need. So
adding new information types should be a separate process.

5) It should implement an oAuth provider.
This could be used for API authenticaion and to log into
Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
We won't need this for a first prototype though. For now we're
probably fine with 6)

6) Like the core it should be accessible with BasicAuth from localhost.
Ideally, in the future, it should be accessible both via BasicAuth
from localhost and via oAuth from the outside world...

Please correct me where I'm being stupid!

Florian





2013/4/18 Terri Oda :
> Background for folk new to this discussion:
>
> Currently, all user information is stored in Mailman core, but it's minimal:
> a real name, a set of email addresses, subscription info, and preferences.
> Barry suggests that it should stay minimal: only the things Mailman needs to
> know to correctly deliver mail (which actually doesn't include "real name"
> but let's leave that as a legacy item for the moment)
>
> It's pretty likely that future features of Mailman will want to attach extra
> information to users.  Some of it will be social-y stuff like user icons for
> HyperKitty to display in the archives. Other things include metrics like
> "when did this person last post to the list?" or "how many posts have they
> made over the lifetime of this list?"  One thing I know of is that Systers
> requires a short essay for all new subscribers, explaining why they want to
> join the list.   (And they're considering porting this feature to Postorius,
> which means we potentially want an answer to "where will the extra profile
> data get stored?" before their students start coding.)
>
> So...
>
> I think we've sort of agreed that it would be best if whatever we built just
> had a rest interface and hyperkitty/postorius/whatever would talk to it
> through there, and could share data that way, but we need a simple prototype
> that folk (particularly students) will be able to start using, and there's
> still some internal architecture decisions that need to be made.
>
> Does anyone have time to build such a thing or write up some short
> architectural documents so a student could build such a thing in relatively
> short order?  It doesn't have to be the perfect final design, but we
> probably need a basic starter api for adding, accessing, editing and
> possibly even removing profile data.
>
> Thoughts?
>
>  Terri
>
>
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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/f%40state-of-mind.de
>
> Security Policy: http://wiki.list.org/x/QIA9
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

Re: [Mailman-Developers] Architecture for extra profile info

[varun sharma]

+1 for this, i am desperately waiting for someone to do do this :)


On Thu, Apr 18, 2013 at 5:51 AM, Terri Oda  wrote:

> Background for folk new to this discussion:
>
> Currently, all user information is stored in Mailman core, but it's
> minimal: a real name, a set of email addresses, subscription info, and
> preferences.  Barry suggests that it should stay minimal: only the things
> Mailman needs to know to correctly deliver mail (which actually doesn't
> include "real name" but let's leave that as a legacy item for the moment)
>
> It's pretty likely that future features of Mailman will want to attach
> extra information to users.  Some of it will be social-y stuff like user
> icons for HyperKitty to display in the archives. Other things include
> metrics like "when did this person last post to the list?" or "how many
> posts have they made over the lifetime of this list?"  One thing I know of
> is that Systers requires a short essay for all new subscribers, explaining
> why they want to join the list.   (And they're considering porting this
> feature to Postorius, which means we potentially want an answer to "where
> will the extra profile data get stored?" before their students start
> coding.)
>
> So...
>
> I think we've sort of agreed that it would be best if whatever we built
> just had a rest interface and hyperkitty/postorius/whatever would talk to
> it through there, and could share data that way, but we need a simple
> prototype that folk (particularly students) will be able to start using,
> and there's still some internal architecture decisions that need to be made.
>
> Does anyone have time to build such a thing or write up some short
> architectural documents so a student could build such a thing in relatively
> short order?  It doesn't have to be the perfect final design, but we
> probably need a basic starter api for adding, accessing, editing and
> possibly even removing profile data.
>
> Thoughts?
>
>  Terri
>
>
> __**_
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> 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/varunsharmalive%**40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>
___
Mailman-Developers mailing list
Mailman-Developers@python.org
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

[Mailman-Developers] Architecture for extra profile info

[Terri Oda]

Background for folk new to this discussion:

Currently, all user information is stored in Mailman core, but it's 
minimal: a real name, a set of email addresses, subscription info, and 
preferences.  Barry suggests that it should stay minimal: only the 
things Mailman needs to know to correctly deliver mail (which actually 
doesn't include "real name" but let's leave that as a legacy item for 
the moment)


It's pretty likely that future features of Mailman will want to attach 
extra information to users.  Some of it will be social-y stuff like user 
icons for HyperKitty to display in the archives. Other things include 
metrics like "when did this person last post to the list?" or "how many 
posts have they made over the lifetime of this list?"  One thing I know 
of is that Systers requires a short essay for all new subscribers, 
explaining why they want to join the list.   (And they're considering 
porting this feature to Postorius, which means we potentially want an 
answer to "where will the extra profile data get stored?" before their 
students start coding.)


So...

I think we've sort of agreed that it would be best if whatever we built 
just had a rest interface and hyperkitty/postorius/whatever would talk 
to it through there, and could share data that way, but we need a simple 
prototype that folk (particularly students) will be able to start using, 
and there's still some internal architecture decisions that need to be 
made.


Does anyone have time to build such a thing or write up some short 
architectural documents so a student could build such a thing in 
relatively short order?  It doesn't have to be the perfect final design, 
but we probably need a basic starter api for adding, accessing, editing 
and possibly even removing profile data.


Thoughts?

 Terri


___
Mailman-Developers mailing list
Mailman-Developers@python.org
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