CredentialCache.DefaultNetworkCredentials is empty and so is Thread.CurrentPrincipal.Identity.Name

I was working on a simple console application in C# that issued HTTP DELETE requests to WebDAV to delete expired documents from the file system. Once completed, this was to run periodically as a job. However, I kept getting back 401 Unauthorized on the DELETE requests. While troubleshooting the issue, I went down the rabbit hole and learned some interesting things. I was passing in CredentialCache.DefaultNetworkCredentials as my HttpRequest credentials. So as a sanity check, I tried viewing it in the debugger to make sure the program was passing in my credentials, only to find that CredentialCache.DefaultNetworkCredentials.UserName was blank.

Well, it turns out that you can’t actually view the credentials unless you set them manually yourself. According to the MSDN documentation:

“The ICredentials instance returned by DefaultCredentials cannot be used to view the user name, password, or domain of the current security context.”

So I tried checking the value of Thread.CurrentPrincipal.Identity.Name instead. This was blank as well. Upon further reading, I determined that this was due to the principal policy not being explicitly set to WindowsPrincipal. Once I did so, Thread.CurrentPrincipal.Identity.Name correctly displayed my windows login ID:

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
Console.WriteLine(Thread.CurrentPrincipal.Identity.Name);

It is helpful to review what an application domain is before proceeding. In Windows, every application runs as its own process, complete with its own set of resources. By isolating applications via processes, this minimizes the risk that one badly coded application can negatively impact others. In the Common Language Runtime, application domains provide an even more granular level of isolation. A single process (the application host) can run multiple application domains, each with the same level of isolation that separate processes would have, minus any of the overhead.
Because every app domain is separate from one another, each has its own Principal object. This object represents the current security context that the code is running as. The PrincipalPolicy is an enum that indicates how this principal object is to be created for the given app domain. Setting it to WindowsPrincipal will map the principal object to the Windows user that the application host is executing as. By default, the PrincipalPolicy will be UnauthenticatedPrincipal, which will set Name to empty string.

After doing some more digging, I also found out that I could use WindowsIdentity.GetCurrent().Name to determine what user the program was executing as:

Console.WriteLine(WindowsIdentity.GetCurrent().Name); 

Having finally proven to myself that my program was running as the correct user, I eventually figured out the issue. It was completely unrelated to the code of course; I had simply forgotten to enable Windows Authentication in IIS. I didn’t mind the time sink, as it proved to be quite educational.

Retrieving a return value from a stored procedure using the Entity Framework DBContext.Database class

I was trying to figure out how to call a stored procedure and then retrieve the return value using the Entity Framework in .NET.      Entity Framework is designed to be an ORM layer, so it doesn’t really have very strong support for stored procs.    My problem seemed to be somewhat common as I found a decent number of results on google.    It seems like lots of places that use Entity Framework still require the use of procs.    Perhaps they don’t trust the performance or scalability of Entity Framework, or perhaps the particular procedure in question encapsulated some complex and highly optimized SQL logic.

 

Whatever the reason, the code had to call a stored procedure and retrieve a return value.    The stored procedure in question could not be modified to use an output parameter instead of having a return value.  This also seemed to be a common requirement.   Typically the proc would be really old legacy TSQL, and changing it would have required too much bureaucracy to have been worth it.

 

So there’s a couple of ways to solve the problem.   Probably the simplest and easiest way is not to use Entity Framework at all and just use plain old ADO.NET instead.       However, in my case, everything else in the solution  was already using the Entity Framework, so I wanted the code to be consistent.    After doing some investigation and testing, I finally figured it out.    The trick is to set the direction of the SQLParameter as ParameterDirection.Output.    This is what tripped me up initially, as in ADO.NET, you would declare the SQLParameter with direction type ParameterDirection.ReturnValue.      Another interesting thing to note is that Database.ExecuteSqlCommand returns an integer.   But this int does not correspond to the return value from the stored procedure.   The MSDN documentation seemed to indicate otherwise.   It states that the return value is: “The result returned by the database after executing the command.”     When I tried storing the result, I got back -1 and I’m not really sure why.

 

Everything  I found online consisted of just code snippets, so here is a complete code sample that deletes a row from a database table and checks the return value to see if it was successful.

 

 


