I'm trying to upgrade the DotNetOpenAuth verson to 4.2.2.13055, in the Google dotnet client library.
So I downloaded the latest dlls - DotNetOpenAuth.Core, DotNetOpenAuth.OAuth2, etc. (we still don't work with NuGet).
I made a small change (changed the way I construct NativeApplcationClient with client_id and client_secret) to support the new version.
Then, I tried to run a sample we have in our samples repository (e.g. https://code.google.com/p/google-api-dotnet-client/source/browse/Tasks.SimpleOAuth2/Program.cs?repo=samples), and I got a bad request error, as following:
DotNetOpenAuth.Messaging.ProtocolException: Error occurred while sending a direct message or getting the response. --->
System.Net.WebException: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions opt
ions)
--- End of inner exception stack trace ---
at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions opt
ions)
at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request)
at DotNetOpenAuth.Messaging.Channel.GetDirectResponse(HttpWebRequest webRequest)
at DotNetOpenAuth.Messaging.Channel.RequestCore(IDirectedProtocolMessage request)
at DotNetOpenAuth.Messaging.Channel.Request(IDirectedProtocolMessage requestMessage)
at DotNetOpenAuth.OAuth2.ClientBase.UpdateAuthorizationWithResponse(IAuthorizationState authorizationState, EndUserAu
thorizationSuccessAuthCodeResponse authorizationSuccess)
at DotNetOpenAuth.OAuth2.UserAgentClient.ProcessUserAuthorization(IAuthorizationState authorizationState, IDirectedPr
otocolMessage response)
at DotNetOpenAuth.OAuth2.UserAgentClient.ProcessUserAuthorization(Uri actualRedirectUrl, IAuthorizationState authoriz
ationState)
at Google.Apis.Authentication.OAuth2.DotNetOpenAuth.NativeApplicationClient.ProcessUserAuthorization(String authCode,
IAuthorizationState authorizationState) in c:\code.google.com\google-api-dotnet-client\default_oauth2\Src\GoogleApis.Au
thentication.OAuth2\DotNetOpenAuth\NativeApplicationClient.cs:line 102
at Google.Apis.Samples.TasksOAuth2.Program.GetAuthorization(NativeApplicationClient arg) in c:\code.google.com\google
-api-dotnet-client\samples_oauth2\Tasks.SimpleOAuth2\Program.cs:line 73
at Google.Apis.Authentication.OAuth2.OAuth2Authenticator`1.LoadAccessToken() in c:\code.google.com\google-api-dotnet-
client\default_oauth2\Src\GoogleApis.Authentication.OAuth2\OAuth2Authenticator.cs:line 124
I noticed also that there is a different in the second request (in exchanging the code with a token): Authorization header was added to the request, and the body was missing my client_id and client_secret.
Similar code worked on old version - 4.0.0.11165,
Am I missing something?
I wonder if the problem is that the newer DNOA version supports putting client credentials in the HTTP header by default. If you create your Client class, passing in a different client credential provider into the constructor, it may work for you.
To change the behavior from using the HTTP Authorization header back to passing client credentials in the POST entity, instantiate your ClientBase-derived class passing in this as a parameter to the constructor:
ClientCredentialApplicator.PostParameter(clientSecret)
Related
Following the OAuth2 login flow described at https://github.com/reddit/reddit/wiki/OAuth2 I got to the point where POST-ing to https://www.reddit.com/api/v1/access_token returns something like this:
{'token_type': 'bearer', 'expires_in': 3600, 'scope': 'identity', 'access_token': '*****'}
Then I do
GET https://oauth.reddit.com/api/v1/me
With this header:
Authorization: bearer *****
The response is HTTP 403 Unauthorized. But why? It is clear that the access token has 'identity' scope. It is also documented that the /api/v1/me call requires this scope only. (See https://www.reddit.com/dev/api/oauth#GET_api_v1_me )
So why am I getting http 403?
I was experiencing the exact same issue as you described. In my case, I resolved the 403 by adding a faux user agent string in the request headers.
In my case, using HttpClient of C#, this proceeds like so:
using (var client = new HttpClient())
{
client.DefaultRequestHeaders.Add("User-Agent", "MockClient/0.1 by Me");
...
}
In my case this was because of a redirect.
Calling a non-oauth endpoint in my application (like https://www.reddit.com/r/learnpython/about.json) with the Authorization header would fail with code 403. But calling https://reddit.com/r/learnpython/about.json (without www) with the Authorization header succeeded. However both endpoints worked when I tried via Postman.
The reason for this is that reddit.com would redirect to www.reddit.com, which results in the Authorization header being dropped by Postman for the second request. In my application code, I was including the header with both requests, which explains the different behavior.
Solution: don't include the Authorization header when calling non-oauth endpoints.
When I send a comments thread. List request to the YouTube API
I get the following exception "But not for all videos":
Google.GoogleApiException: Google.Apis.Requests.RequestError
The API server failed to successfully process the request.
While this can be a transient error, it usually indicates that the requests input is invalid. Check the structure of the commentThread resource in the request body to ensure that it is valid. [400].
And for those videos I double checked the inputs sent with the request and I
make the request with the same data directly from the YouTube API requests trial section but everything goes right!
I want to know why this request becomes valid on some video ID's but invalid on the others ?
I'll appreciate any help.
Here is the full written log: System.AggregateException: One or more errors occurred. ---> Google.GoogleApiException: Google.Apis.Requests.RequestError
The API server failed to successfully process the request. While this can be a transient error, it usually indicates that the requests input is invalid. Check the structure of the commentThread resource in the request body to ensure that it is valid. [400]
Errors [
Message[The API server failed to successfully process the request. While this can be a transient error, it usually indicates that the requests input is invalid. Check the structure of the commentThread resource in the request body to ensure that it is valid.] Location[body - other] Reason[processingFailure] Domain[youtube.commentThread]
]
at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at Google.Apis.Requests.ClientServiceRequest`1.d__0.MoveNext() in c:\ApiaryDotnet\default\Src\GoogleApis\Apis\Requests\ClientServiceRequest.cs:line 0
--- End of inner exception stack trace ---
CommentThreads.list API doesn't need a request body as indicated in the API reference
Request body
Do not provide a request body when calling this method.
This may have caused the RequestError on your call. Try to remove any objects passed when calling this API, hopefully this would fix the issue.
We are experiencing HTTP CODE = 409 error when we are trying to push our code to the repository. I tried with different IP address and it still doesn't work.
I wonder if there's something wrong with remote side.
Here is the message we got when pushing:
error: RPC failed; result=22, HTTP code = 409
fatal: The remote end hung up unexpectedly
fatal: recursion detected in die handler
Everything up-to-date
Check the Content-Type, like that one application/json. Attached link have a example:
http://blog.app4domain.com/2016/12/got-409-http-return-code-in-jboss.html
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
I am using the Thinktecture.IdentityModel 4.0 samples for WebApiSecurity. I've modified the AdfsSamlClient to use our ADFS Server. I am able to get a SAML token from out ADFS Server using
var channel = factory.CreateChannel();
var token = channel.Issue(rst) as GenericXmlSecurityToken;
Then I try to make the service call
var client = new HttpClient { BaseAddress = _baseAddress };
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("AdfsSaml", saml);
var response = client.GetAsync("identity").Result;
And get a 401 - Not Authorized call.
I am not sure how to debug this. I have tracing for Microsoft.IdentityModel, but it is only information level trace, no errors or warnings, and nothing I am able to use to debug.
The interesting part of the service trace:
1.
Description OnEndRequest is redirection to IdentityProvider '/WebHost/api/identity'
2.
Description CreateSignInRequest
BaseUri https://[ADFS...]/adfs/ls/
wa wsignin1.0
wtrealm https://[WorkStation...]/WebHost/
wctx rm=0&id=passive&ru=%2fWebHost%2fapi%2fidentity
3.
Description Redirecting to IdentityProvider: 'https://[ADFS...]/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2f[WorkStation...]%2fWebHost%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fWebHost%252fapi%252fidentity&wct=2013-09-30T17%3a35%3a04Z'
Thanks for any insight.
Main thing that springs to mind is to make sure the server knows how to handle the "AdfsSaml" scheme that you're using, so you'll want to make sure that your mapping is correct to your token handler.
One thing I tried was to create my own token handler, and mapped that as the token handler for the header. If you want, you can start with Thinktecture's own HttpSamlSecurityTokenHandler, and debug your way through that. Obviously, if it never hits it, then you've got a mapping issue somewhere.
I also found that if an exception was thrown in the ClaimsAuthenticationManager, it would report as unauthorized - even though the exception being thrown was something completely unrelated (in my case, an InvalidCastException). That stumped me for a while, because I hadn't realise that authentication had gotten so far down the pipeline and that validation of the token had actually been successful - I was just checking the HTTP response, which kept saying unauthorised - so make sure you're not being misled by anything trivial like that.
I'm using DotNetOpenAuth 3.5.0.10357 and when attempting to authorize using Yahoo as the provider (https://me.yahoo.com) often times a ProtocolException is thrown at OpenIdRelyingParty.CreateRequest(Identifier). If another attempt is made immediately after the first attempt, the workflow behaves as expected. I've added a XRDS document as per this blog post and when the Yahoo provider responds it seems to detect the file as it no longer displays that verification message. All other providers, with the exception of AOL which has the same issues, work properly at all times. I've enabled logging and there seem to be two different causes, one is a timeout another is a NameResolutionFailure, both from WebException.
Here is the log from the instance resulting in NameResolutionFailure:
HTTP GET https://me.yahoo.com/ WebException NameResolutionFailure from
https://me.yahoo.com/, no response available. Error while performing
discovery on: "https://me.yahoo.com/":
DotNetOpenAuth.Messaging.ProtocolException: Error occurred while
sending a direct message or getting the response. --->
System.Net.WebException: The remote name could not be resolved:
'me.yahoo.com' at System.Net.HttpWebRequest.GetResponse() at
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) --- End of inner
exception stack trace --- at
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) at
DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) at
DotNetOpenAuth.Yadis.Yadis.Request(IDirectWebRequestHandler
requestHandler, Uri uri, Boolean requireSsl, String[] acceptTypes)
at DotNetOpenAuth.Yadis.Yadis.Discover(IDirectWebRequestHandler
requestHandler, UriIdentifier uri, Boolean requireSsl) at
DotNetOpenAuth.OpenId.UriDiscoveryService.Discover(Identifier
identifier, IDirectWebRequestHandler requestHandler, Boolean&
abortDiscoveryChain) at
DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.Discover(Identifier
identifier) at
DotNetOpenAuth.OpenId.RelyingParty.AuthenticationRequest.Create(Identifier
userSuppliedIdentifier, OpenIdRelyingParty relyingParty, Realm realm,
Uri returnToUrl, Boolean createNewAssociationsAsNeeded) Performing
discovery on user-supplied identifier: https://me.yahoo.com/ Filtering
and sorting of endpoints did not affect the list.
The following is the log from a timeout:
HTTP GET https://me.yahoo.com/ WebException Timeout from
https://me.yahoo.com/, no response available. Error while performing
discovery on: "https://me.yahoo.com/":
DotNetOpenAuth.Messaging.ProtocolException: Error occurred while
sending a direct message or getting the response. --->
System.Net.WebException: The operation has timed out at
System.Net.HttpWebRequest.GetResponse() at
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) --- End of inner
exception stack trace --- at
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) at
DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) at
DotNetOpenAuth.Yadis.Yadis.Request(IDirectWebRequestHandler
requestHandler, Uri uri, Boolean requireSsl, String[] acceptTypes)
at DotNetOpenAuth.Yadis.Yadis.Discover(IDirectWebRequestHandler
requestHandler, UriIdentifier uri, Boolean requireSsl) at
DotNetOpenAuth.OpenId.UriDiscoveryService.Discover(Identifier
identifier, IDirectWebRequestHandler requestHandler, Boolean&
abortDiscoveryChain) at
DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.Discover(Identifier
identifier) at
DotNetOpenAuth.OpenId.RelyingParty.AuthenticationRequest.Create(Identifier
userSuppliedIdentifier, OpenIdRelyingParty relyingParty, Realm realm,
Uri returnToUrl, Boolean createNewAssociationsAsNeeded) Performing
discovery on user-supplied identifier: https://me.yahoo.com/ Filtering
and sorting of endpoints did not affect the list.
I'm using the default configuration settings. I'm guessing I cat get around the timeout error by increasing the timeout setting, however I'm not sure how to go about the name resolution error.
From the exception this doesn't look like a DotNetOpenAuth-specific problem to me. It looks like your DNS server is slow or you have a bad connection to it. I'd look into that problem. And yes, increasing the timeout will help you in a pinch.