Managing Portals as Host
Configuring Your Installation
As you're about to see, the Host has a lot of options and tools for configuring the environment in which portals live. As you learned in Chapter 4, in the context of the Portal Administrator, some capability is specifically appropriate for initial configuration, some for routine operations, and some for ongoing maintenance, reporting, and issue resolution. As you move through each of the Host Settings, you'll see how they apply to those needs.
Host Settings: Basic
Host Settings (Host ð Host Settings) is divided into two categories for the sake of organization: Basic Settings and Advanced Settings. Each category consists of a number of option groups.
| Note | As with Site Settings, there is an important text button at the bottom of the Host Settings page: Update. Despite the fact that a number of controls on the Host Settings page generate postbacks, no changes are saved until this button is clicked. |
There is also a final control at the bottom of the Host Settings page that falls outside of any option group, the Upgrade Log For Version selector and Go button. Choose a version and click Go to view a log file (if one exists) that contains any errors or warnings recorded during the installation or upgrade process for the selected version. The log files are created in the folder of the Data Provider, so the default installation of DotNetNuke puts those files in \Providers\DataProviders\SqlDataProvider\*.log.
The basic settings — Site Configuration, Host Details, Appearance, and Payment — are explored in the following sections.
Site Configuration
Table 5-1 describes each of the read-only fields displayed in the Site Configuration group under Basic Settings. This group is particularly helpful in identifying the context under which your installation of DotNetNuke is running. If you are communicating with an ISP or hosting company, these details may be useful in diagnosing any issue you might be investigating.
| Field | Description |
|---|---|
| DotNetNuke Version | Indicates the version of DotNetNuke that's currently running. Until version 3.0, the only way to verify the running version was to check a database value or to enable an option to display the version in the browser's title bar (see "Show Copyright Credits" in Table 5-3). The format of a DotNetNuke version number is [Major Version].[Minor Version].[Package Version] Major and minor versions combine to identify which functional version of DotNetNuke you are using (for example, 4.0). The Package Version indicates a particular package that may be an alpha or beta testing release, a public release, a security patch release, and so on. |
| Data Provider | Identifies the Data Provider that DotNetNuke is currently using. |
| .NET Framework | Indicates the version of the .NET CLR that DotNetNuke is running under. This can be helpful in ensuring proper setup when your server environment supports multiple versions of the ASP.NET framework. For developers, this is System.Environment.Version. |
| ASP.NET Identity | Identifies the Windows account name under which DotNetNuke is running (or the name of the account being impersonated). For developers this is System.Security.Principal.WindowsIdentity .GetCurrent.Name. |
| Host Name | Identifies the host name of the system DotNetNuke is running on. For developers this is Dns.GetHostName. |
Host Details
The host details establish the identity of the installation for both internal processing and external identity (see Table 5-2). For the most part, the settings of individual portals define their own identity. However, skin object support is available to pass on host information into portal-level skins. This can be useful for portals whose support requirements are met by their host so that they can dynamically inject appropriate title and contact information where needed.
| Setting | Description |
|---|---|
| Host Portal | This drop-down selection identifies which portal in the installation is to be considered the default. The default portal attributes are used where no other portal context can be determined. For example, when an invalid URL is used to reach the installation, the request is answered on the first alias of the specified Host Portal. |
| Host Title | This value is used to populate the text for the [HOSTNAME] skin token. Prior to version 3.0, you could see the [HOSTNAME] skin token in action on the bottom of the default skin. It was often imposed by the host as a means of injecting a "powered by" link into each portal's skin. |
| Host URL | Specifies the link target for the [HOSTNAME] skin token. (This is not the same as an alias for the default portal.) |
| Host Email | Most e-mail in DotNetNuke is sent to or from the individual Portal Administrators. However, there are a few specific cases where the Host e-mail address is used (for example, an SMTP configuration test, a [HELP] skin token, and so on). |
To avoid potential problems with outbound e-mail, ensure that the Host Email is a valid address on the SMTP Server (described later in Table 5-5).
Appearance
In Chapter 4, you learned about a number of optional settings for default portal appearance. If those choices are left unmade, the host default choices are applied. Additionally, the host has a couple of other configuration options that affect the appearance of portals in this installation. Table 5-3 summarizes the effects of each choice.
| Option | Description |
|---|---|
| Show Copyright Credits | Inserts the DotNetNuke version number into the browser's title bar and populates the [DOTNETNUKE] skin object. In the default skin, this is displayed as a small thin bar across the bottom of the page that shows the DotNetNuke copyright (see the bottom of Figure 5-3). |
| Use Custom Error Messages | Specifies whether DotNetNuke or ASP.NET will intercept module errors. If this option is selected, DotNetNuke displays only basic friendly messages to non-Admin users. If the user is an Admin (or Host) user, full error information is made available. Figures 5-4 and 5-5 illustrate the difference between the same error messages presented to Users and Administrators/SuperUsers, respectively. Detailed information is also retained in the error log. |
| Host Skin | If a skin is not specified in the portal Site Settings, this skin is used as the default for each page where a skin is not explicitly specified in Page Settings. The Host Skin, Host Container, Admin Skin, and Admin Container settings work exactly like their counterparts in the Portal Administrators Site Settings. For more detail, see Chapter 4. |
| Host Container | If a container is not specified in the portal Site Settings, this container is used as the default for each module where a container is not explicitly specified in Module Settings. |
| Admin Skin | If a skin is not specified in the portal Site Settings, this skin is used as the default for Admin pages. |
| Admin Container | If a container is not specified in the portal Site Settings, this container is used as the default for modules on every Admin page. |
| Upload Skin | Uploading a skin from the Host Settings loads it into the Host's default folder, which makes it available to all portals. This is in contrast to uploading from Site Settings, where it loads into the Portal Root folder. Skins uploaded from Host Settings are located in \Portals\_default\Skins. |
| Upload Container | Uploading a container from the Host Settings loads it into the Host's default folder, which makes it available to all portals. This is in contrast to uploading from Site Settings, where it loads into the Portal Root folder. Containers uploaded from Host Settings are located in \Portals\_default\Containers. |
Figure 5-3
Figure 5-4
Figure 5-5
The Show Copyright setting can be helpful in a development environment for quick reference to the running version (see Figure 5-3). In a production environment, however, it can pose a risk of exposure to anyone trolling specifically to locate DotNetNuke web sites. A simple Google search of the copyright statement or DNN in the title bar yields results for sites that have not disabled this option.
ASP.NET error messages can be helpful and informative for developers, but the familiar "yellow screen of death" (the standard ASP.NET error page) doesn't do much for the confidence of users and clients. DotNetNuke's Custom Error Messages option intercepts errors and encapsulates them within either the offending module's container or, in the case of a non-module error, injects them into the top of the Content Pane (see Figure 5-4).
Because the error information is confusing for users but valuable for support personnel, DotNetNuke displays different error information based on the current user. If the current user is an Administrator or SuperUser, full detailed information is provided (see Figure 5-5). Other users are spared the gory details and presented with a friendlier message.
Payment Settings
You learned in Chapter 4 that many of these Payment Settings have been preserved from earlier versions of DotNetNuke for legacy support purposes. For the Host, these settings come into play only as defaults for new portal creation or for portal subscription renewal. These Payment Settings (see Table 5-4) will be deprecated in a future version in favor of more robust eCommerce APIs.
| Setting | Description |
|---|---|
| Hosting Fee | Represents a default monthly charge associated with hosting a portal. This value is displayed on the Host's list of portals and is applied to new portals at the time of their creation. It can also be specified within a portal template, which would override this default value. If subscription renewal is activated, this fee is used for the monthly renewal rate. |
| Hosting Currency | Default host currency is used in conjunction with the specified Payment Processor (for example, as a required parameter for PayPal processing). This value is applied to new portals at the time of their creation but can also be overridden within a portal template. |
| Hosting Space (MB) | Specifies a default disk space limit for new portals. As with many other portal values, it can be overridden in a portal template. It is an enforced limit that's displayed at the base of the File Manager in the Portal Administrators view. As Host, you can change this value in the Site Settings for a specific portal. |
| Demo Period (Days) | If Anonymous Demo Signup is enabled, the Expiry Date for a new portal is set this many days into the future. As Host, you can change this value in the Site Settings for a specific portal. |
| Anonymous Demo Signup | This is a legacy feature and its use is highly discouraged. If this option is disabled, only the Host Administrator can create a new portal. If enabled, anonymous users can sign up and immediately log in as Portal Administrator to their own child portal. You have to create your own link somewhere to reach the signup page, but you can copy it from your browser's address bar after clicking Add New Portal on the Portals page. It should have a form like one of the following (depending upon your FriendlyUrls settings):
This page is not illustrated specifically, but it uses the same control as standard portal signup, which is shown later in Figure 5-12. A legacy feature of DotNetNuke, this setting was originally provided to showcase the capability of DotNetNuke to host private portals for potential clients. Although it's still supported in version 4.0, it is not without its share of legacy issues. Demo signup is enabled through-out the installation, not just on the Host Portal, so a clever anonymous user who locates a DotNetNuke site might try the demo portal signup. The Portal Root ensures file separation and the host File Upload Extensions setting protects from unsafe files, but a malicious user who finds your site could use you as an anonymous download location for the duration of the demo period (or until you catch him or her). Further, because the user chooses the child portal name, you could wind up with unpleasantly named folder paths indexed by search engines that you would rather not have. Because demo signup creates the user as Portal Administrator, a valid e-mail address is not even required. |
The Hosting Space option is included with the Payment Settings because it is recognized as a factor that commands premium pricing from a web host, and therefore generally also from a VAR (value added reseller). If a file upload attempt causes the hosting space to be exceeded, an error message is displayed (see Figure 5-6).
Figure 5-6
Enforcing the file upload limit protects you from rampant file uploading by well-meaning clients who don't understand the value of limited disk space. It provides the ability to proactively allocate your available disk space among clients as well as an opportunity to assess charge-back for additional usage.
| Note | File upload capabilities through an HTML Provider can be disabled. Unless the control maker has made it possible to intercept and filter file upload requests, DotNetNuke cannot ensure integrity of the portal files based on hosting space, allowable file extensions, or directory security. By default, all file uploads should be performed through the File Manager. |
Host Settings: Advanced
The Advanced Settings category of Host Settings includes Proxy, SMTP Server, and other settings. These are explored in the following sections.
Proxy Settings
In general, DotNetNuke should not require specific Proxy Settings. However, some modules may address additional ports for which Proxy Settings are required in your environment (for example, RSS, FTP, NNTP, and so on). Standard settings are configurable for the Proxy Server Name, Port, UserID, Password, and Timeout duration.
Check with your network administrator about appropriate values for these settings in your location.
SMTP Server Settings
Outbound e-mail requires that a valid SMTP server be specified. Table 5-5 explains the SMTP Server Settings in more detail.
| Setting | Description |
|---|---|
| SMTP Server | This value must resolve to a valid SMTP server. You can specify the server by computer name (for example, MYSERVER or Localhost), IP address (for example, 127.0.0.1), or URL (for example, smtpauth.earthlink.net). |
| SMTP Authentication | Unless your SMTP server is an open relay or filtered by IP, you need to specify an authentication method. Most SMTP servers use Basic authentication, although MS Exchange servers prefer NTLM. |
| SMTP Username | Login name for the account on the SMTP Server (optional). |
| SMTP Password | Password for the account on the SMTP Server (optional). |
After you've configured these settings, click the Test button to send a message to the Host Email. If the send operation is successful, you see a message to that effect at the top of the page. If the operation is unsuccessful, you may receive a CDO error (see Figure 5-7). This error is generally produced as a result of specifying an SMTP server that cannot be reached.
Figure 5-7
In hosting situations, the web server itself often runs a simple SMTP service for handling outbound e-mail generated by web sites. Although this setup initiates outbound e-mail, that mail is often flagged as SPAM by the target domains (especially domains like Hotmail.com, Yahoo.com, and so on). For best results, the SMTP server you specify should be the one in the MX record for your domain. Depending on your SMTP server's configuration, it may be necessary for Portal Administrators' e-mail addresses to be recognized on the server as well.
If you are testing from a home network via a broadband connection, be aware of your ISP's policies regarding SMTP servers. Generally speaking, most ISPs do not allow the trafficking of e-mail from other SMTP servers on their networks (as a SPAM control measure). You either need to configure DotNetNuke to use the credentials of your ISP account (just as you would in your local e-mail client) or configure a local SMTP server to relay through your ISP and specify that local server in DotNetNuke.
Other Settings
There are a number of other settings, including some that fall into the category of "super powers." Each setting is described in Table 5-6, but several of them are explained in greater detail later in the chapter when the functional aspects of the features that these settings control are discussed.
| Setting | Description |
|---|---|
| Control Panel | Select the Control Panel that Portal Administrators will use. Chapter 4 contains a full description of the choices. The capability to select the Control Panel exists largely to promote the concept of creating customized Control Panels for the host. If you created your own Control Panel, what would you make it look like? |
| Site Log Storage | Enables you to specify whether site log information is stored in the database or in files. File-based logs are written using the IIS 6 log conventions and are stored in the each portal folder with the following naming convention: / portals/<portalid>/logs/ex<yymmdd>.log. The database option is specified by default. |
| Site Log Buffer (Items) | This value defines the number of site log entries that are held in memory before storing them. Setting the buffer to 0 turns logging off entirely. Changing the buffer value does not affect the actual I/O cost of logging, but it does change where and when the cost is incurred. For example, if the log buffer is set to 1, every page request in every portal will incur the (slight) overhead of the log I/O, whereas if the log buffer is set to 20, only 1 in 20 requests will incur the overhead, but it will incur the overhead of all 20 I/O requests. |
| If the cache is cleared (whether by the restart of the application, in Host Settings, or by other means), any uncommitted items in the log buffer are lost. Individual buffers are cached for each portal, but this setting applies globally to all of them. Setting this value too high could result in data loss for low traffic sites whose cache might expire (and be lost) before reaching the buffer threshold. | |
| Site Log History (Days) | DotNetNuke performs site logging on an individual portal level and retains that information for the number of days specified. This value represents the default duration that will be applied to each new portal created. Changing this value has no effect on the configuration of existing portals, although as Host, you can change this value in the Site Settings for a specific portal. Expiration of site log data is contingent upon execution of a scheduled job, which periodically truncates the buffer to the duration specified. The PurgeSiteLog job must be enabled in the Scheduler for this to occur; otherwise the SiteLog table can grow unchecked. Job scheduling is covered later in this chapter. |
| Disable Users Online | UsersOnline is a popular functionality in many online portal applications, tracking and displaying the number of users registered on the site, how many users are currently using the site, and so on. However, this functionality imposes unnecessary processing overhead on each page request for sites that don't need it. By checking this option, logic within DotNetNuke that populates UsersOnline tracking tables and cache objects is bypassed for the entire installation. Setting this option is only half the process required to enable or disable UsersOnline. An essential part of UsersOnline is a corresponding scheduled job that performs periodic cleanup on the associated AnonymousUsers and UsersOnline database tables. If this job is enabled without UsersOnline in use, it is an unnecessary drain on system resources. Conversely, if it is not enabled when UsersOnline is in use, these tables grow unchecked. Job scheduling is covered later in this chapter. |
| Users Online Time (Minutes) | UsersOnline tracks the presence of users who have been active on the system within this time period. When the scheduled job runs to clear the tracking tables, it uses this time period as a basis for determining which records to clear. |
| UsersOnline does not track or log personal information and is not a mechanism for "spying" on users. It makes temporary note of who is logged in, what page they are currently visiting (no history), and how many anonymous users are currently viewing the site. The data is deleted after this duration has passed. | |
| Auto-Unlock Accounts After (Minutes) | As a security measure to thwart hacking attempts, DotNetNuke locks out a user account after a series of unsuccessful login attempts. Such an account can be automatically unlocked with a successful authentication after a certain period of time has elapsed. This value is the number of minutes to wait until the account is automatically unlocked. Enter 0 to disable the auto-unlock feature. |
| File Upload Extensions | This comma-separated list specifies the file extensions that are permissible through the File Manager. It comes prefilled with a variety of common "safe" file extensions and can be fully customized. The file management utilities within the portal are "intelligent" and reference this allowable file list. For example, a file that is renamed in the File Manager cannot be renamed with an invalid file extension. Likewise, files with invalid file extensions are ignored when an uploaded zip file is unpacked. |
| Skin Upload Permission | You can enable Portal Administrators to upload skin and container files by selecting Portal. To restrict them from uploading skin and container files, select Host. |
| Module Caching Method | Module instances have a Cache Time setting that can be modified to improve performance in relatively static modules. This setting controls whether module caching is performed on disk or in memory. Memory caching provides the most flexibility and is the highest performance method, but it also consumes the most system resources. When this option is enabled, HTML files are created and stored on the file system in the following format:
\Portals\<portalid>\Cache\TabModule_<tabmodule id>_<language>.htm |
| Performance Setting | A variety of cache objects in DotNetNuke provide for increased performance. They do not all have the same duration. They expire based on their specific functionality — for example, User objects expire more often than Portal objects. Changing this setting applies a common multiplier that affects their relative duration (or lifespan). The duration is enforced within DotNetNuke, but it's still subject to external settings that govern the site (such as recycling the ASP.NET worker process). Moderate caching is the default setting. The No Caching option is primarily developer-or support-oriented. Without the benefit of the caching features of ASP.NET, the amount of work performed on each page request renders DotNetNuke slow to run and is not recommended. However, this option can be useful in tracking down a caching-related issue. |
| Clear Cache | Enables the Host to manually clear the cache on demand. Generally this is not required; however, as Host, you typically have access to manipulate database tables directly. Table updates applied this way bypass the application and may not be reflected until the cache is updated. You can force an update of cache to reflect your manual changes by clearing it. (Clearing the cache this way also dumps buffered logs, so it should be performed only when necessary.) |
| Scheduler Mode | The Timer Method maintains a separate thread to execute scheduled tasks while the worker process is alive. Alternatively, the Request Method triggers periodic execution of tasks as HTTP Requests are made. You can disable the Scheduler by selecting Disabled. The Scheduler is examined in detail later in this chapter. |
| Enable Event Log Buffer? | Like the site log, the event log can also be buffered for performance to avoid the overhead associated with logging I/O on every request. If checked, this setting causes event log entries to be buffered into cache and periodically written to the data store. If unchecked, log entries are written immediately. Unlike site logging, event log buffering is governed by a scheduled task (PurgeLogBuffer). If this task is not enabled or if the Scheduler is stopped, this setting has no effect and logging occurs as if this setting were unchecked. Event Logging is covered in more detail later in this chapter. |
| Use Friendly Urls | If checked, DotNetNuke invokes the FriendlyUrl Provider. By default, DotNetNuke installs a provider that produces "machine friendly" URLs that enable better indexing by search engines. |
| For developers, the default provider behavior is controlled by a rule file (siteurls.config) located in the web root. The default modules provided with DotNetNuke work well with this provider. However, not every module may work well with any specific implementation of Friendly Urls. It is advisable to ensure that any module you employ works with your FriendlyUrl Provider. For more information on FriendlyUrls, see Chapter 8. | |
| Help URL | The target URL for administrative help, including the Help button in the Control Panel and the Online Help menu item for administrative functions. If this field is blank, the Control Panel Help button is disabled and the Online Help menu item is not available on administrative functions. By default, DotNetNuke provides context-sensitive online help for all standard modules and administrative features at the following site:
|
| Enable Module Online Help | If enabled, an item for Online Help appears in every Module Actions Menu. This requires that a Help URL be configured in the Module Definitions for each module in use, although the developer may have provided this. |
EAN: 2147483647
Pages: 182