Nate's Stuff

Have you ever noticed that with IE7 you can only download 2 files from any given domain at any given time?  It's actually slightly worse than that, you may only have 2 connections total, including a connection to request web pages.  That means if you are downloading two things from a single domain you are unable to browse!  Much to my angst this is actually a W3 standard! 

Basically it's a quick registry fix.  If you are comfortable making changes to your registry this will be really quick!

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000032
"MaxConnectionsPer1_0Server"=dword:00000032

You can also download the .reg file here

Environment

I have to admit, I was very excited when I saw this was going to be a topic for the users group meeting.  I am very interested in hardware!  I remember building my own connector to the computer to communicate with my calculator (TI-86).  I always wondered how it worked so when I saw the topic I was very excited to might learn some of this stuff.

It has been quite a while since I've been to a users group meeting here, but I can never find where we meet.  I don't remember what floor or what room and there are never any posters or signs.  The meeting started 15 min's late because the presenter was caught in traffic!  Also, the wireless at Neumont is always locked down and it really sucks not having Internet when we're group programming and need to know the format string for a DateTime.TryParseExact!  Pizza and drinks were plentiful and that is always nice!

The presenter started out apologizing for poor content, usually not a good sign!  However he really did seem to know his stuff and came prepared to amaze us with his gobs of cool hardware.  He is kind of a quiet talker and while I was near the back of the room I was still plenty close to be able to hear and I had to really strain to hear.  If he didn't have code on the screen most of the time I probably wouldn't have gotten much out of it.

I was a little annoyed that we had to wade through the code creation process.  Although this is something I like to do in my presentations I only apply it in cases where the topic I am presenting is new.  Parsing strings in C# is something we all do all of the time and it was annoying to sit around for over an hour waiting for the code to be created.  I was really disappointed when that resulted in skipping Ethernet and Wireless connectivity.  I didn't mind so much that the final application wasn't written.  I didn't actually even expect anything polished as this is a users group meeting.  About two minuets into looking through the code he did have I was satisfied and we could have moved on from there.

Presenter: Josh Perry - 6bit Inc.

http://www.6bit.com/

Sponsor: MindCenter sponsor

http://www.MindCenter.net

The Serial Port

• RS (Recommended Standard)-232C
• Defined in 1969
• DTE (Data Terminal Equipment) - Client
• DCE (Data Circuit-terminating Equipment) - Server

Physical

• Computers wired as DTE
• Devices (modems, etc..) wired as DCE (usually)
• DE-9 most common connector
• DV-25 (25 pin serial connector)

Pin-outs (DE-9)

• RX - 2
• TX - 3
• GND - 5
• RX on DTE goes to TX on DCE
• TX on DTE goes to RX on DCE
• NULL-Modem

Serial - Electrical

• +12v to -12v swing; +12v = 1 - 12v = 0
• Single ended communication, common ground
• Small and embedded systems need level converters and inverters to go from logic to serial levels
• Oscilloscope trace of serial communication

Serial - Protocol

• Time-based sampling
• Baud rate is the frequency of bytes
• Bit rate is 8 * baud + 1 (start bit) + stop bits + Parity
• Most common is 8 bit bytes, no parity, and 1 stop bit
• Baud varies a lot, but 9600 and 115500 are popular
• With only RX, TX, and ground; flow control is none or XON-XOFF. None is most common, XON-XOFF causes problems with binary communications.

Byes are send LSB first if you scope a serial connection under hyper terminal. 

We are implementing the NMEA protocol which is a standard maritime protocol that was first implemented for boats.  It is an ASCII protocol.  Each sentence is 1 line terminated with a CRLF.  Comma delimited with each of the values.

Atmel chips are a good way to get started.

The .net microframework chips allow you to program chips using the .net framework.  

Links

• http://utahdnug.org/
• http://www.atmel.com/products/
• http://www.MindCenter.net/ 
• http://msdn.microsoft.com/en-us/embedded/bb267307.aspx

Every company I consult with invariably has their own "security" assembly and they all have a hard-coded encryption key with the IV and the method to decrypt is right next to the method to encrypt.  This is what I call marginal protection.  Yes, it's encrypted and will probably get a security auditor off of your back but don't be fooled into thinking that you are protected!  A similar thing is done with information in the database, but I'll cover how to do this on an upcoming post. 

Why aren't you protected?  The answer to this question is actually quite simple.  If an attacker has access to download your web.config file (say, they brute forced a password on the FTP server) then there is nothing stopping them from downloading the your Security.dll which is responsible for decrypting the password.  Once they have that library it's seconds, not minuets, before they have got the password. 

One possible work around is to encrypt configuration sections of your web.config file using DPAPI as outlined in this MSDN How-to.  This is immune to the download attack because the DPAPI uses encryption that is based on a machine or a user.  Even if someone was able to download your web.config they would effectively have no way to decrypt that information. 

