Application ID
Though it requires precise configurations, it is possible to have more
than one website to run under the same application context. The login
control has a concept called Application ID, which will be appended to
each configuration entry key in the App.Config file.
An APPID is used in the following ways:
When the control is used, specify the APPID as an attribute
Ex:
<%@ Register
TagPrefix="login"
Namespace="eCart.CoreControls"
Assembly="CoreControls, Version=2.1.1.1, Culture=neutral, PublicKeyToken=c19615e04a86079f"
%>
<Login:Login id="Login1" APPID=”TestApp” runat="server"></Login:Login>
In this case, APPID will be TestApp
In such a case, all the configuration parameters keys in the App.Config
file should be appended with “TestApp”
For example:
<add key="TestAppLicFile
<add key="TestAppCfgDbType"
<add key="TestAppCfgDb"
Password Encryption
if the password that is stored in the member database is encrypted, then
the Encryption Key is stored as a DPAPI encrypted string in the configuration
file.
Configuration Database Connection String and Member Password encryption
key are always encrypted using DPAPI encryption.
The web developer may use the Rijdael encryption function from the security
component provided with this package to encrypt and decrypt a string.
DPAPI encryption should not be used for this purpose, since there is no
way to decrypt the encrypted string on a different machine.
Application and Session Variables
The following critical configuration items are stored as application
variables to improve system performance and resource management, so that
configuration files are not referenced each time a component requires
them.
AppId + "CFGDBTYPE"
AppId + "CFGDB"
AppId + "LICFILE"
For example, if no application id was specified, application variable
LICFILE will return the license file path that has been configured.
Since the system first checks the application variable before it reads
a configuration file, any change in the configuration file requires an
application reset. However, developer may use the /sys/resetconfig.aspx
utility to reset the application variable during development.
APPID is stored in a session variable and not an application variable.
This enables multiple applications co-exists on the same application contexts
at the same time. If the APPID session variable is reset programatically,
the following takes precedense.
If the web developer requires that the same web page is access through
multiple domains, multiple logical application contexts may be created
by conditionally setting the APPID session key in the global.asa file.
For example, the following code in global.asa will create mutually exclusive
logical contexts in the same web application, when accessed through different
domain names.
|
public void Session_Start(object sender, EventArgs e)
{
HttpContext Ctx = HttpContext.Current;
Uri uri = Ctx.Request.Url;
String url = uri.Authority;
switch (url.Trim()) {
case "localhost":
if ( true)
{
Session ["APPID"] = "LOCAL";
}
break;
case "priusant.com":
case "www.priusant.com":
if ( true)
{
Session ["APPID"] = "REMOTE";
}
break;
default:
break;
}
} |
|
|
|
|
If APPID is defined by setting the property of the LoginControl, that
values is used. However, it does not reset the session variable APPID.
By this feature, it is possible to switch logical contexts for a page
without affecting the rest of the pages.
|