"No OpenID endpoint found." exceptions during startup of OpenIdProvider and OpenIdRelayingParty

[Werner Strydom]

Consider two websites, "accounts.example.com" which is an openid provider and "app.example.com" which is an openid relaying provider both using version 4.0.1.12097 of the dotnetopenauth framework. 

Assume the websites was never visited before, or that IIS was restarted, or ASP.NET is compiling the site because something changed. When visiting "app.example.com" and trying to sign in, it almost always throws a ProtocolException with an exception "No OpenID endpoint found".  The exception orginates from the call "

return _openid.CreateRequest(value).RedirectingResponse.AsActionResult();

And the stack trace looks as follows:

[InvalidOperationException: Sequence contains no elements]
System.Linq.Enumerable.First(IEnumerable`1 source) +498
DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.CreateRequest(Identifier userSuppliedIdentifier) +64 

[ProtocolException: No OpenID endpoint found.]
DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.CreateRequest(Identifier userSuppliedIdentifier) +187
MyApp.Controllers.OpenIdRelyingPartyController.SignIn(String returnUrl) 

[OpenIdRelayingPartyException: Unable to create open id request]
MyApp.Controllers.OpenIdRelyingPartyController.SignIn(String returnUrl) 
lambda_method(Closure , ControllerBase , Object[] ) +127
System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters) +260
System.Web.Mvc.Async.<>c__DisplayClass42.<BeginInvokeSynchronousActionMethod>b__41() +40
System.Web.Mvc.Async.<>c__DisplayClass39.<BeginInvokeActionMethodWithFilters>b__33() +129
System.Web.Mvc.Async.<>c__DisplayClass4f.<InvokeActionMethodFilterAsynchronously>b__49() +882151
System.Web.Mvc.Async.<>c__DisplayClass37.<BeginInvokeActionMethodWithFilters>b__36(IAsyncResult asyncResult) +15
System.Web.Mvc.Async.<>c__DisplayClass2a.<BeginInvokeAction>b__20() +33
System.Web.Mvc.Async.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult) +882732
System.Web.Mvc.<>c__DisplayClass1d.<BeginExecuteCore>b__18(IAsyncResult asyncResult) +28
System.Web.Mvc.Async.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) +20
System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult) +67
System.Web.Mvc.Async.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) +20
System.Web.Mvc.Controller.EndExecute(IAsyncResult asyncResult) +53
System.Web.Mvc.<>c__DisplayClassb.<BeginProcessRequest>b__4(IAsyncResult asyncResult) +42
System.Web.Mvc.Async.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) +20
System.Web.Mvc.<>c__DisplayClasse.<EndProcessRequest>b__d() +54
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +469
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +375

If we visit the website again to sign in, it works as expected.  The source of this issue seems to stem from the time it takes for the openid provider to respond back.  If one takes the sample ASP.NET MVC open id provider and artificially delay the response by 30 seconds whenever the XRDS documents are requested or in the OpenIdProvider.Provider method, then the open id relaying party (app.example.com) will fail.  

So I suspect that we may experience intermittent failures depending on the response times of the open id provider and this may actually be very hard to track given the logs and the exception message being thrown.  What is possibly worse, is from a usability standpoint, we do not know that this failure is due to slow response times and thus cannot provide the user with an appropriate message (such as "We are experiencing some delays and cannot process your request right now"). 

Has anyone else experienced this behavior? Is there something one can set to make the relaying party more resilient to slow response times?  If not, should we consider this a defect?

Werner

[Andrew Arnott]

You've correctly identified this as a timeout issue.  A balance in the timeout is desirable, since a timeout that is too long makes your site more vulnerable to DoS attacks because all your web server threads are tied up waiting for a network response that is deliberately slow.  And you know what happens when the timeout is too short.

The only solution I know of is for you to adjust the dial to what suits you.  DotNetOpenAuth allows you to set that timeout.  The easiest place is in your web.config file, shown below with the default values:

<dotNetOpenAuth>

<messaging>

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

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/DlGxaFEI4dcJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
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

[Werner Strydom]

Thanks.

May I ask how you determined the default values?  It seems to be a tad to aggressive for ASP.NET startup times (as in my case with two applications).  I'm a tad concerned what would happened if the application pool gets recycled (which is common during certain times during the day) and the impact it may have on the whole usability of sign in process.  

Another question is whether it is possible to report a different error. While the above case may pose some challenges (as processing DOS attacks appropriately) and may be infrequent, it does create the wrong impression with consumers.  My experience (working in insurance, banking and other businesses) is that it is better to attempt to retry an operation and let the user wait than simply fail.  Users seem to be tolerant to a slow system that still performs it task than a system that fails and fails quickly.  

Even looking at the logs there isn't anything to help an operations engineer understand why the RP couldn't connect to the OP.  Then there is the question of how many users are experiencing this issue and whether it is a result of a DOS attack on the OP or simply the fact that its 07:45AM the morning in NYC and 1000 users tried to sign in and the OP isn't responding in time because it was starting up for the time the day.  For the latter, I'll argue that usability of the consumer should have priority.  If there is a DOS attack on the OP and the RP can't get any responses within say 90s then I should be able to provide the user with an appropriate message.  More importantly, operations personell needs to be informed that the system isn't working as expected. 

I'll try to play with the settings you suggested to see what times work for me.

Thanks,

Werner

[Andrew Arnott]

Hi Werner,

Good question.  And I can't say a great deal of science and research went into these values (this is just an open source project after all without a lab to study).  I'd be interested in hearing what your tuning leads you to use as timeout values.

BTW, the timeouts are not optimized for ASP.NET startup times.  Most OpenIDs and services are hosted on highly tuned and performant servers such that timeouts aren't typically an issue (I doubt customers would typically see a timeout with a Google OpenID, for example).  If your customer's OpenIDs tend to be on servers that can be slow to respond, then a larger timeout for that particular web site seems warranted.

As for logs explaining why a login failed rather than simply "no openid endpoint found" when a timeout occurs, I totally agree, and we should be able to fix that.  Please file a ticket for that so it doesn't slip through the cracks.

--
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

Werner

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/m03h8NW5hbgJ.

[Werner Strydom]

Andrew, you are right.  Once the OP is deployed in production it should respond quickly.  Perhaps its time to discuss and obtain a general consensus how errors should be dealt with.

[Werner Strydom]

Andrew,

As you requested, it seems to take approx. 15s - 30s per application to fire up the first time.  The more dependencies, the longer it takes.

Werner

[Andrew Arnott]

Thanks.  And wow, that's a long time.  That seems inexorably long -- much longer than what I could recommend the default timeout be set to.  

Which leaves us with two options for improving the status quo:

1. recognize when timeouts occur and produce an error message to the user that suggests that trying again may work. (this would require a bit of DNOA work to beef up the exception we throw)
2. prime the pump on the recycled web app so that the user doesn't observe these delays.

Both options obviously have their merits and costs.

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/WoMY6sjWLq8J.

To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--

[Werner Strydom]

My opinion is that the focus should be on the end user experience and supportability of solutions built on the framework.  An appropriate exception would go a long way to satisfy those conditions. 

[Andrew Arnott]

Can you file a ticket for this?

--
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

On Mon, Apr 30, 2012 at 7:42 PM, Werner Strydom <blou...@gmail.com> wrote:

My opinion is that the focus should be on the end user experience and supportability of solutions built on the framework.  An appropriate exception would go a long way to satisfy those conditions. 

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/C2h6gKYRF0sJ.