AuthenticationHandler.TeardownCoreAsync - Not getting called on exception about security

[Tratcher]

What sort of response action? Does it need to be run even for failed requests?

Most response actions take place in OnSendingHeaders (unless you're buffering or there is no response body).

[BadriL]

Yes, I'm buffering the response and I need to write the buffer back to the network stream even if there is a failure (whatever is in the buffer at that point).

[Tratcher]

If there is a failure I don't think you should write out the buffer, you should let the failed request handling take over instead. That said, you would still need to put the original response stream back in so the error handler could write to it.

I'll take a look at the object model and see if we can call Teardown in a finally block.

[BadriL]

Yes, that's a good point. I need to put the original stream back in. BTW, had I not buffered, the response produced thus far would have gone out isn't it? Is it not correct to write the buffer back? Sure, the error handler should respond back but any pointers on how to go about with the response produced till that point. Just discard?

[Tratcher]

Yes, I would just discard the response in an error case. The error handling logic can produce better results if the response body hasn't been sent yet, and a partial response body isn't useful to anyone anyways.

[BadriL]

There could be a problem in putting TeardownAsync in a finally block in AuthenticationMiddleware. TeardownAsync also calls ApplyResponseAsync, which in turn calls ApplyResponseGrantAsync and ApplyResponseChallengeAsync. When there is an exception, not sure if it is a good idea to send a challenge or grant. So, as part of this, you may want to consider separating the teardown part and the response handling part and ensure only the teardown part is called even if there is an exception.

[Tratcher]

Yeah, I was considering how to deal with that case. One option is to pass in a flag to these APIs indicating if this was a success or failed response. They could then choose if they want to do any work. Your example of wanting to replace the response body is one of the few where I think it makes sense to do work during an unhandled error.

[Tratcher]

Ah, here's an idea. TeardownAsync calls both ApplyResponseAsync and TeardownCoreAsync. I could skip ApplyResponseAsync in error cases and just run TeardownCoreAsync, which you could override to put the stream back (if it didn't happen inside of ApplyResponseAsync).

[BadriL]

Yes, that will work. I do not think anyone would be needing to send challenge or grant in case of an exception and hence there may not be a need to pass the flag and let the derived classes decide to do anything about it. I think this approach will be better, for this does not disturb the existing setup and only ensures TeardownCoreAsync runs even if there is an exception, which is exactly what I want :). Thanks much.

[Tratcher]

@loudej @davidfowl

[Tratcher]

Related problem: https://katanaproject.codeplex.com/workitem/360
Exceptions thrown in the ApplyResponse code path get cached and re-thrown durring OnSendingHeaders, breaking error handling scenarios like ErrorPage or ErrorHandler.