Archives

Archives / 2005

  • ASP.NET files and inheritance

    10 Comments

    I've been completely silent on my blog for a few months while having my head down in projects, but I thought I should start up some activity, even if it's a quickie.  I feel that I've been covering so much ground but not enough time to report on it.

    Read more...

  • Schema Changes in the latest ASP.NET V2.0 bits

    6 Comments

    I just installed the latest version of Visual Studio 2005 and the .NET Framework.  I went from version v2.0.50215 (common February version) to v2.0.50727 (August version).  The install went smooth and everything was good for the most part.

    One issue I ran into though is that the Membership provider didn't work.  I received an error "Procedure or function aspnet_Membership_GetPasswordWithFormat has too many arguments specified.".  Fortunately the error is descriptive enough to be quite obvious.  The database schema has changed slightly between the two builds.  I am using a SQL 2000 database that was prepared using the v2.0.50215 aspnet_regsql.exe tool so the latest version of the framework doesn't match with the schema on the database.

    The difficult way
    To let you learn from my mistakes, I'll explain what I tried at first.  To upgrade I created a backup of the database, ran the v2.0.50727 aspnet_regsql.exe tool to remove the schema with the goal to ran it again to create the schema back again.  The first issue was the v2.0.50727 aspnet_regsql.exe tool ran into errors removing the schema which was created using v2.0.50215.  After some manual adjustments I was able to complete it.  Then I ran aspnet_regsql.exe again to create the schema on the new database.  I then copied over just the relevant data from the backup database to the new live database.  This worked fine but it was a lengthy process.

    The better way
    I'm kicking myself for not thinking of it before but as an experiment I created a test database using the old v2.0.215 schema and ran the aspnet_regsql.exe tool, but this time I just selected the option to "Configure SQL Server for application services".  Sure enough it upgraded everything and didn't mess with my data.  The ASP.NET team made upgrading between minor versions almost too easy.

    Conclusion
    When upgrading to a newer version of the ASP.NET framework, simply run the aspnet_regsql.exe tool and select "Configure SQL Server for application services."  It serves as an upgrade option.

    I'm not promising that this will work between all minor upgrades, but it did work between this one.  Warning: Make sure to create a backup of your database before any of these changes, even if it has worked properly in the past.  Any large change of any sort should be preceded by a fresh backup of the database.

    Read more...

  • Enabling Roles in ASP.NET v2.0

    4 Comments

    By default the Roles provider is defined in machine.config but it isn't enabled.  Attempting to use the Roles feature before it is enabled will throw the following error:

    Read more...

  • Encrypting the connection string in ASP.NET V2.0

    7 Comments

    ASP.Net V2.0 has much improved encryption over v1.x including the ability to encrypt any part of the connection string.  Of course there is some performance overhead to do this so only sections that have sensitive information should be encrypted.

    Read more...

  • How to find the SiteID in IIS5 and IIS6

    5 Comments

    Occasionally I need to explain how to find the SiteID / Site Identifier in IIS5 and/or IIS6 so I thought I would quickly blog on how to do that so that I have a page that I can reference rather than typing it out each time.

    Read more...

  • Changing the Password Complexity in ASP.NET V2.0

    24 Comments

    One of the first things many people try with ASP.NET V2.0  (currently in Beta 2) and with the starter kits is to create a new user.  Whether it is the CreateUserWizard, a starter kit form or using the membership namespace from code, creating a new profile is going to happen.  Immediately following that is often a sigh of frustration when a fairly non-descriptive error occurs: "Please enter a different password."  What is that supposed to mean?  Is it recommending passwords for us now and not pleased with the one we chose?  Did the passwords not match?  Even carefully double checking and trying again with a password that is 7 characters and has numbers and upper case and lower case letters triggers this non-descriptive error.

    The issue is simply this: ASP.NET V2.0, at the time of writing, has a password complexity requirement of 7 characters and at last 1 non-alphanumeric character.  For example, 'Complex592PaSsWoRd' isn't complex enough.  A space or a special character is required.  Now, being cautious about security is one thing, but many of the V2.0 sites out there now are either test sites, personal or club starter kits or something fairly light.  Personally I like to loosen the requirements somewhat, or even loosen them a lot and allow the user to determine how complex they want their password. 

    Fortunately there are a couple solutions and neither are too complex.  The first solution obviously is to enter a more complex password.  The second is to override the default complexity requirement and put in your own.

    The provider that controls this is the membership provider.  This is set by default in the machine.config file on the server.  It can be changed at the machine.config file or overridden in the web.config file at the site level.

    The two properties that control this are minRequiredPasswordLength and minRequiredNonalphanumericCharacters.  They aren't in machine.config by default in the Beta 2 timeframe.  I'm not sure if there are plans to change this or not.  To override it, simply add them to the <add name="AspNetSqlMembershipProvider" /> section.  The minRequiredPasswordLength property must be at least 1, while the minReqiredNonalphanumericCharacters property can be 0.  Here is an example of the two lines to add which removes the requirements completely and allows the user to decide on their password.  Don't hold me accountable if you open this too much, but I give this example as the other extreme of the default settings.
          minRequiredPasswordLength="1"
          minRequiredNonalphanumericCharacters="0"

    Now, let's say we want to do this at the web.config level.  This is easy enough too.  The gotcha is that because it already exists at the machine.config level, there will be a clash between the two.  So, you must first "remove" the provider set at the machine level and add it back at the site level.  To remove the existing one, (I'm assuming default names) you use <remove name="AspNetSqlMembershipProvider"     />

    Here is an example of a complete web.config file that could be used.  If you have an existing web.config file that you want to work this into, take the section between and including <membership> and </membership>     and place it in your <system.web> section.

    <?xml version="1.0"?>
    <    configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"    >
      <    connectionStrings    >
            <remove name="LocalSqlServer"    />
        <    add name="LocalSqlServer" connectionString="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|aspnetdb.mdf"     />
      </    connectionStrings    >
      <    system.web    >
        <    membership    >
          <    providers    >
            <    remove name="AspNetSqlMembershipProvider"     />
            <    add name="AspNetSqlMembershipProvider"
                      type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
                      connectionStringName="LocalSqlServer"
                      enablePasswordRetrieval="false"
                      enablePasswordReset="true"
                      requiresQuestionAndAnswer="true"
                      applicationName="/"
                      requiresUniqueEmail="false"
                      minRequiredPasswordLength="1"
                      minRequiredNonalphanumericCharacters="0"
                      passwordFormat="Hashed"
                      maxInvalidPasswordAttempts="5"
                      passwordAttemptWindow="10"
                      passwordStrengthRegularExpression=""     />
          </    providers    >
        </    membership    >
          </system.web    >
    </configuration    >

    Of course anything in my example can be adjusted however you want as long as it is within an allowed range.  Take note especially of the connectionStringName which is referenced in the ConnectionString section of web.config and/or machine.config.  If you changed your connection string name, then make sure to update the reference to that connection string there.  Another thing to take note of is the connection string in this example.  That connection string will only work if Sql Server Express is installed on the server and "user instancing" is enabled.  At ORCS Web (www.orcsweb.com) for example, we disable user instancing because of security considerations, create a database when first setting up the site, and provide an alternative connection string which should be used instead. 

    That's it.  Once you set this, you'll be able to have a password that isn't quite so complex.  This quick example only briefly covers other considerations like the connectionStringName, user instancing, type of database used and additional properties but I hope it gives enough information to lay the foundation of managing the password complexity within ASP.NET v2.0.

    Read more...