Configuring the Application

When you're finished setting up the database, you should create a new ASP.NET Web Application on your test server. In the sample code, the Web application is called WS_Ch15. When that is done, you'll need to make a few server changes to allow this application to work. One of the Web Services that you'll use returns a long stream of XML, which will need to be converted for use with the Web page. One of the easier ways to do this is to write the string to a text file and then read it into the DataSet using the ReadXML function. To do this, however, the ASP.NET worker process (the user ID is ASPNET) needs to have access to write to the server at some location. Find a directory to use and give the ASPNET user ID Full Control over that directory using NTFS permissions.

The next step is to set up the web.config file for the application. Listing 15.3 shows the settings you should put into this file to configure the security properly.

Listing 15.3. web.config—Security Settings
<?xml version="1.0" encoding="utf-8" ?>
<configuration>

  <system.web>

    <!--  DYNAMIC DEBUG COMPILATION
          Set compilation debug="true" to insert
          debugging symbols (.pdb information)
          into the compiled page. Because this
          creates a larger file that executes
          more slowly, you should set this value
          to true only when debugging and to
          false at all other times. For more information,
          refer to the documentation about
          debugging ASP.NET files.
    -->
    <compilation defaultLanguage="vb" debug="true" />

    <!--  CUSTOM ERROR MESSAGES
          Set customErrors mode="On" or "RemoteOnly" to
          enable custom error messages, "Off" to disable.
          Add <error> tags for each of the errors you want to handle.
    -->
    <customErrors mode="RemoteOnly" />

    <!--  AUTHENTICATION
          This section sets the authentication policies of
          the application. Possible modes are "Windows",
          "Forms", "Passport" and "None"
    -->
    <authentication mode="Forms">
						<forms name="Users"
						path="/" loginUrl="login.aspx" protection="All" timeout="20" />
						</authentication>

    <!--  AUTHORIZATION
          This section sets the authorization policies
          of the application. You can allow or deny access
          to application resources by user or role.
          Wildcards: "*" mean everyone, "?" means anonymous
          (unauthenticated) users.
    -->
    <authorization>
						<deny users="?" />
						</authorization>

    <!--  APPLICATION-LEVEL TRACE LOGGING
          Application-level tracing enables trace log
          output for every page within an application.
          Set trace enabled="true" to enable application
          trace logging.  If pageOutput="true", the
          trace information will be displayed at the bottom
          of each page.  Otherwise, you can view the
          application trace log by browsing the "trace.axd"
          page from your web application
          root.
    -->
    <trace enabled="false" requestLimit="10" pageOutput="false"
       traceMode="SortByTime" localOnly="true" />

    <!--  SESSION STATE SETTINGS
          By default ASP.NET uses cookies to identify which
          requests belong to a particular session.
          If cookies are not available, a session can be tracked
          by adding a session identifier to the URL.
          To disable cookies, set sessionState cookieless="true".
    -->
    <sessionState
            mode="InProc"
            stateConnectionString="tcpip=127.0.0.1:42424"
            sqlConnectionString="data source=127.0.0.1;user id=sa;password="
            cookieless="false"
            timeout="20"
    />

    <!--  GLOBALIZATION
          This section sets the globalization settings of the application.
    -->
    <globalization requestEncoding="utf-8" responseEncoding="utf-8" />

  </system.web>
  <location path="login.aspx">
						<system.web>
						<authorization><allow users="?" /></authorization>
						</system.web>
						</location>
						<location path="profile.aspx">
						<system.web>
						<authorization><allow users="?" /></authorization>
						</system.web>
						</location>
						<appSettings>
						<add
						key="ConnectionString"
						value="server=(local);database=WSCh15;uid=sa;pwd=;" />
						</appSettings>
</configuration>

The first section that is marked in this file indicates that this application will be handling security via Forms. Security in ASP.NET applications can be handled in four different ways—no security, form (or user-defined), Microsoft Passport, and Windows authentication. Because using Microsoft Passport isn't practical for most developers, and because most public web sites don't use Windows authentication, forms authentication is probably going to be the most likely choice for most applications that make their way to the Web.

The name attribute is the name of the cookie that will be used for authentication. You won't have to access that cookie directly; instead, there are functions in the FormsAuthentication object (part of System.Web.Security namespace) that makes your job easier. The loginURL parameter specifies what page to use to let the user log into the application. The application will use the cookie to determine if the user has logged in; if not, the user will automatically go to the login page.

The next section in the configuration file that's marked removes access to anonymous users for the site. The question mark refers to anonymous users in this case, so telling the application to deny access to all anonymous users has the effect of locking everyone out who does not authenticate using the login page that you'll build. The problem with that is twofold: users still need access to the login page, and new users need to be able to register using the profile page.

These concerns are covered by the <location> tags at the end of the document. You can think of the <location> tags as overrides. Each of these tags specifies that one page (login.aspx and profile.aspx) can be accessed by unauthenticated users.

The last section is the database connection string, which you should change to fit your server and Web configuration. With the configuration complete, it's time to write some code.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset