Create a 2-legged OAuth sample, including adding support if needed about dotnetopenauth HOT 19 CLOSED

This work is now in progress in the sample2legged branch.

from dotnetopenauth.

Is this branch available? I have a direct access scenario where I need to implement the service and consumer...

from dotnetopenauth.

@infitude I've just published the branch. Please provide your feedback as I primarily need someone to successfully use it before it can merge into the mainline.

from dotnetopenauth.

As a reference - I have a 2 legged example working with Googles GData API libraries - successfully querying calendar adding contacts which validates the consumerKey and consumerSecret I'm using. Now, when I run the GoogleApps2Legged example I get an exception (see below) - it looks like it's trying to establish a SSL channel and request a token - is this the correct behavior? The GData API sample doesn't do any 'handshake' for a token, just sets the Authorization Header..should we be calling RequestNewClientAccount ?

CONNECT www.google.com:443 HTTP/1.1
Host: www.google.com

The data sent represents an SSLv3-compatible ClientHello handshake. For your convenience, the data is extracted below.

Major Version: 3
Minor Version: 1
Random: 4D BC A5 C1 49 48 1B E0 0A 44 41 95 6E E9 E6 BF BA 29 1E C5 F1 D5 47 EC 5F 05 02 88 CA 7F 8C 9C
SessionID: A4 78 6A F7 A4 CC 25 18 83 BD 47 1D 7E 12 55 69 09 4D 82 5C 82 C8 28 B1 77 9F 19 D6 7F AF 67 6D
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5

[WebException: The remote server returned an error: (400) Bad Request.]
System.Net.HttpWebRequest.GetResponse() +5373789
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options) in C:\Projects\DotNetOpenAuth\2legged\src\DotNetOpenAuth\Messaging\StandardWebRequestHandler.cs:126

[ProtocolException: Error occurred while sending a direct message or getting the response.]
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options) in C:\Projects\DotNetOpenAuth\2legged\src\DotNetOpenAuth\Messaging\StandardWebRequestHandler.cs:172
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request) in C:\Projects\DotNetOpenAuth\2legged\src\DotNetOpenAuth\Messaging\StandardWebRequestHandler.cs:100
DotNetOpenAuth.Messaging.Channel.GetDirectResponse(HttpWebRequest webRequest) in C:\Projects\DotNetOpenAuth\2legged\src\DotNetOpenAuth\Messaging\Channel.cs:607

from dotnetopenauth.

