Newest KB Articles in Programming, error messages and sample code

WordPress login and xmlrpc.php IIS restrictions (Cloudflare)

Wed, 29 Oct 2025 18:19:03 GMT

General information about setting up an allow list for wp-login.php, /wp-admin, and xmlrpc.php can be found in the main WordPress login and xmlrpc.php IIS restrictions article. With this article focused on the additional markup when using Cloudflare.

Cloudflare IP Ranges Allow List

An updated list of Cloudflare IP ranges can be found at https://www.cloudflare.com/en-in/ips/

In addition to the Cloudflare IP ranges, the ipSecurity attribute "enableProxyMode" needs to be set to true in order to obtain the original visitor IP, which is sent via an X-Forwarded-For header. Both updates would be made to the top level system.webServer element, outside of the location tags used for the wp-login.php, wp-admin, and xmlrpc.php allow lists.

Example

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <security>
      <ipSecurity enableProxyMode="true">

          <!--Cloudflare allow list-->
          <add ipAddress="103.21.244.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="103.22.200.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="103.31.4.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="104.16.0.0" subnetMask="255.248.0.0" allowed="true" />
          <add ipAddress="104.24.0.0" subnetMask="255.252.0.0" allowed="true" />
          <add ipAddress="108.162.192.0" subnetMask="255.255.192.0" allowed="true" />
          <add ipAddress="131.0.72.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="141.101.64.0" subnetMask="255.255.192.0" allowed="true" />
          <add ipAddress="162.158.0.0" subnetMask="255.254.0.0" allowed="true" />
          <add ipAddress="172.64.0.0" subnetMask="255.248.0.0" allowed="true" />
          <add ipAddress="173.245.48.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="188.114.96.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="190.93.240.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="197.234.240.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="198.41.128.0" subnetMask="255.255.128.0" allowed="true" />

      </ipSecurity>
    </security>
  </system.webServer>

Example WordPress web.config with Permalinks

Completed web.config with sections added to restrict access to wp-login.php, /wp-admin and xmlrpc.php when routing traffic through Cloudflare. Requires updating the ipAddress for any site visitors that should have access to wp-login.php and /wp-admin.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

  <location path="wp-login.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <add ipAddress="xx.xx.xx.xx" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

  <location path="wp-admin">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <add ipAddress="xx.xx.xx.xx" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>
  
  <location path="xmlrpc.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <!--Jetpack allow list-->
          <add ipAddress="122.248.245.244" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="54.217.201.243" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="54.232.116.4" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="192.0.80.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="192.0.96.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="192.0.112.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="195.234.108.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="192.0.64.0" subnetMask="255.255.192.0" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

  <system.webServer>
    <rewrite>
      <rules>
        <rule name="WordPress Rule" stopProcessing="true">
          <match url=".*" />
            <conditions>
              <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
              <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            </conditions>
          <action type="Rewrite" url="index.php" />
        </rule>
      </rules>
    </rewrite>

    <security>
      <ipSecurity enableProxyMode="true">
          <!--Cloudflare allow list-->
          <add ipAddress="103.21.244.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="103.22.200.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="103.31.4.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="104.16.0.0" subnetMask="255.248.0.0" allowed="true" />
          <add ipAddress="104.24.0.0" subnetMask="255.252.0.0" allowed="true" />
          <add ipAddress="108.162.192.0" subnetMask="255.255.192.0" allowed="true" />
          <add ipAddress="131.0.72.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="141.101.64.0" subnetMask="255.255.192.0" allowed="true" />
          <add ipAddress="162.158.0.0" subnetMask="255.254.0.0" allowed="true" />
          <add ipAddress="172.64.0.0" subnetMask="255.248.0.0" allowed="true" />
          <add ipAddress="173.245.48.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="188.114.96.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="190.93.240.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="197.234.240.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="198.41.128.0" subnetMask="255.255.128.0" allowed="true" />
      </ipSecurity>
    </security>
  </system.webServer>
</configuration>

Problem with establishing encrypted connection to SQL server from your application

Sat, 01 Apr 2023 22:43:14 GMT

Error encountered when connecting to SQL server with encrypted connection from your application (Classic ASP, ASP.NET, .NET Core, and PHP).

The certificate chain was issued by an authority that is not trusted.

Reason:

This error occurs because a self-signed certificate is being used for encrypted connections on our SQL server.

