Locations of visitors to this page
    Sprouting Synapses       Minimize  

             
            Minimize  
Author: SkySigal Created: 7/1/2008 12:17 PM
.ASP.NET Configuration Notes (ie: web.config, providers, etc.)

By SkySigal on 10/21/2008 2:30 PM

Visual Studio does it for you automatically, so this doesn't come up too often, but if you need to create the Provider tables in an already existing database, you'll need aspnet_regsql. You'll find it here:

C:\WINDOWS\Microsoft.NET\Framework\<versionNumber>\aspnet_regsql.exe

Using the CommandLine

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_regsql.exe 
    -E -S localhost [-d aspnetdb] -A all

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_regsql.exe 
    -U me -P justkidding -S localhost [-d aspnetdb] -A all

Flags to use are:

  • -W Runs the tool in wizard mode.
  • -S The name of the server computer running SQL Server. Can also include an instance name, such as .\INSTANCENAME.
  • -U The SQL Server User Name. Needs to be used with (-P) option. Not necessary if using Windows credentials (-E).
  • -P The SQL Server password. Use with (-U) option. Not necessary if using Windows credentials (-E).
  • -E Authenticates using the Windows credentials of the currently logged-in user.
  • -d Name of the database to create or modify. If not specified, the default is "aspnetdb".
  • -C The connection string to the computer running SQL Server where the database is/will be installed. 
        Not necessary if only specifying server (-S) and login (-U and -P, or -E) information.
  • -sqlexportonly filename Generates a SQL script file only.

Using the GUI

The GUI is launched without any command line arguments:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_regsql.exe

In order to get this:

image

image

image

image

etc.

 

 

 

 

Links

powered by metaPost

By SkySigal on 8/27/2008 6:56 PM

blog_aspnet_logo_config

This was a really painful lesson to learn at the time (still is ongoing) ...wish I had started off right, at the very beginning, rather than having a lot of code to go back and write alternate solutions for:

Read More »

By SkySigal on 7/9/2008 10:11 AM

blog_aspnet_logo_config Karl Seguin has a great post introducing Memcached:




<<<You're probably already familiar with Memcached - it's a highly efficient distributed caching system. It's used generously by all the big web 2.0 players (In may 2007 it was revealed that Facebook relies on 200 16GB quad-core dedicated Memcached servers). Interest in Memcached from the .NET community has been relatively low (although over the last year more and more people are talking about it). Frankly, if you're doing anything that requires horizontal scaling you're seriously shooting yourself in the foot by overlooking it. It runs on windows - although we run it on Linux and there's really no reason for you not to learn that too!

Fundamentally, there are two problems with the built-in cache. First, it's limited to the memory of a single system which happens to be shared with the rest of your application domain. Secondly, if you have two servers, each with their own in-memory cache, users are likely to see very weird synching issues. Memcached isn't as fast as in-memory caching, but will scale to virtually unlimited amount of memory. There isn't any redundancy of failover, simply memory spread across multiple servers.
>>>

powered by metaPost

By SkySigal on 7/6/2008 4:25 PM

aspnet_logo_config  Good to remember:

 

 

<<<In a Web farm, you cannot guarantee which server will handle successive requests. If a user is authenticated on one server and the next request goes to another server, the authentication ticket will fail the validation and require the user to re-authenticate.

The validationKey and decryptionKey attributes in the machineKey element are used for hashing and encryption of the forms authentication ticket. The default value for these attributes is AutoGenerate.IsolateApps. The keys are auto-generated for each application, and they are different on each server. Therefore, authentication tickets that are encrypted on one computer cannot be decrypted and verified on another computer in a Web farm, or in another application on the same Web server.

To address this issue, the validationKey and decryptionKey values must be identical on all computers in the Web farm. For more information about configuring the machineKey element, see How To: Configure MachineKey in ASP.NET 2.0.
>>>

Src: “Explained: Forms Authentication in ASP.NET 2.0”

powered by metaPost

By SkySigal on 7/4/2008 12:08 PM

aspnet_logo_config Need this be mentioned? Probably not…but just in case.

If you want to see debug messages generated by ASP.NET, don’t forget to:

  1. Turn compilation debug message ON (so that the framework produces PDB files)
  2. Turn customErrors OFF so that you can see the debug messages:
<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
  <location inheritInChildApplications="false">
    <system.web>
      ...
      <compilation debug="true"/>
      ...
      <customErrors mode="Off"/>
      ...
      </system.web>
   </location>
</configuration>

 

(And when you’ve finished….reverse both values so that debugging is turned off, and error messages go back to being custom…)

 

<!--
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
-->
powered by metaPost

By SkySigal on 7/3/2008 7:11 AM

aspnet_logo_config As you may already know, I’ve been writing a set of Generic Db (Sql-92) Providers for Membership, Roles, Profiles, and Personalization, and am nearly done.

 

Since the primary purpose of the Membership and Roles providers is to provide Authentication on your website, and use it to limit access to certain directories (Authorization), I’m going to go over the two parts again below.

