Settings and Tuning
Learn about settings and tunings for Aurea CRM Web.
Below are some of the required settings:
IIS Application Settings
Content Expiration
To avoid that clients have to download the same static files every time they navigate to Aurea CRM web it is strongly recommended to enable a content expiration on all static content.
Setting the content expiration allows web browsers to cache the content for the specified time period before requesting it again from the server.
If you have installed Aurea CRM web using the setup process, the content expiration is set to one day for the following directories: \images, \scripts, and \styles.
Use IIS Manager to change the content expiration of files or directories. Select the Aurea CRM web directory, open the Properties dialog box, and set the content expiration in the HTTP Respones Headers tab (Set Common Headers action).
Application Protection / Application Pool
If you have installed Aurea CRM web using the setup process, the following web application structure is created in IIS: A new application pool is created by the setup process. By default, the application pool is named "update_CRMweb". You can specify another name during the setup process, see IIS Virtual Directory and IIS Application Pool.
If you want to run more than one Aurea CRM web application on one web server, you have to
configure them to use different application pools. If you want to have multiple web
applications using the same physical folder, you have to use environment variables
%APPLICATIONPOOL%
and %PID%
(= Process ID) in all paths
specified in settings.xml, to ensure that web applications won't block
each other by locking files.
Session Timeout
After a certain period of inactivity, a user loses his session and must then log on again. To ensure that the user does not lose his session, you have to increase the default value for the session timeout. Adjust these settings using IIS Manager.
Aurea CRM web Settings
Jobs.PollingInterval Configuration Parameter
The Jobs.PollingInterval
Web Configuration parameter defines how often
Aurea CRM web clients contact the server for new data (e.g. Reminders or To-Dos). By default
this setting can be changed by all users in Aurea CRM web (User
Configuration > Handling > Check for
new records every min.).
The default value of Jobs.PollingInterval
checks for new records every 30
minutes. If this value is reduced for a significant number of users, performance decreases
as database access rises. It is recommended to set a reasonable interval and to prevent
users from changing it (by removing the corresponding option from the mask
(UserConfig
layout), see Configuration Layouts in the Aurea CRM
web Administrator Guide.
Aurea CRM win Settings
Rights Settings
When a user logs on, a new Internet Interest record is created. Therefore, each Aurea CRM user must have "New", "Update" and "Read" rights for the Internet Interest (II) table, otherwise the login fails.
Every Aurea CRM rep is assigned to an Internet Interest at login, therefore, this table must be fully accessible (without conditions). Every rep must have "Read" and "Write" rights for the II table. The same applies to the I9 table.
Number of Visible Reps
If a user has access to too many reps (approximately 300 or more), the rep picker in Aurea CRM web can become rather slow when opened for the first time in a session (this is a known issue).
You can limit the number of reps for a user. It is suggested that users only have access to the reps they really need. This can be accomplished using the Aurea CRM win Rights module.
Configuration Table (MC) Entries
The following entries of the Configuration table (MC) only work as a global setting in Aurea CRM web, but not when defined for a user or group:
- General Settings > Start of Fiscal Year
- Country Table > Disconnect Field from Country Table
- General Settings > RepOff
Configuring Single Sign-On
Aurea CRM web
Aurea CRM web supports single sign-on with the Active Directory. You need to enable single sign-on per user in the Login (US) info area (s. below).
To enable single sign-on for Aurea CRM web:
- Configure single sign-on in the Login info area (US): For each
user enter the appropriate values for Domain and Windows
User Name, see Configuring Logins in the CRM.core
Administrator Guide.Note: You can access the Login info area from Aurea CRM web (Administration > Logins) or from the Aurea CRM win Rights module (Rep > Configure Login).
- In IIS Manager:
- Select the Aurea CRM web site.
- Select Authentication.
- Set "Anonymous Authentication" to "Disabled" and "Windows Authentication" to "Enabled".
On Windows 2008 Server you need to deactivate the advanced security settings for single sign-on to Aurea CRM web to work.
For information on how to configure a browser for single sign-on, see the article “How to Configure browsers for single sign-on” at https://support.aurea.com.
CRM.bulkloader
For CRM.bulkloader to work with single sign-on, change the configuration file ..\crm.services\web.config as follows:
- Change the value of the
clientCredentialType
attribute fromNone
toWindows
.
CRM.designer
For information on how to configure single sign-on for CRM.designer, see the article “How to Enable SSO in designer” at https://support.aurea.com.
Start Page Redirect
When using both Aurea CRM web and CRM.mobile, you can define rules for automatically redirecting your users to the appropriate application depending on the device they currently use, i.e. automatically start CRM.mobile if they access Aurea CRM web's URL on a smartphone. For details, see https://support.aurea.com/wiki/index.php?title=Start_Page_Redirect.
The conditions for redirecting to CRM.mobile are defined in the startPageRedirect.xml file (located at .. \system\settings). startPageRedirect.xml is included in Aurea CRM web's settings.xml.
The redirect logic only works if the root of the Aurea CRM website (i.e.
default.aspx) is accessed; if the user directly accesses e.g.
http://<server name>/updateCRM_web/start.aspx
, Aurea CRM web is
started regardless of the used device.
Security Settings
Black/White List for External Pages
To prevent phishing attacks when opening an external page, you can define a black/white
list ensuring that a RedirectPage
or URL
action cannot be
redirected to a harmful site.
<update.web>
section of the settings.xml
file, define a <NavigationSecurity>
element containing black/white
listed
pages.<NavigationSecurity unguardedNavigation="Warning">
<RegexDictionaryEntry>
<Key>www.my-good-website.com</Key>
<Value>Allow</Value>
</RegexDictionaryEntry>
<RegexDictionaryEntry>
<Key>www.areyousure.org</Key>
<Value>Warning</Value>
</RegexDictionaryEntry>
<RegexDictionaryEntry>
<Key>www.buy-me.com</Key>
<Value>Deny</Value>
</RegexDictionaryEntry>
</NavigationSecurity>
Available values:
- Allow: The page is opened (in a new tab).
- Warning: A prompt asks the user if the page should be opened.
- Deny: A message is displayed informing the user that the page can not be opened.
Use the unguardedNavigation
attribute to define the default behavior for
pages for which no entry exists.
Due to its security handling, Google Chrome displays pages flagged with 'Allow'
and pages flagged with 'Warning' differently: If you have defined two URL actions both
with target e.g. set to _blank
, the URL flagged with 'Allow' is opened in
a new window, the URL flagged with 'Warning' is opened in a new tab.
Process End on Application_End
You can define conditions for ending (and restarting) the IIS worker process, e.g. changed file in the ..\bin directory.
In the settings.xml in the <update.web>
section
define a <TerminateOnApplicationEnd/>
element containing the exit
reasons.
<TerminateOnApplicationEnd>
<ExitOn>
<ExitReason>BinDirChangeOrDirectoryRename</ExitReason>
<ExitReason>BrowsersDirChangeOrDirectoryRename</ExitReason>
<ExitReason>ChangeInGlobalAsax</ExitReason>
<ExitReason>ChangeInSecurityPolicyFile</ExitReason>
<ExitReason>CodeDirChangeOrDirectoryRename</ExitReason>
<ExitReason>ConfigurationChange</ExitReason>
<ExitReason>HttpRuntimeClose</ExitReason>
<ExitReason>InitializationError</ExitReason>
<ExitReason>MaxRecompilationsReached</ExitReason>
<ExitReason>None</ExitReason>
<ExitReason>PhysicalApplicationPathChanged</ExitReason>
<ExitReason>ResourcesDirChangeOrDirectoryRename</ExitReason>
<ExitReason>UnloadAppDomainCalled</ExitReason>
<!-- No exit for the following-->
<!--ExitReason>BuildManagerChange</ExitReason-->
<!--ExitReason>HostingEnvironment</ExitReason-->
<!--ExitReason>IdleTimeout</ExitReason-->
</ExitOn>
</TerminateOnApplicationEnd>
For details on all available exit reasons, >> http://msdn.microsoft.com/en-us/library/system.web.applicationshutdownreason.aspx.
Including stack trace reports in Server Channels Exception messages
By default CRM.Web does not include stack trace information along with exception messages
generated by a CRM application, in the reports sent to the clients. To enable stack trace
reports to be included along with exception messages, you have to set
EnableStackTrace
option to true
in the
settings.xml file. The following sample shows the
ExceptionSettings
element with the EnableStackTrace
option
set to true
.
<update.lib>
<ExceptionSettings>
<EnableStackTrace>TRUE</EnableStackTrace>
</ExceptionSettings>
</update.lib>
Disabling HSTS (HTTP Strict Transport Security) Policy
HTTP Strict Transport Security (HSTS), a web security policy mechanism is enabled by default in Aurea CRM. HSTS protects Aurea CRM against protocol downgrade attacks and cookie hijacking. It is an IETF standards track protocol and is specified in RFC 6797. Once a client establishes a secure (HTTPS) connection with CRM.Web, the HSTS (HTTP Strict Transport Security) policy is enforced to ensure that the client continues to use SSL or TLS connections and does not switch to a non-secure connection.
If you do not want to enforce HSTS, you can disable it by setting the
DisableHSTS
parameter to true
in the
settings.xml
file. See the sample code below:
<update.lib>
<WebSecuritySettings>
<DisableHSTS>TRUE</DisableHSTS>
</WebSecuritySettings>
</update.lib>
Using HTTPS to Connect to Aurea CRM.Web Limits the Scope of the Cookies to Secure Channels
From v10.1.0 release of Aurea CRM.Web, when a client uses the https channel then Aurea CRM limits the scope of the cookie to the secure channel, HTTPS (HTTP over Transport Layer Security (TLS) [RFC2818]) in this case. Later, if the same client tries to use HTTP to connect to Aurea CRM.Web, the connection attempt fails until the client clears the cookies. This is because once the scope of an established cookie is restricted to a secure channel, then the cookie is not transmitted over an unsecured channel like HTTP.
Enabling Cross Site Request Forgery (CSRF) Protection
Aurea CRM.Web provides the element <EnableCsrfProtection/>
in the
settings.xml file that can be set to true to enable CSRF protection.
Aurea CRM.Web uses the Cookie-to-Header Token method to prevent cross site forgery
attacks. This method relies on the same origin policy, which ensures that JavaScript
within the same origin can read the cookie’s values.
This method uses a random header token that is generated by the server when a user logs in and is included by the client in all its request to the server for the duration of this session. JavaScript that belongs to the same origin on the client side can read this token value and include it in the custom header when it sends a transaction request. The assumption here is that the javascript running from a rogue file does not have the X-Csrf-Token header, because it cannot read the Csrf-token cookie, as it is not from the same origin. Consequently its transaction request is not honored by CRM.Web and the CSRF attack fails.
false
by default. All customer
side extension software (including client browsers) that send requests to CRM.Web must be
adapted to use the Cookie-to-Header Token method before enabling this option.- Cross-site request forgery for the Cookie-to-Header Token method
- Same-origin policy
HTTP Post Method for Data Manipulations
Aurea CRM enforces HTTP POST requests for all channel methods to prevent CRSF (Cross Site Request Forgery) attacks that exploit the HTTP GET method. All HTTP GET requests are by default converted to a HTTP POST request. This prevents malicious users from posting HTTP GET requests on channels that manipulate data.
The HTTP POST method is not enforced on the following channel methods:
TypesChannel.GetTypes
ApplicationChannel.GetStartupData
ApplicationChannel.GetLoginSettings
SettingsChannel.Find
ConfigurationChannel.GetTexts
AdministrationChannel.GetSystemInfo
DisableHttpMethodTypeProtection
option to false
for a
channel endpoint. <update.web.base> <ChannelEndpoint> <!-- If DisableHttpMethodTypeProtection is enabled all Channels start to serve for any Http Method type,even it is configured to serve Http POST only. This option is not recommended for production usage. --> <DisableHttpMethodTypeProtection> false </DisableHttpMethodTypeProtection> </ChannelEndpoint> </update.web.base>
Enabling X-Powered-By ASP.Net and Other version headers in HTTP response
The following headers are disabled by default in a HTTP response:
- Server: Details of the web server hosting Aurea CRM. For example, “Microsoft-IIS/7.5”.
- X-Powered-By: One or more application frameworks being run by site hosting Aurea CRM. For example, “ASP.NET”, “PHP/5.2.17” and “UrlRewriter.NET 2.0.0”.
- X-AspNet-Version: Header from an ASP.NET. For example, “2.0.50727”, “4.0.30319” and “1.1.4322”.
To enable one or more of the above headers, you can add the application settings key DisableResponseHeaders in the Web.Config file. Add the response headers you want to specifically disable to the key value separated by a “;”. See the examples below:
To enable all three headers:
<add key="DisableResponseHeaders" value=""/>
To enable the Server header:
<add key="DisableResponseHeaders" value="X-AspNet-Version;X-Powered-By"/>
Displaying a Document's Path in System Information
As a security measure, by default, Aurea CRM.Web System Information page (
) does not display the path on the server where the uploaded documents are kept. See the screenshot below:To display the document path set the web configuration parameter
Security.HidePathInformation
to False
.
Enabling Protection from Session Hijacking
To prevent a user’s live session from being hijacked, you can ensure that all session requests are originating from the same IP address that the user logged in and the User-Agent String value remains the same during the session.
To enable this protection, set the <SessionHijackingProtection>
element
in the CRM.Web’s settings.xml file, as shown below:
<update.web>
<SessionHijackingProtection validateClientIpAddress="true" validateClientUserAgentString="true" />
</update.web>