To resolve this issue:

For Classic ASP/ASP.NET/.NET Core applications, update your connection string with the following:

"Data Source=DBSERVERNAME;Initial Catalog=YOURDATABASENAME;User ID=YOURUSERID;Password=YOURPASSWORD;Encrypt=yes;TrustServerCertificate=true"

For PHP applications add the following:

$connectionInfo = array( "Database"=>"YOURDBNAME", "UID"=>"YOURUSERID", "PWD"=>"YOURPASSWORD","Encrypt"=>true,"TrustServerCertificate"=>true);

Response header updates for PCI Compliance

Tue, 21 Jun 2022 21:16:06 GMT

Server and Scripting Response Headers

To meet PCI compliance requirements, four response headers often have to be removed: server, X-Powered-By, and in the case of a .NET (MVC) app, X-AspNet-Version and X-AspNetMvc-Version. The response headers can be viewed in a browser using dev tools like Chrome Developer Tools, the referenced headers being the last four in the screenshot below.

Removing the headers is fairly straight forward. With all but X-AspNetMvc-Version being removed via web.config update. In the case of X-AspNetMvc-Version, it is disabled in a project's global.asax(.cs) file.

Server

If a site is currently on IIS 8, it's recommended to have the site migrated to IIS 10 / Windows Server 2019 by Support. Where on IIS 10 the server header can be removed via the attribute removeServerHeader

<system.webServer>
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
</system.webServer>

Otherwise on IIS 8 the header response would be removed via the following rewrite rule for RESPONSE_Server. Unlike the attribute above, this method still returns a "Server" header, but the response is blank

<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="Remove RESPONSE_Server" >
        <match serverVariable="RESPONSE_Server" pattern=".+" />
        <action type="Rewrite" value="" />
      </rule>
    </outboundRules>
  </rewrite>
</system.webServer>

X-Powered-By

The X-Powered-By header is removed via the customHeaders element

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

X-AspNet-Version and X-AspNetMvc-Version

ASP.NET version is disabled using the enableVersionHeader attribute

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

To remove X-AspNetMvc-Version, "MvcHandler.DisableMvcResponseHeader = true" is added to the Application_Start event of the global.asax or global.asax.cs as in the examples below

protected void Application_Start()
{
    MvcHandler.DisableMvcResponseHeader = true;
}

    Sub Application_Start()
        MvcHandler.DisableMvcResponseHeader = True
    End Sub

Example web.config and response

An example web.config removing the server, X-Powered-By and X-AspNet-Version would look like

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Then, along with the project update for MVC, the resulting response header would be

Additional Response Headers