public bool DeleteRowFromDB(int rowId)
{
    bool success = false;
    var retVal = new SqlParameter("@Success", SqlDbType.Int) {    Direction = ParameterDirection.Output };

    object[] parameters =
    {
         new SqlParameter("@RowID", SqlDbType.BigInt) { Value = rowId}
        ,retVal
    };

    string command = string.Format("exec @Success = dbo.spDeleteTableRow @RowID");

    //the result is -1 regardless of what the stored procedure returns
    //note that ExecuteSqlCommand maps to sp_executesql in SQL Server 
    //which will append the type and value for @RowID  
    int result = _DBContext.Database.ExecuteSqlCommand(command, parameters);

    if ((int)retVal.Value == 1)
    {
        success = true;
    }

    return success;
}

 

A no frills AJAX uploader using ASP.NET and vanilla javascript

This is a tutorial on how to write a simple AJAX uploader. I’ve been doing more front end development at work lately, and I recently needed to write a page that processed a small file upload from the user. Because the page in question only accepted files up to 1 MB in size, I figured it would be a much better user experience to do the upload via AJAX, rather than forcing the user to sit through an entire FORM post and wait for the page to reload. Normally, I’d consider going with a third party solution, as there are quite a few AJAX uploaders available on the web. However, management wanted to reduce dependencies on third party code. This sounded reasonable to me. The files in question were going to be small, so fancy features such as progress bars that are commonly found in AJAX uploader plugins would prove to be unnecessary anyway. As a bonus, I’d get to avoid the hassle of researching all the available options out there and save time spent reading through pages of boring documentation. All in all, I was pretty happy to go through the exercise of writing my own.

The first roadblock that I encountered is the fact that Javascript can’t actually access the file system. To see why this would be a bad idea, just look at the well intentioned yet completely awful technology that is ActiveX and all the horrible malware that it has spawned. Giving a client side scripting language like Javascript access to the file system represents a gaping security hole, so it is a good thing that it cannot. To work around this limitation, we must still do a FORM post, but through the use of some clever smoke and mirrors the user never needs to leave the page.

This is accomplished using the “target” attribute of the form element. This attribute specifies where to open the page specified by the “action” attribute. For example, you can provide the value “_blank” to tell the browser to open up the “action” page in a new window. It just so happens that you can also specify an Iframe for your target attribute. So the solution will be to add a hidden IFrame element to the HTML and then specifying it as the target attribute of the form.

The HTML is straightforward. We will have a form element, a file upload element, a hidden IFrame, and a submit button. Finally, we will have a div (with the display initialized to “none”) that displays a simple “upload in progress” message along with an animated gif of a spinning wheel.

<form id="uploadForm" action="/processupload.aspx" method="post" enctype="multipart/form-data" target="upload_target" onsubmit="startUpload();"> 	  
	<input type="file" name="picFile" runat="server" size="50">                        
	<input type="submit" name="submitBtn" value="Upload">						
</form>           	     
    
<br />  
    
<div id="result" style="display:none">Upload in progress.... please wait <img src="/images/processing_small.gif" align="absmiddle" /></div>
    
<iframe id="upload_target" name="upload_target" style="width:0;height:0;border:0px solid #fff;"></iframe> 

The Javascript code is fairly simple as well. We will have two simple functions: StartUpload and StopUpload. StartUpload will simply display our hidden div:

function startUpload() {
	$('result').style.display = "block";
}

StopUpload will be called after the server has finished processing the upload. It will either display “Upload successful” or show some error message.

function stopUpload(success) {
    var result = '';
    if (success == 1) {
        $('result').innerHTML = 'The file was uploaded successfully!';
    }
    else {
        $('result').innerHTML = 'Sorry, there was an error during the file upload.';
	   }			
    }

The final piece of the puzzle is to figure out a mechanism with which to call StopUpload after the server has finished processing the upload. Because the “target” attribute is an iframe, we can write javascript code in the server response, which will then automatically be called when the browser renders the result in the IFrame.

The following is a bare bones Page_Load() function for the processUpload.aspx specified in the form action. Obviously, a real world version would contain more robust error handling, security checks, business logic, and so on. It’d also have a more descriptive file name as well.


protected void Page_Load(object sender, EventArgs e)
{
    int success = 0;
    try
    {
	HttpPostedFile uploadedFile = Request.Files[0];

        //In the real world we'd want to pull set the upload path from web.config or something along those lines
        string imageUploadPath = "C:\\temp";  
	uploadedFile.SaveAs(imageUploadPath); 

        string iframeJavascript = "<script language="javascript" type="text/javascript" >window.top.window.stopUpload(1)</script>";
 
	Response.Write(iframeJavascript);  
    }
    catch (Exception e)
    {
        //here is where we could send back more detailed error information to the browser...
        string errorResponse= "<script language="javascript" type="text/javascript" >window.top.window.stopUpload(0)</script>"; 
	Response.Write(errorResponse);      
    }
}