What happens, though, if the attacker has the ability to upload files?  Well, in theory, they may be able to grab that configuration in code which will, of course, be decrypted before it is returned.  Ahh, but they don't even know what the name of the connection string (in the case of databases) is because the entire section was encrypted.  However, they could guess it or get it from other code. By the way, you really shouldn't deploy the .cs files to production anyway; you should use the "publish website" option with the setting to not allow the site to be updated.  If you follow all of the standards pretty closely your in good shape.  Another great idea is to use Integrated Authentication for database access -- that way there is no password to steal!

The How to outlines 3 basic steps summarized below:

1. Identify the configuration sections to be encrypted
1. You may only encrypt the following:

<appSettings>. This section contains custom application settings. 
<connectionStrings>. This section contains connection strings. 
<identity>. This section can contain impersonation credentials. 
<sessionState>. The section contains the connection string for the out-of-process session state provider.

2. Choose Machine or User store
1. Use Machine store if this is a dedicated server with no other applications running on it or you want to be able to share this information with other applications running on this machine.
2. Use User store if the above does not match your situation and in a scenario in which the user has limited access to the server.
3. Encrypt your configuration file data
1. To encrypt using Machine Store, run the following command from a .NET command prompt:
   aspnet_regiis.exe -pef "{ConfigSectionName}" {PhysicalDirectory} –prov "DataProtectionConfigurationProvider"
   OR
   aspnet_regiis.exe -pef "{ConfigSectionName}" -app "/{VirtualDirectory}" –prov "DataProtectionConfigurationProvider"
   
2. To encrypt using User Store:
   Add the following section to your configuration file:
   

<configProtectedData> 
    <providers> 
        <add useMachineProtection="false" keyEntropy="" 
                name="MyUserDataProtectionConfigurationProvider" 
                type="System.Configuration.DpapiProtectedConfigurationProvider, 
                System.Configuration, Version=2.0.0.0, Culture=neutral, 
                PublicKeyToken=b03f5f7f11d50a3a" /> 
    </providers> 
</configProtectedData>

Open a command prompt using the user you plan to encrypt the file with. To do so, Right click on the Command Prompts shortcut, right click -> Run As.  Or use the following command:

Runas /profile /user:domain\user cmd

 
Run the following command:
Aspnet_regiis -pe "connectionStrings" -app "/{VirtualDirectory}" -prov "MyUserDataProtectionConfigurationProvider"

It really is that simple!  The great thing is that we don't have to do anything special in development to benefit from the encryption of the configuration sections. 

References:

http://msdn.microsoft.com/en-us/library/ms998280.aspx