Additional response headers may be required, for example Content-Security-Policy (https://content-security-policy.com/), to set restrictions on how elements are loaded on the site. Because various headers may be required, a basic syntax example is

<httpProtocol>
  <customHeaders>
    <add name="headerName" value="setting or directive" />
  </customHeaders>
</httpProtocol>

As an example, and not explicitly a guide, nopCommerce has many of these customHeaders set by default, as seen below

<httpProtocol>
  <customHeaders>
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="X-Frame-Options" value="SAMEORIGIN" />
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
    <add name="Content-Security-Policy" value="default-src 'self'; connect-src *; font-src * data:; frame-src *; img-src * data:; media-src *; object-src *; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';" />
    <add name="Referrer-Policy" value="same-origin" />
    <add name="Permissions-Policy" value="accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=*, usb=()" />
  </customHeaders>
</httpProtocol>

Note that setting these customHeaders can have unintended consequences on what elements are being loaded on the site. And extra care and review may be required versus the headers detailed in the first section of the article.

Example conflict

A simple Content Security Policy restriction can be set with default-src. Description of the directive: The default-src directive defines the default policy for fetching resources such as JavaScript, Images, CSS, Fonts, AJAX requests, Frames, HTML5 Media.

And basic web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <httpProtocol>
        <customHeaders>
          <add name="Content-Security-Policy" value="default-src 'self';" />
        </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Which would have the intended effect of preventing images from being loaded from external sources with the message

Refused to load the image 'https://externalDomain/image.png' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.

However, some Javascript based functions may stop loading on the site with the message

Refused to execute inline event handler because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.

Description of unsafe-line being: Allows use of inline source elements such as style attribute, onclick, or script tag bodies (depends on the context of the source it is applied to) and javascript: URIs

Requiring an update to the Content-Security-Policy above to now read

<add name="Content-Security-Policy" value="default-src 'self'; script-src 'unsafe-inline' *.domain.com domain.com;" />

Adding the unsafe-inline keyword and defining from which domains the Javascript can be loaded.

WordPress login and xmlrpc.php IIS restrictions

Fri, 21 Aug 2020 21:26:45 GMT

wp-login.php, /wpadmin and xmlrpc.php are often be targetted by bots in an attempt to compromise WordPress sites. But access can be restricted to the admin section of the site and to xmlrpc.php through the use of the ipSecurity element of a web.config. An overview of the sections and implementation can be found below.

In cases where traffic is being routed through Cloudflare, additional markup is required which can be found in the WordPress login and xmlrpc.php IIS restrictions (Cloudflare) article.

wp-login.php and /wpadmin

First obtain the IPv4 address of any user that requires access to the admin section of WordPress. When not known, https://whatismyipaddress.com/ can be used. Then from the example below, add the two new sections to the configuration element of the site's web.config.

The two "xx.xx.xx.xx" below would be replaced with the IP address of any WordPress users. If there is more than one user, simply copy and paste as many "add ipAddress" lines as needed below the one in the example.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

  <location path="wp-login.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <add ipAddress="xx.xx.xx.xx" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

  <location path="wp-admin">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <add ipAddress="xx.xx.xx.xx" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

xmlrpc.php

xmlrpc.php is a WordPress API that is being phased out, but most notably is still used for WordPress' own JetPack plugin. The same general syntax can be used to deny access to xmlrpc.php. However, if using JetPack, then it's necessary to allow WordPress IP ranges found at https://jetpack.com/support/how-to-add-jetpack-ips-allowlist/

When not using a plugin like JetPack that requires whitelisting, add a new web.config section like the example below

  <location path="xmlrpc.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

Because the JetPack allow list includes IP ranges, a "subnetMask" needs to included along with the ipAddress. To obtain the subnet mask from a CIDR like those provided by JetPack, a converter like https://www.ipaddressguide.com/cidr may be used.

Using 122.248.245.244/32 as an example, the syntax for adding the IP address and subnet mask is

<add ipAddress="122.248.245.244" subnetMask="255.255.255.255" allowed="true" />

Example of the full section with Jetpack allow list

  <location path="xmlrpc.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <!--Jetpack allow list-->
          <add ipAddress="122.248.245.244" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="54.217.201.243" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="54.232.116.4" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="192.0.80.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="192.0.96.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="192.0.112.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="195.234.108.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="192.0.64.0" subnetMask="255.255.192.0" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

Example WordPress web.config with Permalinks

Completed web.config with sections added to restrict access to wp-login.php, /wp-admin and xmlrpc.php. Requires updating the ipAddress for any site visitors that should have access to wp-login.php and /wp-admin.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

  <location path="wp-login.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <add ipAddress="xx.xx.xx.xx" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

  <location path="wp-admin">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <add ipAddress="xx.xx.xx.xx" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>
  
  <location path="xmlrpc.php">
    <system.webServer>
      <security>
        <ipSecurity allowUnlisted="false">
          <!--Jetpack allow list-->
          <add ipAddress="122.248.245.244" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="54.217.201.243" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="54.232.116.4" subnetMask="255.255.255.255" allowed="true" />
          <add ipAddress="192.0.80.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="192.0.96.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="192.0.112.0" subnetMask="255.255.240.0" allowed="true" />
          <add ipAddress="195.234.108.0" subnetMask="255.255.252.0" allowed="true" />
          <add ipAddress="192.0.64.0" subnetMask="255.255.192.0" allowed="true" />
        </ipSecurity>
      </security>
    </system.webServer>
  </location>

  <system.webServer>
    <rewrite>
      <rules>
        <rule name="WordPress Rule" stopProcessing="true">
          <match url=".*" />
            <conditions>
              <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
              <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            </conditions>
          <action type="Rewrite" url="index.php" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

How to truncate your DNN event log table

Fri, 15 Feb 2019 23:13:52 GMT

**Highly recommended you back up database before making any changes**

DotNetNuke has a tendency to fill up your database with eventlogs. The following SQL query will clear those logs and usually clear up a lot of space.

First you'll need to connect to your database through SMSS: https://support.winhost.com/kb/a1033/how-to-connect-to-a-sql-server-using-sql-server-management-studio.aspx

Once you connected you'll want to click the plus sign to expand the database then click the plus sign next to "Databases". Then right click on the database and click "New Query".

Then copy and paste the following query:

IF EXISTS (SELECT * FROM sys.sysobjects WHERE id = object_id(N'dbo.[sys_currentDNNVersion]') AND Type = N'FN')
	DROP FUNCTION dbo.[sys_currentDNNVersion]
GO
-- --------- create tooling: --------- 

CREATE FUNCTION dbo.[sys_currentDNNVersion]()
	RETURNS Int
AS	
BEGIN
	DECLARE @Vers Int;
	SELECT Top(1) @Vers = Major * 10000 + Minor * 100 + Build FROM dbo.[Version] ORDER BY CreatedDate DESC;
	RETURN @Vers;
END
GO

IF dbo.[sys_currentDNNVersion]() >= 70400 BEGIN
	-- Drop Foreign Key Constraints:
	DECLARE @fkName nVarChar(100) = Null;
	SELECT @fkName = name FROM sys.foreign_keys 
	 WHERE parent_object_id = OBJECT_ID(N'dbo.[ExceptionEvents]')
	   AND Object_id IN (SELECT constraint_object_id  
	                      FROM  sys.foreign_key_columns F 
						  JOIN  sys.columns C ON F.parent_object_id = C.object_id AND F.parent_column_id = C.column_ID 
						  WHERE C.Name = N'LogEventID');
	IF Not @fkName Is Null
		Exec(N'ALTER TABLE dbo.[ExceptionEvents] DROP CONSTRAINT [' + @fkName +'];');

	SET @fkName = Null;
	SELECT @fkName = name FROM sys.foreign_keys 
	 WHERE parent_object_id = OBJECT_ID(N'dbo.[EventLog]')
	   AND Object_id IN (SELECT constraint_object_id  
	                      FROM  sys.foreign_key_columns F 
						  JOIN  sys.columns C ON F.parent_object_id = C.object_id AND F.parent_column_id = C.column_ID 
						  WHERE C.Name = N'ExceptionHash');
	IF Not @fkName Is Null
		Exec(N'ALTER TABLE dbo.[EventLog] DROP CONSTRAINT [' + @fkName +']')
END
GO

-- Truncate tables:
IF dbo.[sys_currentDNNVersion]() >= 70400 BEGIN
	TRUNCATE TABLE dbo.[Exceptions]
	TRUNCATE TABLE dbo.[ExceptionEvents]
	TRUNCATE TABLE dbo.[EventLog]
END ELSE
	TRUNCATE TABLE dbo.[EventLog]
GO

IF dbo.[sys_currentDNNVersion]() >= 70400 BEGIN
	-- Recreate Foreign Key Constraints (using common naming):
	ALTER TABLE dbo.[ExceptionEvents] 
	  WITH CHECK ADD CONSTRAINT [FK_ExceptionEvents_EventLog] 
		FOREIGN KEY([LogEventID])
		REFERENCES dbo.[EventLog] ([LogEventID])
	  ON DELETE NO ACTION;
	  
	ALTER TABLE dbo.[EventLog] 
	  WITH CHECK ADD CONSTRAINT [FK_EventLog_Exceptions] 
		FOREIGN KEY([ExceptionHash])
		REFERENCES dbo.[Exceptions] ([ExceptionHash])
	  ON DELETE CASCADE;
END
GO

DROP FUNCTION dbo.[sys_currentDNNVersion]
GO

Once you have inserted the script, click "Execute" or hit F5 on your keyboard. It will run and you should receive a message that it was successful.

*Note if you have a different prefix than the standard dbo. you will need to find and replace dbo. in the script with the prefix for your tables.

How to redirect non www to www

Thu, 07 Feb 2019 22:19:43 GMT

Below is the code you need to enter in to your web.config file in order to redirect a domain to a sub-domain or vice versa.

WWW to non WWW:

<rewrite>
  <rules>
    <rule name="Remove WWW prefix" stopProcessing="true">
      <match url="(.*)" ignoreCase="true" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="^www\.yourdomain\.com$" />
      </conditions>
      <action type="Redirect" url="http://yourdomain.com/{R:1}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

*You will also need to change "yourdomain" to your actual domain on Lines 6 and 8.

Non WWW to WWW:

<rewrite>
  <rules>
    <rule name="Add WWW prefix" stopProcessing="true">
      <match url="(.*)" ignoreCase="true" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="^yourdomain\.com$" />
      </conditions>
      <action type="Redirect" url="http://www.yourdomain.com/{R:0}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

*You will need to change "yourdomain" to your actual domain on Line 6 and 8.

Subdirectory and subdomain pointers with URL rewrite

Wed, 01 Aug 2018 16:33:08 GMT

To host multiple sites within one site hosting account, and barring conflicting rewrite rules, routing or a site built on the ASP.NET Core Framework, URL rewrite may be used to redirect domains and subdomains to subdirectories on an existing site. Syntax examples can be found below for each type of redirection. The rule(s) would be added to the web.config file in the document root of the site. For Core, see the last section.

Adding a Domain Pointer

Winhost Control Panel > Sites > the domain name > Domain Pointer

Redirecting a domain to a subdirectory

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <rewrite>
   <rules>
    <rule name="domain.com" stopProcessing="true">
     <match url=".*" />
     <conditions>
      <add input="{HTTP_HOST}" pattern="^(www.)?domain.com" />
      <add input="{PATH_INFO}" pattern="^/subdirectory/" negate="true" />
     </conditions>
     <action type="Rewrite" url="\subdirectory\{R:0}" />
    </rule>
   </rules>
  </rewrite>
 </system.webServer>
</configuration>

In the above syntax example, "domain.com" on lines 6 and 9 should be replaced by the domain pointer and "subdirectory" on lines 10 and 12 should be replaced by the subdirectory where the files have been uploaded.

Adding a Subdomain

Winhost Control Panel > Sites > the domain name > Subdomain Manager

Redirecting a subdomain to a subdirectory

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <rewrite>
   <rules>
    <rule name="subdomain.domain.com" stopProcessing="true">
     <match url=".*" />
     <conditions>
      <add input="{HTTP_HOST}" pattern="^subdomain.domain.com$" />
      <add input="{PATH_INFO}" pattern="^/subdirectory/" negate="true" />
     </conditions>
     <action type="Rewrite" url="\subdirectory\{R:0}" />
    </rule>
   </rules>
  </rewrite>
 </system.webServer>
</configuration>

In the above syntax example, "subdomain.domain.com" on lines 6 and 9 should be replaced by the applicable subdomain and "subdirectory" on lines 10 and 12 should be replaced by the subdirectory where the files have been uploaded.

If after adding either rule the subdirectory is being appended to the URL, you'll want to verify line 10 in the above syntax has been added to remove it.

ASP.NET Inheritance

Note that if the subdirectory is set as an application starting point and there is an ASP.NET application in the parent directory, the child application will inherit settings from the parent application. For more information about disabling inheritance, see: https://stackoverflow.com/a/5968658

ASP.NET Core

Microsoft.AspNetCore.Rewrite is middleware with support for URL rewrite rules. For an overview on using the middleware, see the microsoft.com article URL Rewriting Middleware in ASP.NET Core. To use URL rewrite rules like those above through a referenced xml file, see the IIS URL Rewrite Module rules section.

node.js

Sat, 28 Jul 2018 15:32:35 GMT

On IIS, node.js is handled by the iisnode module. To run a node.js script, a handler mapping will first have to be added to the site's web.config to process the .js script, or all .js scripts, using the iisnode module. To run a custom node.js version, see the Custom node.js Version section.

Handler Mapping

To have all .js scripts handled by the iisnode module, add module "iisnode" to the handlers element of the web.config as in the syntax example below:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="iisnode" path="*.js" verb="*" modules="iisnode" />
    </handlers>
  </system.webServer>
</configuration>

If there are other files using the .js extension in the application, necessitating targeting specific files, update the handler path. For example, if the below ztest.js file were in the document root, the syntax would be:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="ztest" path="ztest.js" verb="*" modules="iisnode" />
    </handlers>
  </system.webServer>
</configuration>

Note when adding a handler for more than one file, each will require a unique name.

Testing node.js

To test node.js, the syntax below may be copied, making sure to use the file extension .js. Or download and extract ztest.js; then upload the file to the site and visit the page in a browser.

  var http = require('http');

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello world');
}).listen(process.env.PORT);

