In general, when an .asp file creates an instance of your component, the component will inherit the security context of the .asp file. However, if the .asp file assigns Session or Application scope to your component, the server will free the component in the security context of the Web server instead of the security context of the client who owns the session. This could potentially cause a problem that you will want to anticipate when designing. If your design requires that the component's cleanup or destructor method run in the security context of the client, it should save the client's security context during its creation method so that it can recall this context during its cleanup.
You can obtain the security context of the client by calling the OpenThreadToken
function. In your component's destructor method you can call the SetThreadToken
function to set the security context to the previously saved client's context. This procedure is outlined in the following pseudo code, which includes the necessary Win32 API functions. This is not a working example; the italicized functions all require additional parameters.
//saving the client's security context
OpenThreadToken(hTokenClient,);
// . . . creation code
//make a copy of the current security context
Success = OpenThreadToken(
GetCurrentThread(),
TOKEN_QUERY|TOKEN_IMPERSONATE|TOKEN_EXECUTE,
TRUE,
HToken);
//set the security context to the previously-saved client context
SetThreadToken(hTokenClient);
// . . . destruction code
//reset the thread to its standard security context
SetThreadToken(hTokenSave);
Note In the previous example, the standard security context is saved in hTokenSave
before the object calls the SetThreadToken
function. This enables you to reset the thread to its normal security context after the object instance is destroyed. This is not a working sample.