I am not a gamer!  I would get killed playing anything modern!  I was never very good at the games I did play (back in the 90's) like Marathon or StarCraft.  I did like games before that but they were mostly DOS based games.  I loved Cyberbox, a little game where you try to navigate your dot from one side of the screen to the other pushing blocks along the way.  A couple of years ago I was introduced to Line Rider.  A really simple game where you "draw" a track for our sledding hero to ride.  A simple premise but a fun one!  You can spend literally hours without realizing it just designing the most awesome ever track! 

LineRider has gone Silverlight!  It's been greatly enhanced with the new features of Silverlight and is pretty awesome.  I am hoping that more and more Silverlight is adopted and ubiquity increases to match or exceed Flash.  I know of no such place that keeps track of these types of statistics but it will be interesting in a year from now how much Silverlight will penetrate the market.  It seems that they should be able to make it available as an update via Windows Update like the .net frameworks, but reaching a growing OS X audience may be more difficult.  Hopefully there are plans in the works to get Silverlight on that platform.

If I can figure out how to post a capture video from Line Rider, I'll post it here.

Nathan Zaugg

Have you ever needed to add a line to a config file like:

<type="Config.RoleService, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

These fully qualified types are not easy to figure out.  The syntax is a bit confusing and the PublicKeyToken is hard to get a look at.  This has been an issue -- until now!

GetAssemblyName App

I created a quick little app that will load an assembly you select and show you all of the AQN (Assembly Qualified Names) for each class contained in the assembly. Notice the cool glass look?  I'll post information about that in a later blog post.

Quick Instructions:

1. Run the app
2. Press the "Select Assembly" button
3. Browse to the assembly you want to get the AQN for and press Open
4. The window will fill up with the assembly full name and the AQN for each type found in the assembly
5. Double Click the line to copy that class's AQN to the clipboard

Downloads:

• GetAssemblyName Source Code
• GetAssemblyName Binary App
  

Naming conventions are like arm pits.  Everyone has them and they all stink!  Well, at least that's the perspective of pretty much every developer an DBA alike.  I will present my own personal philosophy for naming conventions on databases and hopefully spawn some discussion in the process.

Basic Principles

Consistency

As annoying as certain standards are (such as putting tbl_ before everything) it is more annoying and more difficult when there are no conventions or mixed conventions.  Being able to reliably predict the schema once the basic relational structure is understood is key to productivity.  Therefore, even if you get stuck with standards you disagree with, so long as they are consistent they will be much better than the alternative.  Unless you get to make the decision, my guess is that there are going to be some conventions that you do not agree with.

Abbreviations

It is a good idea to abbreviate, when appropriate, in the naming of objects in your database.  It may be a good idea to have a list of abbreviations that you plan to use in the database as part of your data dictionary.  However, if there is not a good, clear abbreviation for an object, don't make one up.  When in doubt, spell it out!  Especially with SQL Server where you don't have the pesky 30 char limit for tables and columns like Oracle.

Identities

Every table should have an Identity as it's primary key!  Sometime, in a future blog post I will explain why this is so critical, but suffice it to say that any table that does not have a primary key is considered by SQL Server a "heap".  If you are using something other than an Identity column for the primary key you better have a really compelling reason because it will cause major performance problems.  THERE IS NO SUCH THING AS A NATURAL KEY AND THEY SHOULD NEVER BE USED IN PLACE OF AN IDENTITY! So always use a surrogate key approach, even with join tables.

Security

I believe that with a good data layer like Linq to SQL there is no need for relegating all database access through stored procedures.  While it does remove some of the service area for venerability and bugs robust solutions like Linq to SQL are very limited by this approach.  You should grant specific access to tables and procs by user.  A good approach can be found on another one of my blog posts.

Object Naming

Table Names

• If you are running a database that preserves case (like SQL Server) tables should have no prefixes and should not contain underscores "_" unless it is a join table.  Table names should also be Pascal Cased.  If you are running a database that makes all tables upper case (like Oracle) then you have little choice but to use underscores everywhere.
• Avoid pluralizing table names (User vs Users).  This is a good idea for two reasons, first it can be confusing when doing the keys.  Do we use UserID or UsersID?  Second not all tables pluralize well (Addresses) so avoiding any plural names will keep it consistent.  It you are using Linq to SQL the designer will pluralize for you automatically.
• Join tables should the two or three tables that they are joining together as part of the name seperated by underscores.  (ex: User_Address, User_Order). Although they are many-to-many relationship see if you can find a principle table.  Users have orders, orders do not have users, therefore the User table comes first in the name.

Column Names

• Name the Primary Key Identity column the table name with ID.  (ex: UserID) With the possible exception of join tables, in which case just name the Identity ID.
• Use Pascal casing (ex: EachWordsStartsCapolatized)
• Do not use the table name as part of the column name.  If this is a shipping table don't name your columns ShippingAddress, just name it Address.
• Do not prefix column names with the type (ex: strUserName).  It makes the database much more difficult to work with.
• Use the correct data types.  Always use nvarchar types (unicode) rather than varchar types.  This avoids substantial complexity if you are ever requried to store non latin-based data!  Trust me, you do not want to have to deal with code pages in the database!  Also, use Date fields for dates, bit fields for boolean, etc.
• Don't make every column nullable!  Think through what data is absolutely required.  If you want to hold "partally complete records" then I would suggest a different table or different "staging" database. 
• Don't make a bit field nullable unless you have a great reason!
• Try to include a TimeStamp column if you think you may have to worry about concurrency.
• Don't prefix with anything.

Constraint & Index Names

• Name your constraints and indexes.  With the exception of foreign key constraints they are not automatically assigned meaningful names.
• Don't use prefixes and make light use of underscores.

Stored Procedure Names

• Don't prefix your stored procedures!  People used to prefix them with "sp" because existing procs in the database use this convention.  It has been presumed that sp stands for system procedure and it wouldn't make any sense to use that.  Seriously, prefixes are not very helpful in the database!
• The first part of the name of a proc should be the table name it works upon (ex: User_Insert).  If the proc works on multiple tables try to give it the name of the portion of the database this proc deals with.  For example, if it's a proc that the invoicing system uses it would be acceptable to name it Invoicing_Update, for example.
• Don't generate procs for simple Insert, Update, Delete, and Select unless you have a policy in place for accessing data exclusively from procs.
• Don't create any stored procedure you don't need or plan to immediately use.  At some point you will change the schema and you won't update procs your not using.  Someone may eventually want to use that proc later only to find it broken.
• The verb in the naming convention does not have to be relegated to "Insert, Update, Delete, Select".  It should say what it does.  Just be careful that if there is another procedure that does this same thing to another table that the verbs are named the same.
• You can add additional information to the proc name to help distinguish it from others.  (ex: User_Select_ByDate, User_Select_ByState)
• Don't use a prefix for arguments (ex: @ArgUserID). In my experience they don't help at all and are quite annoying!

Tips & Tricks

SQL Server 2008 has a policy manager that can help create and enforce policies like naming conventions!  Regardless of using SQL 2008 be sure to keep a Data Dictionary of your database! The database is the heart and soul of your business processes and should be well documented!  There is nothing worse than an unclean database!

Nathan Zaugg