Coffeehouse Thread

10 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

ASP.NET and Threading

Back to Forum: Coffeehouse
  • User profile image
    pavone

     I have yet another question for the C9 gurus. Recall that in my previous thread, I was working with an ASP.NET app and multi-threading. I came across an odd problem:

    My app has to check for several paths on network shares, this is done with Directory.Exists(path). However this is always returning False when called from inside one of my spawned threads, if called from the main Thread with the same path, it returns True.

    Can anyone shed some light as to why this happens? 

    Thanks   Smiley

  • User profile image
    blowdart

    Probably because the app pool identity doesn't flow to the thread. To check validate Thread.Identity is the same value in your main path and your spawned threads.

  • User profile image
    lensman

    Also consider that asp.net apps operate within a sand box.  Your thread might not have rights to view the destination location. 

  • User profile image
    blowdart

    Ah, I knew there was something. Are you using impersonation by any chance? That definitely doesn't make it to background threads. If that's the case then you need to store the WindowsIdentity in a class level member variable, then wrap you threaded bits in impersonation calls;

     

    public partial class _Default : System.Web.UI.Page
    {
        private WindowsIdentity threadIdentity;
    
        protected void Page_Load(.....)
        {
            this.threadIdentity = Context.User.Identity as WindowsIdentity;
    
            // And then you kick off your thread
           Thread thread = new Thread(new ThreadStart(RunMe));
           ....        
        }
    
        protected void RunMe()
        {
            IntPtr token = IntPtr.Zero;
            WindowsImpersonationContext impersonatedUser = null;
            try
            {
                    WindowsIdentity id =this.threadIdentity;
                    impersonatedUser = id.Impersonate();
                    // Now I'm the right user, do stuff
            }
            catch
            {
            }
            finally
            {
                if (impersonatedUser != null)
                    impersonatedUser.Undo();
    
                if (token != IntPtr.Zero)
                    CloseHandle(token);
            }        
        }
    }

  • User profile image
    JoshRoss

    @blowdart: That actually solves a problem I had from a while back. Thanks for the code.

    -Josh

  • User profile image
    blowdart

    , JoshRoss wrote

    @blowdart: That actually solves a problem I had from a while back. Thanks for the code.

    -Josh

    Please send money to ....

     

  • User profile image
    pavone

    , lensman wrote

    Also consider that asp.net apps operate within a sand box.  Your thread might not have rights to view the destination location. 

     I think you may just be right about that. This is an exception I got from a File.Delete in another thread spawned:
    "The account used is a computer account. Use your global user account or local user account to access this server.  "

    And blowdart comes to the rescue yet again, you're awesome, thanks. 

  • User profile image
    JuanZamudio

    @blowdart: question, if you don't undo the context in the catch aren't you falling in the security hole mentioned here http://blogs.msdn.com/b/shawnfa/archive/2005/03/22/400749.aspx? (another code can catch the exception and run as the impersonated user), or in this case it doesn't matter because is a web page that cant be called by someone else?

     

  • User profile image
    cbae

    @blowdart: Fully-qualfied type name: System.Security.Principal.WindowsImpersonationContext

    Thank goodness for usings and autocomplete.

  • User profile image
    blowdart

    , JuanZamudio wrote

    @blowdart: question, if you don't undo the context in the catch aren't you falling in the security hole mentioned here http://blogs.msdn.com/b/shawnfa/archive/2005/03/22/400749.aspx? (another code can catch the exception and run as the impersonated user), or in this case it doesn't matter because is a web page that cant be called by someone else?

    Mitigated by that yes, but you're right, I shouldn't be so lazy, so Shawn's advice should stand, if only to get you into the habit of doing it right for all cases.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.