Custom node.js Version

Visit https://nodejs.org/en/download/releases/ and click the version number link under "Node.js" for the package download.

Then under "Binary Downloads" select the win x64 zip.

After downloading the zip, extract node.exe.

Then upload the extracted node.exe to an /App_Data directory on the site.

iisnode.yml

Create a new text file and name it "iisnode.yml". In that file add the following line:

nodeProcessCommandLine: "server path to file"

For the example above where node.exe was placed into /App_Data the syntax would be:

nodeProcessCommandLine: "E:\web\FTPusername\app_data\node.exe"

To test the update, create a separate .js file and add the following syntax to display the version of node.js the site is using:

var http = require('http');
http.createServer(function(req,res) {
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end('Node.js ' + process.version);
}).listen(process.env.PORT);

To test the update, create a separate .js file and add the following syntax to display the version of node.js the site is using:

Or download node.zip for a sample iisnode.yml and test script. Edit iisnode.yml and replace "FTPusername" with the FTP username for the site, then upload iisnode.yml (and the test script) to the document root.

And view the ztest.js in a browser to show the version.

Checking / Updating Outbound TLS 1.2 Support

Tue, 26 Jun 2018 19:21:57 GMT

Due to changes in security, it may be necessary to update or migrate a site to use TLS 1.2 for outbound connections. Most notably for a payment gateway. For general information, including testing, find the applicable scripting section below (ASP.NET, Classic ASP, or PHP). If it's necessary to migrate the site to a newer version of Windows or you require assistance with reviewing TLS 1.2 support, please open a ticket with the Support Department.