Lo and behold, we now have a fully functional AJAX uploader. From here we can make any number of improvements to make it more useful. For example, if we wanted StopUpload to display a more useful error message, we could add an “ErrorMessage” parameter to the javascript function, and have the server write out appropiate messages based on the nature of the error: “File size too large”, “Error processing file”, and so on. Of course, if you find yourself spending too much time implementing, testing, and debugging additional functionality, it would make more sense to use the many AJAX uploader plugins already out there on the internet (many of them free).

Reverse all the bits in a byte

A common question encountered in interviews is to reverse all the characters in a string. A fun little variant on this one is to reverse all the bits in a byte. It’s a good way to test the candidate’s basic knowledge of bit manipulation. Of course, there are quite a few solutions to these problems, some of them devised by low level programming gurus. You know, the kind of people who code in assembly and write drivers for fun. These solutions involve an esoteric combination of multiplication and modulo operations that somehow end up with the correct answer. The solution presented here is the standard (boring) textbox solution for mere mortals.

First, we’ll need a way to figure out whether a given bit in a byte is on or off. To do so, we bitwise AND the byte with 2^(n-1), where n is the bit position we are interested in (ranging of course, from one to eight).    We then compare the result to zero. 2^(n-1) serves as a bit mask. Note that every bit in this byte is off, except at position n. Thus, the resultant AND operation will zero out every other bit in the byte. So if the result is zero, then bit n of the original byte must also be equal to 0. If the result is anything else, then bit n must be equal to 1.

Here is a concrete example. If we want to determine whether or not the third bit is ON in a given byte, we AND byte x with 2^(3-1), or 00000100 in binary. Let’s take a look at the number 36. 36 AND 4 = 4, which means the third bit is on. How about 17? 17 AND 4 = 0, so the third bit is off.    Opening up the trusty Windows Calculator in programmer mode can quickly verify this.

Now, instead of writing out eight separate bit masks for each bit position, we can simply use one bit mask: 1. This makes life easier. We can then write a for loop from one to eight that bit shifts the byte right by one through every iteration. By then ANDing this value with one, we get the value of the bit at position n, where n is the current loop index.

During each iteration, we’ll need to write this bit value to its correct location to an output byte, which we will initialize to zero. If the bit in question is 0, then we don’t need to do anything, since the corresponding bit in the output byte is already zero. If the bit is equal to 1, then we need to write it at position 9-n in the output byte, where n is the current loop index. To do that, we’ll bitwise OR the output byte with the bitmask 2^(n-1). Because every other value in this bit mask is zero, we preserve all the existing values in the output byte, except the one that we want to flip on.

Instead of using eight different bit masks, we can again simplify things by using only one bit mask: 1. To do so, we’ll slightly modify the for loop logic to left shift the output byte by 1 before ORing it with 1. This will write the current bit to the lowest significant bit. Eventually, after every bit in the input byte has been iterated over, all bits will have been shifted into their correct position.

The code looks like this in C#:

static byte reverseByte(byte val)
{
    byte result = 0;

    int counter = 8;
    while (counter-- < 0)
    {
        result <<= 1;         
        result |= (byte)(val & 1);         
        val = (byte)(val >> 1);
    }

    return result;
}

Let’s reverse 182 (10110110 in binary). Here are the values of the output byte in binary after each iteration of our loop, so we can see what’s going on:

Bit 1 of 182 is 0.
0 OR 0 = 0.

Bit 2 of 182 is 1
0 << 1 = 00
0 OR 1 = 01

Bit 3 of 182 is 1
01 << 1 = 010
010 OR 1 = 011

Bit 4 of 182 is 0
011 << 1 = 0110
0110 OR 1 = 0110

Bit 5 of 182 is 1
0110 << 1 = 01100
01100 OR 1 = 01101

Bit 6 of 182 is 1
01101 << 1 = 011010
011010 OR 1 = 011011

Bit 7 of 182 is 0
011011 << 1 = 0110110
0110110 OR 0 = 0110110

Bit 8 of 182 is 1
0110110 << 1 = 01101101
01101101 OR 1 = 01101101

Whew, so there you have it. This is the standard answer you’d want to give in an interview. For bonus points, you’d want to point out that there’s a simpler and faster solution that saves on CPU cycles, at the cost of a few extra bytes of memory: a lookup table. By storing each byte value, and its reversed value as key value pairs, we can now do an instant O(1) lookup, at the expense of just 512 bytes of memory. As an added bonus, the CPU can potentially store the data in its cache as well, so it would never even need to hit main memory. This is a pretty good tradeoff. Its worth doing this kind of analysis in an interview. In the real world, applications are always bound by some bottleneck, whether it be the CPU, memory, disk IO, or something else entirely, and a good developer needs to aware of these issues when writing code, as they obviously play an important role when making architectural design decisions.

