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

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

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

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" th

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

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 di

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

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

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

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 pro

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

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 th

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

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 e

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

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

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

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* ente

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

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

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

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, bu

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

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 a

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

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

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

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 A

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

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 con

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

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

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

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 o

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

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

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

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" wh

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

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 inv

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

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

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

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

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

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

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

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

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

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 sit

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

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

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

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 detai

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

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 K

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

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 t

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

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 resourc

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

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

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

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

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

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

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

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

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

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 i

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

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 wha

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

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.

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

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 t

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

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 th

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

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 nee

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

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

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

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.

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

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 validatio

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

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 r

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

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

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

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

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

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 v

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

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

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

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

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

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

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

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.

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

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? > > > > S

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

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 auth

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

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 r

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

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

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

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 thing

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

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 o

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

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

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

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) w

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

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

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

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

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

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 har

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

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 des

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

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.

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

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 tr

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

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 Wackerbar

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

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

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

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 som

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

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 c

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

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 wh

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

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 o

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

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 t

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

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 fr

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

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, th

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

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

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

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 th

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

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)

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

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 ident

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

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

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

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

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

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

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

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 ou

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

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

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

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 ver

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

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

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

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 app

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

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

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

+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, subscripti

[Mailman-Developers] Architecture for extra profile info

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 de