I think there may be two very different ideas of what "two-legged OAuth" is. I just ran across http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html which claims to describe two-legged OAuth but I count 0 legs.
My idea of two-legged OAuth is that the consumer, which presumably has a consumer key but not necessarily any consumer secret (because in these scenarios the client rarely can keep secrets from their users), obtains a request token (leg #1), then skips the authorization step, and immediately exchanges the request token for an access token (leg #2). That's what DotNetOpenAuth's RequestNewClientAccount method does.

from dotnetopenauth.

We have implemented a two-legged oAuth DotNetOpenAuth server, and are now creating a sample for our customers. Did the two-legged sample discussed above get merged into the mainline?

from dotnetopenauth.

Hi Terry,

The branch hasn't yet been merged into the master branch. I'd love to do so, after it's validated that it works. If you can validate it by building a 2-legged OAuth consumer from the sample2legged branch, and report back, that would be awesome!

from dotnetopenauth.

Hi Andrew,

I have successfully used the sample2legged branch to connect to our two leg DotNetOpenAuth server, and was able to successfully do a GET and POST to the server.

FYI, if you aren't already aware, there are some compilation errors in the DotNetOpenAuth.Test project that should be addressed before merging into the mainline.

Please let me know when you plan to check this in, as I would like to send our customers to DotNetOpenAuth to build their OAuth consumer code.

Thanks!
Terry

from dotnetopenauth.

Awesome. Thanks for the testing. I'll fix the build breaks and merge into the v3.4 branch.

from dotnetopenauth.

v3.4 now has this change.

from dotnetopenauth.

By the way, an official nightly build of v3.4 with this change will be available tomorrow from http://teamcity.dotnetopenauth.net/viewType.html?buildTypeId=bt49&tab=buildTypeStatusDiv

from dotnetopenauth.

Thanks Andrew! It's been a pleasure working with you.

from dotnetopenauth.

One additional question for you. What was your intention with the ApplicationBlock project? Because many of the methods in the ApplicationBlock are internal, when I deploy my sample application I have the following options:

1. Download the source, add my TrakopolisConsumer.cs, compile the ApplicationBlock and include it with my sample application.
2. Add my TrakopolisConsumer.cs to the open source solution

Is there another solution you can think of that would allow me to reference the ApplicationBlock, and extend it in my application?

from dotnetopenauth.

The ApplicationBlock project is delivered in source code form so you can
copy and paste files or classes directly into your web site project and
tweak them all you want (as opposed to the compiled dotnetopenauth.dll,
which should be extensible in its binary form for all your needs).

That said, if there is something marked "internal" that would be more
convenient to access as "public", I'm quite happy to entertain changing
it. If you can tell me which ones you want to access externally but
can't, I can look into it.

On 6/10/2011 8:19 AM, terrymandin wrote:

One additional question for you. What was your intention with the ApplicationBlock project? Because many of the methods in the ApplicationBlock are internal, when I deploy my sample application I have the following options:

1. Download the source, add my TrakopolisConsumer.cs, compile the ApplicationBlock and include it with my sample application.
2. Add my TrakopolisConsumer.cs to the open source solution

Is there another solution you can think of that would allow me to reference the ApplicationBlock, and extend it in my application?

from dotnetopenauth.

I downloaded version 3.4.8.11161 from http://teamcity.dotnetopenauth.net/viewType.html?buildTypeId=bt49&tab=buildTypeStatusDiv. When I ran it I got the message:

The following required parameters were missing from the DotNetOpenAuth.OAuth.Messages.AuthorizedTokenRequest message: oauth_verifier.

I don't get this message when I run using the branch though. If there is some debugging you would like me to try, let me know and I will down load the latest mainline.

from dotnetopenauth.

Can you activate logging and send the logs?

from dotnetopenauth.

hi Andrew,

I hope that you are well. We're just implementing some 2Legged stuff just now.

We're on v3.4.7.11121 but RequestNewClientAccount in WebConsumer does not seem to exist?

What version should we be working with?

Thanks as always!

UPDATE: I got everything working in v3.4.8, thanks again :)

from dotnetopenauth.

That new method isn't in any released version of DNOA, but you can download
a v3.4.8 prerelease (which should be quite stable) from
http://teamcity.dotnetopenauth.net/

On Thursday, September 1, 2011, iaineh wrote:

hi Andrew,

I hope that you are well. We're just implementing some 2Legged stuff just
now.

We're on v3.4.7.11121 but RequestNewClientAccount in WebConsumer does not
seem to exist?

What version should we be working with?

Thanks as always!

Reply to this email directly or view it on GitHub:
#20 (comment)

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

from dotnetopenauth.

Thanks, I was able to do that and everything is working perfectly. Against a 3.4.7 server release too which is great!

Thanks again

Sent from my iPhone

On 1 Sep 2011, at 16:28, "AArnott" [email protected] wrote:

That new method isn't in any released version of DNOA, but you can download
a v3.4.8 prerelease (which should be quite stable) from
http://teamcity.dotnetopenauth.net/

On Thursday, September 1, 2011, iaineh wrote:

hi Andrew,

I hope that you are well. We're just implementing some 2Legged stuff just
now.

We're on v3.4.7.11121 but RequestNewClientAccount in WebConsumer does not
seem to exist?

What version should we be working with?

Thanks as always!

Reply to this email directly or view it on GitHub:
#20 (comment)

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

Reply to this email directly or view it on GitHub:
#20 (comment)

from dotnetopenauth.