Working on an app ported from VWG (parts of which were ported from Windows Forms originally). The original code made use of WindowsIdentity.GetCurrent() to get information about the user. Under VWG, this was changed to HttpContext.Current.User, which was set to a WindowsIdentity as a part of the login process (we authenticate against Active Directory).
HttpContext is not valid under WiseJ, so I changed the code to stash the WindowsIdentity in Application.Session[“Principal”] as a part of login. Subsequent attempts to access this value, however, fail – at least under the debugger (I’m not sure about outside the debugger yet). I’m not using Applcation.UserIdentity because I believe that will yield information about the App Pool user from IIS, not the authenticated user on the other end of the browser.
If I stop on the code that tries to fish the value out of Application.Session[“Principal”], the value obtained is null, and I cannot inspect Application.Session at all – even hovering the mouse over Application.Session in the debugger causes the application to immediately terminate with the error “The target process exited with code -2147023895 (0x800703E9) while evaluating the function ‘Wisej.Core.DynamicObject.ToString'”.
This location in the code is quite a few layers down in the call stack, but it’s nested inside code that was invoked from WiseJ (e.g. a button handler) – we haven’t switched threads or anything like that.
Not sure where to go from here…
Check Application.SessionId. If it’s null or empty then you have a thread started somewhere. If it contains the session id and Application.Session[“Principal”] is null then it has been removed by the app.
Application.UserIdentity and Application.UserIdentity and Application.User return the logged in user – depends on your authentication in web.config. It’s identical to System.Web.HttpContext.LogonUserIdentity and System.Web.HttpContext.User.
Please login first to submit.