Windows Server Version

The version of Windows Server, necessary to check for ASP.NET and Classic ASP support, can be ascertained by reviewing the Server Name in the Winhost Control Panel, then matching it against the key below. The Web Server field in the Winhost Control Panel will show whether the site is on Windows Server 2008, 2012, or 2016, but the key below will specify whether it's on 2008 R2 or 2012 R2.

Winhost Control Panel > Sites > the domain name > Site info pane

Server key

Windows Version	Server Name
Windows 2008	w01 - w04
Windows 2008 R2	w05 - w08
Windows 2012	w11 - w15
Windows 2012 R2	w00, w16 - w25
Windows 2016	w26 - w34, w101 - w102
Windows 2019	w35 - w36, w100, w103, w01h
Windows 2022	w37 - w42, w104

ASP.NET

The requirements for TLS 1.2 support when using ASP.NET are Windows Server 2012 R2 or 2016, ASP.NET Framework 4.5 or higher and bootstrapping code to set the TLS version.

If a site is hosted on an older version of Windows, for migration assistance to Windows 2012 R2 or Windows 2016, please open a ticket with Support.

If a site is using an ASP.NET Framework older than 4.5 it will need to be updated. Note this is a project update rather than the ASP.NET Framework version set in the Winhost Control Panel.

To set the TLS version for an outbound connection, add the following to the script making the connection or the global.asax:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