Manipulating raw bitmap data in .NET

The Bitmap class found in the .NET Framework provides a lot of useful functionality.   Unfortunately, it doesn’t have any methods that let you easily manipulate the raw bitmap data.   It provides a SetPixel method which takes x,y coordinates and a color value, and does exactly what you’d think it would.    Unfortunately, the implementation is not the most efficient.   It will lock the entire bitmap before modifying the data.    This is fine if you only need to manipulate a few pixels, but horrible if you need to manipulate the entire image.   Needless to say, the overhead of locking and unlocking the data just to modify one measly little pixel is detrimental for performance.

I found a few articles on the best way to manipulate the raw data.    The simplest and most intuitive way is to create a memory stream, save the bitmap to it, and then manipulate the bytes in the memory stream.     Once you are done, you recreate the bitmap based on the modified memory stream.   For example, this pedeantic snippet sets all the bits in the bitmap purple (based on this tutorial article):

MemoryStream ms = new MemoryStream();

bmp.Save(ms, ImageFormat.Bmp);
byte[] bitmapData = ms.GetBuffer();

const int BITMAP_HEADER_OFFSET = 54;
Color colorValue = Color.Purple;

for (int i = 0; i < bitmapData.Length; i += 4)
{
    bitmapData[BITMAP_HEADER_OFFSET + i] = colorValue.R;
    bitmapData[BITMAP_HEADER_OFFSET + i + 1] = colorValue.G;
    bitmapData[BITMAP_HEADER_OFFSET + i + 2] = colorValue.B;
    bitmapData[BITMAP_HEADER_OFFSET + i + 3] = colorValue.A;
}

bmp = new Bitmap(ms);

Once you have the bytes themselves you can begin manipulating them.      Each pixel is represented by a four bytes, consisting of the Red, Green, Blue, and Alpha (this controls transparency) values, respectively.     Divide the current byte index by four to get the pixel you are on.    From there you can mod by the bitmap width to get the x coordinate, and divide by the bitmap height to get the y coordinate.

One thing to note is that the raw image data does not begin at byte 0.     The first 54 bytes of the data consists of the bitmap header which contains various metadata. The problem with this code of course, is that it hard codes this offset and assumes it will never change.    This ties the code to the internal implementation details of the Bitmap class which violates encapsulation.   Not the best practice.

So another way of accomplishing the same task that does not require knowledge of the internal structure of a windows bitmap is to pin the bitmap object in memory and copy the data over to a local buffer. The data can then be manipulated locally and then copied back to the bitmap, which can then be unpinned from memory.    The following is based on the MSDN example.

// Lock the bitmap's bits.
Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
System.Drawing.Imaging.BitmapData bmpData =
bmp.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadWrite,
bmp.PixelFormat);

// Get the address of the first line.
IntPtr ptr = bmpData.Scan0;

// Declare an array to hold the bytes of the bitmap.
byte[] bitmapData = new byte[Math.Abs(bmpData.Stride) * bmp.Height];

// Copy the RGB values into the array.
System.Runtime.InteropServices.Marshal.Copy(ptr, bitmapData, 0, bitmapData.Length);

Color colorValue = Color.Purple;
for (int i = 0; i < bitmapData.Length; i += 4)
{
    bitmapData[i] = colorValue.R;
    bitmapData[i + 1] = colorValue.G;
    bitmapData[i + 2] = colorValue.B;
    bitmapData[i + 3] = colorValue.A;
}

// Copy the RGB values back to the bitmap
System.Runtime.InteropServices.Marshal.Copy(bitmapData, 0, ptr, bitmapData.Length);

// Unlock the bits.
bmp.UnlockBits(bmpData);

Note the use of the Bitmap data class, particularly the use of Scan0 and Stride.   Scan0  gets the memory location of the actual image data itself, completely bypassing the problem of figuring out the end of the bitmap header.    Stride represents the width in bytes of a bitmap object.

