I'm working on an extension that will do just that. Stay tuned. And no, it does
not compete with OpenID (nor uses it).
EHL
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of jmkrist...@gmail.com
> Sent: Monday, March 16, 2009 9:09 PM
> To:
OAuth doesn't tell a consumer who the user is. I mean, it doesn't
authenticate the user to the consumer. The service provider may
associate access tokens with an authenticated user, but a consumer
can't get this information via OAuth alone. I've heard that people
are working to combine OAuth an
Using the Java library, you can construct an OAuthMessage with method
= OAuthMessage.POST. The library will construct a request body
containing just the OAuthMessage parameters, if you use
ParameterStyle.BODY. Or you can provide the request body, by creating
a subclass of OAuthMessage that retur
OAuthClient.access is often a better choice than OAuthClient.invoke,
for accessing web services. Give it a try. It was added to the
source code -r899, and Maven oauth-core/20090221.
You don't have to use OAuthClient. You can use
net.oauth.http.HttpClient, or the Jakarta Commons HTTP software.
Ok, so I understand the general flow of OAuth and have used it to
connect to services just fine. What I'm wondering is if there is any
plan or standard method for utilizing OAuth as a login strategy for
sites that depend entirely on the OAuth provider for service (i.e.
Twitter-based applications).
Eran Hammer-Lahav wrote:
>
> OAuth Core 1.0 5.2 implies that servers must support all three methods
> since clients will send parameters using one of three methods. The EC
> edition clarifies this a bit and says that clients must use one (and
> only one) of the three methods unless an extensio
Morten Fangel wrote:
> It should be noted that it won't continue to be able to set the
> Authorization-header via JavaScript, so JS-clients will not be able to
> support Authorization-headers in the future..
>
> See the Editors Draft for reference (bullet point #5)
> http://dev.w3.org/2006/weba
It should be noted that it won't continue to be able to set the
Authorization-header via JavaScript, so JS-clients will not be able to
support Authorization-headers in the future..
See the Editors Draft for reference (bullet point #5)
http://dev.w3.org/2006/webapi/XMLHttpRequest/Overview.html#
I misspoke.
OAuth Core 1.0 5.2 implies that servers must support all three methods since
clients will send parameters using one of three methods. The EC edition
clarifies this a bit and says that clients must use one (and only one) of the
three methods unless an extension is used.
Section 4.2
Thanks. That seems to agree with my interpretation.
It would be useful to be explicit in the specification that the server
is not required to accept all three.
Eran Hammer-Lahav wrote:
> OAuth is silent on which method you should use, other than to express
> some weak preference. The server
OAuth is silent on which method you should use, other than to express some weak
preference. The server needs to communicate which methods it supports and the
client must use those.
EHL
On 3/16/09 11:52 AM, "Martin Atkins" wrote:
In section 5.2 of OAuth Core 1.0, and in section 3.4 of Eran
In section 5.2 of OAuth Core 1.0, and in section 3.4 of Eran's "Editor's
Cut" draft, three different mechanisms are listed for encoding request
parameters, implying that support for all three is required. However,
it's not clear to me who this requirement applies to and how it applies.
Here a
On Mon, Mar 16, 2009 at 9:34 AM, Zhihong wrote:
>
> ...
>
> 2. OAuth is a 3-party dance. When a failure is returned from service
> provider (like invalid sig or rejected token), consumer can't simply
> respond to the 401 and continue the exchange. It needs to switch
> context to send an error to
On Fri, Mar 13, 2009 at 6:10 AM, John Kemp wrote:
>
> On Mar 13, 2009, at 8:47 AM, Zhihong wrote:
>
> [...]
>
>>
>> I really like the way OAuth uses Authorization header so you can hide
>> OAuth clutter away from app data. However, the header is not used in
>> the context of HTTP auth. In OAuth,
Hi John,
I have a quick question about the Problem Reporting Extension regarding
the parameter_absent problem. The spec says that missing parameters
should be listed in the oauth_parameter_absent parameter, using & to
separate multiple parameters.
Would it make more sense to use commas to sep
The command line example (OAuthHelper) uses POST.
See more in example/command-line/build.xml
On Mon, Mar 16, 2009 at 5:14 AM, matthias wrote:
>
> Just so I get this right:
>
> There is *no* support in this OAuth implementation which allows you to
> POST something to the server? ^^
>
> I browsed
This could be a server problem also. Not sure if it's related, this
sounds like a problem I discovered in our server.
We had a bug that's only reproducible on PHP client, not Java. It
turns out that the PHP using Curl doesn't do keepalive and the Java
with pool manager does it. The root cause is
You should probably read the new edition of the spec. It will help you better
understand the architecture. Not all the features of OAuth are valuable in a
desktop application but you can very much still use OAuth. And the one call
where a user is involved is not authenticated (using OAuth) so a
There is nothing wrong about the way OAuth uses HTTP auth from HTTP
perspective. However, it doesn't really work with the flow of OAuth.
Here are the few problems you will encounter if you want plug it into
HTTP Auth,
1. OAuth is for server-server call. It will be very hard to make OAuth
call fro
Just so I get this right:
There is *no* support in this OAuth implementation which allows you to
POST something to the server? ^^
I browsed through the docs and source code, struggling to find a
method which actually allows you to set the body of a POST message...
--~--~-~--~~--
This is clearly a problem with the current implementation. Looking at
the source code of OAuthClient.invoke actually turned up this:
...
if (response.getHttpResponse().getStatusCode() !=
HttpResponseMessage.STATUS_OK) {
throw response.toOAuthProblemException();
You are correct. Just looked at the code again and it does seem to
sort the parameters correctly. I missed the magic in URLEncoder.
I will find out why my testcase fails and get back to you if I find
any issues.
Zhihong
On Mar 15, 4:06 pm, jmkrist...@gmail.com wrote:
> Once we clarify sorting,
22 matches
Mail list logo
