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
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
On Apr 28, 2013, at 11:59 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Richard Wackerbarth writes:
snip
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
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
On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull step...@xemacs.org 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
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
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
On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull step...@xemacs.org 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
On Apr 27, 2013, at 10:36 AM, Stephen J. Turnbull step...@xemacs.org 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
On Apr 28, 2013, at 2: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
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
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
On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
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
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
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
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
On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull step...@xemacs.org 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
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
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
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
Richard Wackerbarth writes:
On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull step...@xemacs.org 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
On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull step...@xemacs.org 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
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*
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,
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
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
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
For OAuth http://en.wikipedia.org/wiki/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
Here is my take on the basic system requirements and design issues:
System Components:
* A RESTful
APIhttps://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_APIs
-
a mini-server that servers restful calls.
* A persistent store - a schemaless or relaxed datasource, e.g.
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
On Apr 27, 2013, at 2:42 AM, Stephen J. Turnbull turnb...@sk.tsukuba.ac.jp
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.
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
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.
Xu Wang writes:
For OAuth http://en.wikipedia.org/wiki/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
On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth r...@dataplex.net 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
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.
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
On Apr 27, 2013, at 8:19 AM, Stephen J. Turnbull step...@xemacs.org 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
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
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
On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
Xu Wang writes:
For OAuth http://en.wikipedia.org/wiki/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
On Sat, Apr 27, 2013 at 4:27 AM, Richard Wackerbarth r...@dataplex.netwrote:
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
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
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
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
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
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
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
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
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
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
Richard Wackerbarth writes:
On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull step...@xemacs.org 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?
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.
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
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
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
2013/4/18 Stephen J. Turnbull step...@xemacs.org:
Florian Fuchs writes:
5) It should implement an oAuth provider.
I don't see this. Mailman is an auth consumer. The only people
Mailman can provide auth for are the site admins. Everybody else is
more or less untrustworthy.
I can see
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
On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com 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
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
On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com 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
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
On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org 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
Richard Wackerbarth writes:
On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org
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
On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org 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
On Apr 18, 2013, at 12:21 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Richard Wackerbarth writes:
On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Richard Wackerbarth writes:
There is no reason why alternate channels [to a connection from
localhost
On Apr 18, 2013, at 11:26 AM, Terri Oda te...@zone12.com wrote:
On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:
1) It should be self-contained.
Meaning: It should not depend on any
2013/4/18 Richard Wackerbarth rich...@nfsnet.org:
On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com 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
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
2013/4/18 Terri Oda te...@zone12.com:
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
On Apr 18, 2013, at 2:39 PM, Florian Fuchs flo.fu...@gmail.com wrote:
2013/4/18 Terri Oda te...@zone12.com:
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
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
On Apr 18, 2013, at 1:54 PM, Florian Fuchs flo.fu...@gmail.com wrote:
2013/4/18 Richard Wackerbarth r...@dataplex.net:
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
2013/4/18 Richard Wackerbarth r...@dataplex.net:
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
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 flo.fu...@gmail.com wrote:
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
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
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
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,
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.
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.
On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull step...@xemacs.org 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
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
83 matches
Mail list logo
