Google OpenId: No OpenID endpoint found (intermittent)
Asked Answered
P

2

9

Usually using the Google OpenId works fine, thousands of times a day, then it will start intermittently going wrong and timing out for an hours or so (some requests will validate but not all). Repeated validation will eventually work.

Error messages are:

Event code: 200000 
Event message: No OpenID endpoint found. : https://www.google.com/accounts/o8/id 

Sequence contains no elements

Adding in log4net yields:

DotNetOpenAuth.Yadis:
Error while performing discovery on: "https://www.google.com/accounts/o8/id": 
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) 
     in  c:\...\Dot...Core\Messaging\StandardWebRequestHandler.cs:line 127    
 --- End of inner exception stack trace ---     
  at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse
     (HttpWebRequest request, DirectWebRequestOptions options) 
     in c:\...\Dot...Core\Messaging\StandardWebRequestHandler.cs:line 175
  at DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse
     (HttpWebRequest request, DirectWebRequestOptions options)
     in c:\...\Dot...Core\Messaging\UntrustedWebRequestHandler.cs:line 250
  at DotNetOpenAuth.Yadis.Yadis.Request
     (IDirectWebRequestHandler requestHandler,
       Uri uri, Boolean requireSsl, String[] acceptTypes) 
     in c:\...\Dot...OpenId\Yadis\Yadis.cs:line 172
  at DotNetOpenAuth.Yadis.Yadis.Discover
     (IDirectWebRequestHandler requestHandler, UriIdentifier uri, Boolean requireSsl)
     in c:\...\DotNetOpenAuth.OpenId\Yadis\Yadis.cs:line 63
  at DotNetOpenAuth.OpenId.UriDiscoveryService.Discover
     (Identifier identifier, IDirectWebRequestHandler requestHandler, 
           Boolean& abortDiscoveryChain) 
     in c:\...\DotNet...OpenId\OpenId\UriDiscoveryService.cs:line 51
  at DotNetOpenAuth.OpenId.IdentifierDiscoveryServices.Discover
     (Identifier identifier) 
     in c:\...\Dot...OpenId\OpenId\IdentifierDiscoveryServices.cs:line 58
  at DotNetOpenAuth.OpenId.RelyingParty.AuthenticationRequest.Create
     (Identifier userSuppliedIdentifier, OpenIdRelyingParty relyingParty,
       Realm realm, Uri returnToUrl, Boolean createNewAssociationsAsNeeded) 
     in ...OpenId.RelyingParty\OpenId\RelyingParty\AuthenticationRequest.cs:line 364

And

DotNetOpenAuth.Http WebException: 
 Timeout from https://www.google.com/accounts/o8/id, no response available.

Any ideas?

Philo answered 8/4, 2012 at 11:7 Comment(3)
Do outbound HTTP requests to other servers succeed reliably during these troubled times?Exegete
Yes as do all the inbound requests.Philo
DotNetOpenAuth.Http WebException Timeout from google.com/accounts/o8/id, no response available. DotNetOpenAuth.Yadis Error while performing discovery on: "google.com/accounts/o8/id": 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() ...Philo
E
2

It sounds like you need to fix your network latency. It seems highly unlikely that Google would be the bottleneck here.

You may also want to increase the HTTP timeouts on your end to reduce the failure rate. The full set of options is available here. Specifically you're probably looking for:

<untrustedWebRequest
            timeout="00:00:10"
            readWriteTimeout="00:00:01.500" />

Check out the configurations link to see the context of where this goes.

Exegete answered 9/6, 2012 at 19:26 Comment(1)
Seemed to be related to DNS server outagesPhilo
H
2

We recently ran into this same issue. Having read several different scenarios and having gone through the trace steps I finally concluded, as I have seen elsewhere that this problem can be caused by a DNS server issue. In our case we had a production server that has been in use for over 18 months and just recently started getting the same issue as mentioned above, but it was very consistent on this one server. Another server on a another network and our development computers did not have any issues.

Long story short I changed the primary DNS for the production server to Google's public DNS, 8.8.8.8 and it instantly started working. I had manually flushed the DNS cache on the production server prior to this (without positive outcome) so it leads me to believe the DNS server (provided by our hosting center) had a bad cache entry that was ultimately causing the problem.

Hope this helps someone else who runs across this scenario.

Humpy answered 17/3, 2014 at 18:39 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.