Authentication, Roles, and Authorization are distinct  services.
Although Authentication is almost always used in conjunction with other services, such as Roles, or Authorization, it is important to recognize that Authentication is only the process of recognizing a returning user to your website, no more, no less.

One can then use other services to assign Roles to an Authenticated user, and/or use Authorization to limit access to specific users and/or roles.
Because there is no meaningful way of setting up Authentication without setting up Roles and/or Authorization, they are always discussed together (but that doesn’t make them the same thing).

Authentication

The first step is always authentication, which you can setup in one of the following Modes:

  • None
  • Forms (ie Forms Authentication),
  • Windows (Windows NT authentication, used with any IIS authentication (Basic, Digest, Integrated Windows authentication ( NTLM/Kerberos ), or certificates.
  • Passport (Microsoft Passport Authentication).

Intranet websites often use Windows authentication, and 9 times out of 10, websites that are intended for public use will use the Forms authentication mode.

We’ll not be discussing the Windows mode, and instead be focusing only on the Forms mode.

Setting up a Forms Authentication environment
To set up Forms authentication environment, we have to do the following steps:

  • add an authentication element to the web.config file
  • create a login.aspx page, with a asp:login control on it.
  • define a list of Users.

The simplest example of such a setup would be the following two snippets:

1. A really rudimentary login.aspx page:

<%@ Page Language="C#" AutoEventWireup="true" %>
<!DOCTYPE html PUBLIC 
    "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
  <head runat="server">
    <title>Untitled Page</title>
  </head>
  <body>
    <h5>Login Please:</h5>
    <form id="form1" runat="server">
        <div>
            <asp:Login runat="server"/>
        </div>
    </form>
  </body>
</html>

2. A minimalist root web.config authentication section:

<authentication mode="Forms">
   <forms loginUrl="Login.aspx" protection="All" timeout="30" path="/" /> 
</authentication>

Note that the above authentication section is doing the following:

  • specifying that the mode=Forms,
  • specifying that the page that non-authenticated users are redirected to is called login.aspx
  • the optional protection attribute is described in full here, but you can safely omit it for most purposes.
  • the timeout is self-evident.
  • the Path is optional, but important to consider (I generally would set it):
    Specifies the path for cookies that are issued by the application.
    The default is a slash (/), because most browsers are case-sensitive and will not send cookies back, if there is a path case mismatch.

3. The above is not complete: you’ve defined the system by which to authenticate, but you still need to define an actual list of users/passwords to authenticate against.
The simplest solution (but not the best -- see further down) is to define a list of users/passwords directly within the web.config by adding a credentials element to the forms element:

<authentication mode="Forms">
   <forms loginUrl="Login.aspx" protection="All" timeout="30" path="/">
     <credentials passwordFormat="Clear">
       <user name="user1" password="0000" />
       <user name="user2" password="1111" />
     </credentials>
   </forms>
</authentication>

Note
Obviously this way of adding users/passwords is rudimentary: one can only setup a very small list of users in the web.config, and the list is not dynamic, so the above solution is never really used in a real life situation (one would use a Membership Provider instead, which we will be presenting at the bottom).

How it works - the Authenticate process

We have a login form, and we have a list of users/passwords, but if you try it out, you can click the Login control’s submit button until you are blue in the face without getting past it.

That is because you have a form, and you have a list – but nobody is actually checking against the list.

You do this by by handling the Authenticate event of the Login control, and from there calling a method of the FormsAuthentication static class to check the name and password against the credentials in the system.web file.

MSDN Documentation:

  • "The Authenticate event is raised when a user uses the Login control to log in to a Web site.
    Custom authentication schemes can use the Authenticate event to authenticate users."
  • "Custom authentication schemes should set the Authenticated property to true to indicate that a user has been authenticated."
  • "When a user submits his or her login information, the Login control first raises the LoggingIn event, then the Authenticate event, and finally the LoggedIn event."
protected void Login1_Authenticate(object sender, AuthenticateEventArgs e){
  string userName = uiLogin.UserName;
  string password = uiLogin.Password;
  //Note:
  //By setting the return value, the form
  //will automatically be Response.Redirected to the original page.
  e.Authenticated = 
    FormsAuthentication.Authenticate(userName, password);
}

If the Authenticate helper method says its ok, remember to set the e.Authenticated return flag, so that the Login control then continues to by building an Identity cookie and redirect the page to the original page, as demonstrated in the following proxy code:

class Login: CompositeControl {
  void AttemptLogin(string, string){
    ..raise.
    if (args2.Authenticated){
      FormsAuthentication.SetAuthCookie(
        this.UserNameInternal, 
        this.RememberMeSet);
      this.OnLoggedIn(EventArgs.Empty);
      this.Page.Response.Redirect(this.GetRedirectUrl(), false);
    }
    ...
  }
}
&l ... Read More »

By SkySigal on 7/3/2008 7:02 AM

aspnet_logo_config I’ve already mentioned in a previous post how you can use the web.config to add a reference to a specific assembly to all pages in the website, saving you a ton of typing, and making subsequent changes much easier: