HttpServer captures Thread.CurrentPrincipal and restores it to this original value when finished handling a request. However, it is reset before the formatters have been asked to serialize their response.
Impact is low because only the formatters encounter this, and it unlikely they require the principal.
To reproduce this, write a custom message handler that sets Thread.CurrentPrincipal to some custom principal. Also write a custom media type formatter that accesses Thread.CurrentPrincipal in its WriteToStreamAsync() method.
Expected: Thread.CurrentPrincipal is the custom one set in message handler
Actual: Thread.CurrentPrincipal has been reset back to what it was when the request was received.
Comments: I believe the impact of the issue should be raised. If the controller returns a deferred LINQ execution (e.g. Select) then the time it evaluates is within the context of the transformer not the controller and securtity is not available. To make matters worse it can exhibit as an intermittent rather than consistent problem and therefore could be missed during routine testing. It's also not possible to detect whether a controller has returned a deferred execution collection so it's up to developers to know about this problem and manually apply ToList() etc. to their controller return methods. As stated before even unit testing won't necessarily catch this every time.
Impact is low because only the formatters encounter this, and it unlikely they require the principal.
To reproduce this, write a custom message handler that sets Thread.CurrentPrincipal to some custom principal. Also write a custom media type formatter that accesses Thread.CurrentPrincipal in its WriteToStreamAsync() method.
Expected: Thread.CurrentPrincipal is the custom one set in message handler
Actual: Thread.CurrentPrincipal has been reset back to what it was when the request was received.
Comments: I believe the impact of the issue should be raised. If the controller returns a deferred LINQ execution (e.g. Select) then the time it evaluates is within the context of the transformer not the controller and securtity is not available. To make matters worse it can exhibit as an intermittent rather than consistent problem and therefore could be missed during routine testing. It's also not possible to detect whether a controller has returned a deferred execution collection so it's up to developers to know about this problem and manually apply ToList() etc. to their controller return methods. As stated before even unit testing won't necessarily catch this every time.