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
19 matches
Mail list logo