More information regarding the last update can be found after the link https://stackoverflow.com/q/28286086. Also note that the bootstrapping code would have to be updated if TLS requirements were to change in the future.

Classic ASP

TLS 1.2 support through Classic ASP the site should be on a Windows 2012 R2 or Windows 2016 server.

To test TLS 1.2, the script in zssl.zip may be used: zssl.zip

For migration assistance to Windows 2012 R2 or Windows 2016, please open a ticket with Support.

PHP / cURL

For PHP, TLS 1.2 support is dependent on the version of PHP set for the site. Which should be set to 5.5 or newer in the Winhost Control Panel.

Winhost Control Panel > Sites > the domain name > PHP

To test TLS 1.2, the script in zcurl.zip may be used: zcurl.zip

Installed .NET Core Frameworks

Fri, 12 Jan 2018 18:05:34 GMT

.NET Core versions supporting framework-dependent (FDD) deployment are listed below. Versions are installed on IIS 8 and IIS 10 web servers.

Core versions not listed below can be deployed self-contained until the framework is installed.

If you aren't on an IIS 8 server that supports FDD .NET Core we can migrate your site to a newer server that does support it. Just open up a support ticket and let us know.

.NET Core versions currently supported:

1.0.x (End of life)
1.1.x (End of life)
2.1.x (End of life)
2.2.x (End of life)
3.0.x (End of Life)
3.1.x (Maintenance)
5.x (End of life)
6.x
7.x
8.x
9.x
10.x