Thursday, September 23, 2004

Yahoo! Mail - ashish_cal5@yahoo.com

Yahoo! Mail - ashish_cal5@yahoo.com

Public keys and public key tokens

spent some time this morning doing some "dotting the i's work" on my metadata engine. One of the things that I've been holding out implementing for a while because it wasn't particularly important in my test cases was adding some code that would generate efficient assembly references to strongly-named assemblies.



Strongly-named assemblies contain the signer's public key embedded in the assembly. You can see this by opening up the assembly using ILDASM and viewing its manifest. Inside the manifest, there must be a .publickey section if that assembly has a strong name. If you look at one of these sections, you'll see that it is rather large. For example, System.Web.dll's public key is 160 bytes in length.



When one assembly references a strongly-named assembly, it must embed a reference to the strongly-named assembly's public key to ensure that an attacker cannot substitute another assembly for the one that it was expecting to find. The simplest solution would be to simply embed the strongly-named assembly's public key in the referencing assembly. As you can see, however, this is not a very efficient solution due to the large size of the public keys.



Microsoft solves the "public key bloat" problem by using a hash of the strongly-named assembly's public key. These hashes are referred to as public key tokens, and are the low 8 bytes of the SHA1 hash of the strongly-named assembly's public key. SHA1 hashes are 160 bit (20 byte) hashes, and the top 12 bytes of the hash are simply discarded in this algorithm.



Calculating the SHA1 hash of an assembly's public key turns out to be really straightforward using the CryptoAPI hashing functions. Here's a simple piece of code that will generate an SHA1 hash:



bool CalculatePublicKeyToken( const unsigned char *publicKey, ULONG publicKeyLen )
{
if( 0 == publicKeyLen )
return true;



bool result = false;
HCRYPTPROV hProv = 0;
HCRYPTHASH hHash = 0;
unsigned char buffer[ 20 ];
DWORD bufferLen = 20;



if( CryptAcquireContext( &hProv, 0, 0, PROV_RSA_FULL, 0 ) )
{
if( CryptCreateHash( hProv, CALG_SHA1, 0, 0, &hHash ) )
{
if( CryptHashData( hHash, publicKey, publicKeyLen, 0 ) )
{
if( CryptGetHashParam( hHash, HP_HASHVAL, buffer, &bufferLen, 0 ) )
{
DumpPublicKeyToken( buffer, bufferLen );
result = true;
}
}
}
}



if( hHash ) CryptDestroyHash( hHash );
if( hProv ) CryptReleaseContext( hProv, 0 );



return result;
}



It is also possible to use the StrongNameTokenFromAssembly API defined in the StrongName.h header file in the Framework SDK. However, this API assumes that the assembly isn't loaded already, which certainly isn't the case in my code.


Wednesday, September 22, 2004

Difference between ODBC and OLEDB

First of all both are API for database access.
The differences between these two data access protocols are technical, but in the most general terms, OLE DB is newer, more advanced, and compatible with a wider selection of database technologies. In addition, OLE DB is more general, in that it includes the ODBC functionality.

Technically speaking, ODBC (Open Database Connectivity) is designed to provide access primarily to SQL data in a multi-platform environment. OLE DB (Object Linking and Embedding Database) is designed to provide access to all types of data in an OLE Component Object Model (COM) environment. OLE DB includes the SQL functionality defined in ODBC but also defines interfaces suitable for gaining access to data other than SQL data.

you can vist this page for details http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnodbc/html/msdn_ole4odbc.asp.

Wednesday, September 08, 2004

Conversion : datareader into array

private Object[] PopulateReportRecordFromSqlReader(IDataReader reader)
{
//Add One More for ID
int length = reader.FieldCount + 1;

Object[] data = new Object[length];

for(int i =0 ; i < length ; i++)
{
if(i==0)
{
data[0] = i;
}
else
{
data[i] = reader[i-1];
}
}
return data;
}

Efficient string manipulation

Avoid Returning null Instead of Array, String, or Collection

In almost all situations except when performance can be an issue (e.g.
heavily looped or performance tuned code), null should not be returned
from a method that returns an array, string, collections, ArrayList,
BitArray, HashTable, Queue, SortedList, or Stack. It should not be
necessary for a user of a method to handle a null that is returned
from a method. Instead only empty or zero-length data types such as 0
item arrays, empty strings (String.Empty), and 0 item collections
should be returned.

Avoid Checking String Equality Using == and = Operators

Using == operator in C# and = operator in Visual Basic to compare
strings is slower than using the System.String.Equals method. In
addition, if you need to do case sensitive or insensitive comparisons
the System.String.Compare method is the preferred way to do so. The
String.Compare method can compare two strings based on their
alphabetical sort order as well, something that is important in
developing applications for the international market.

Testing for Empty Strings

The most efficient method to determine if a string is empty is via
it's Length property.

[C#]
if(var1.Length < 1)

[Visual Basic]
If (var1.Length < 1) Then

Avoid Hard Coded String Literals

Use String.Empty rather than "" for empty strings. Other strings
should be placed in a constants class.
[C#]
string var1 = ""; // Avoid
string var2 = String.Empty; // Recommended

[Visual Basic]
Dim var1 As String = "" ' Avoid
Dim var2 As String = String.Empty ' Recommended

Tuesday, September 07, 2004

Server.Transfer Vs. Response.Redirect

1.Server.Transfer. Where possible, use the Server.Transfer method
instead of the Response.Redirect method. Response.Redirect sends a response header to the client that causes the client to send a new request to the redirected server by using the new URL. Server.Transfer avoids this level of indirection by simply making a server-side call.

2. You cannot always just replace Response.Redirect calls with
Server.Transfer calls because Server.Transfer uses a new handler during the handler phase of request processing. If you need authentication and authorization checks during redirection, use Response.Redirect instead of Server.Transfer because the two mechanisms are not equivalent. When you use Response.Redirect, ensure you use the overloaded method that accepts a Boolean second parameter, and pass a value of false to ensure an internal
exception is not raised.

3. Also note that you can only use Server.Transfer to transfer control to pages in the same application. To transfer to pages in other applications,you must use Response.Redirect.