The Lock and UnlockBits are used to pin the bitmap object in memory.     What this means is that this object now has a fixed location in memory and cannot be moved.    Typically, the garbage collector moves objects around during the lifetime of an application.    This is done to avoid memory fragmentation.   For example, the garbage collector has a compaction phase where objects that are still being referenced are packed together in the heap.      This solves the problem of being unable to allocate a block of memory even though there is enough free memory (imagine for example, that there is 3KB of free memory, but a 3KB block cannot be allocated because the 3KB is not contiguous and is spread out in small chunks throughout the heap) Pinning the bitmap allows us to safely copy the data back and forth from the object without having to worry whether or not that memory location is still the correct address.

To test the performance, I wrote a simple program to set all the pixels in a 1000 x 1000 bitmap to purple.      The pinning method is slightly faster, but not by much.   Here is the code:

using System;
using System.Drawing;
using System.IO;
using System.Drawing.Imaging;

namespace BitmapTestFramework
{
    class Program
    {
        static void Main(string[] args)
        {
            Bitmap testBitmap = new Bitmap(1000, 1000);
            DateTime start;
            DateTime end;
            TimeSpan timeSpan;

            Console.WriteLine(string.Format("Method 1:   Calling Get/Set Pixel", testBitmap.Width, testBitmap.Height));
            start = DateTime.UtcNow;
            Method1(testBitmap);
            end = DateTime.UtcNow;
            timeSpan = end - start;
            Console.WriteLine(string.Format("Completed in {0} milliseconds", timeSpan.TotalMilliseconds));

            Console.WriteLine("Method 2:  Create a memory stream of the bitmap and manipulate the buffer");
            start = DateTime.UtcNow;
            Method2(testBitmap);
            end = DateTime.UtcNow;
            timeSpan = end - start;
            Console.WriteLine(string.Format("Completed in {0} milliseconds", timeSpan.TotalMilliseconds));

            Console.WriteLine("Method 3:   Pin the bitmap object in memory and manipulate a local copy of the data");
            start = DateTime.UtcNow;
            Method3(testBitmap);
            end = DateTime.UtcNow;
            timeSpan = end - start;
            Console.WriteLine(string.Format("Completed in {0} milliseconds", timeSpan.TotalMilliseconds));
        }

        static void Method1(Bitmap bmp)
        {
            for (int x = 0; x < bmp.Width; x++)
            {
                for (int y = 0; y < bmp.Height; y++)
                {
                    bmp.SetPixel(x, y, Color.Purple);
                }
            }
        }

        static void Method2(Bitmap bmp)
        {
            MemoryStream ms = new MemoryStream();
            bmp.Save(ms, ImageFormat.Bmp);
            byte[] bitmapData = ms.GetBuffer();

            const int BITMAP_HEADER_OFFSET = 54;

            Color colorValue = Color.Purple;
            for (int i = 0; i < bitmapData.Length* 4; i += 4)
            {
                bitmapData[BITMAP_HEADER_OFFSET + i] = colorValue.R;
                bitmapData[BITMAP_HEADER_OFFSET + i + 1] = colorValue.G;
                bitmapData[BITMAP_HEADER_OFFSET + i + 2] = colorValue.B;
                bitmapData[BITMAP_HEADER_OFFSET + i + 3] = colorValue.A;
            }

            bmp = new Bitmap(ms);
        }

        private static void Method3(Bitmap bmp)
        {
            // Lock the bitmap's bits.
            Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
            System.Drawing.Imaging.BitmapData bmpData =bmp.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadWrite, bmp.PixelFormat);

            // Get the address of the first line.
            IntPtr ptr = bmpData.Scan0;

            // Declare an array to hold the bytes of the bitmap.
            byte[] bitmapData = new byte[Math.Abs(bmpData.Stride) * bmp.Height];

            // Copy the RGB values into the array.
            System.Runtime.InteropServices.Marshal.Copy(ptr, bitmapData, 0, bitmapData.Length);

            Color colorValue = Color.Purple;
            for (int i = 0; i < bitmapData.Length; i += 4)
            {
                bitmapData[i] = colorValue.R;
                bitmapData[i + 1] = colorValue.G;
                bitmapData[i + 2] = colorValue.B;
                bitmapData[i + 3] = colorValue.A;
           }

            // Copy the RGB values back to the bitmap
            System.Runtime.InteropServices.Marshal.Copy(bitmapData, 0, ptr, bitmapData.Length);

             // Unlock the bits.
             bmp.UnlockBits(bmpData);
        }
    }
}

Here is the output on my machine:

Method 1:   Calling Get/Set Pixel
Completed in 649.414 milliseconds
Method 2:  Create a memory stream of the bitmap and manipulate the buffer
Completed in 91.7969 milliseconds
Method 3:   Pin the bitmap object in memory and manipulate a local copy of the data
Completed in 82.0312 milliseconds