I'm currently working on a Windows forms application which uses WCF hosted in IIS for backend access.
We use the Enterprise Library caching block in the client application to store a small amount of lookup data which is frequently required within the application. In order to ensure a level of consistency with the data, we are using a custom refresh action with
an expiration time which will retrieve the current lookup data via a WCF method. As far as I understand this, this refresh request runs on a background thread generated within the Enterprise Library code.
On the server side, we are using a custom authorization policy to authenticate client requests. WCF is set up to run in PerCall mode.
In production, the client application runs on a Citrix environment.
The behaviour we are seeing is that the caching block refresh action is causing an identity issue on the threads arriving at the server. If we have a request pattern as follows occurring in this order within a very small timeframe:
- 1: Client A requests data - on server, Thread.CurrentPrincipal is Client A (Correct)
- 2: Client B triggers the cache refresh action - on server, Thread.CurrentPrincipal is Client B (Correct)
- 3: Client A requests data again - on server, Thread.CurrentPrincipal is
Client B - eh?
We have confirmed from WCF tracing that the same thread has been used for all of the above operations. I have yet to come up with a theory of how this is possible - but it does seem as if the next request after a request from the refresh action already has
Thread.CurrentPrincipal set to a WindowsIdentity. Every other request from the client will have the application pool identity and we authenticate the client and set the principal to the correct identity which is used thereafter.
The fix for this is very easy for us to implement - there was some legacy code which was skipping over the correct authentication process. However, I thought I would post this to see if anyone else has ever come across this strange behaviour?
If I remove the refresh action from the cache, we do not get this problem. I have also written a quick implementation of System.Runtime.Caching and ran some tests with that - again, the problem no longer occurs. So it does look as if the EL5 caching block is
causing this issue - does anyone have any idea as to why? :)