Cadzow 2000 Weblink/Content Manager Setup
Cadzow 2000 Weblink is a series of ASP.NET (.aspx) scripts which interact with the main Cadzow 2000 store. Thus the web-server side of Cadzow 2000 and the client-side application share the same data source, whether it be an Access .MDB (Jet) or SQL Server database.
The Cadzow 2000 Weblink system therefore consists of:
- Various resource files (.dll, .aspx, ,html, .css, graphic files etc) which are replaced whenever an update is released;
- A number of site-specific configuration files; and
- The Cadzow 2000 data file.
Installing Cadzow 2000 Weblink
- CHECK YOUR SYSTEM: Check the system requirements.
- CREATE THE APPLICATION FOLDER: A path under the webroot can be a physical folder or a pointer to another location.
If you intend to store the Cadzow 2000 Weblink files on the web server, simply create a folder using Windows Explorer under your webroot where appropriate. If you are storing the files on another server, use Internet Services Manager to create a virtual directory.
The folder/virtual directory name becomes the default address for the entire site, so it should be short and meaningful. For example, http://www.site.com/knowledgebase/.
Then, turn the folder into an Application using the Properties of the folder and choosing Create under Application Settings. (Set Application Protection as required.)
- SET PERMISSIONS: If using the virtual directory wizard, the virtual directory only requires Read and Run Scripts permissions. Execute, Write and Browse should be turned off. If using the properties of the folder once created, the permissions required are Read and Execute Permissions: Scripts Only.
Other file system permissions required are:
- If the database is a Microsoft Access .MDB file, the ASPNET account (or the account being impersonated) needs full control (read/create/write/delete) of the temporary files folder under C:\Documents and Settings\<ServerName>\ASPNET\Local Settings\TEMP. (See http://support.microsoft.com/kb/827190 for further information.)
- The IIS anonymous user and the ASPNET account require full control (read/create/write/delete) access to the “system” TEMP directory (usually %SystemRoot%\TEMP; for example, C:\WINDOWS\TEMP).
- INSTALL FILES: The Cadzow 2000 Weblink files are contained in a self-extracting package. The download location is:
The default extract location is c:\Inetpub\wwwroot\Cadzow. The path may be changed to suit the location of the instance of Cadzow 2000 Weblink on your web server. In the default instance, the folder used for external access to the system is “Cadzow”. If your system is configured as, say “Knowledgebase”, then the location to extract the files to is c:\Inetpub\wwwroot\Knowledgebase. Alternatively, if your configuration is more complex, with redirected virtual folders etc, simply extract the files into the appropriate location.
- SET THE DEFAULT DOCUMENT: By default, the Cadzow 2000 Weblink path to the home page is of the form:http://www.site.com/folder/details.aspx?id=100
where “100” is the id of the “home page” article. However, the system has a provision for a default article where the article is missing or invalid, in which case the path to the home page could be:http://www.site.com/folder/details.aspx
However, if you set “details.aspx” as one of the default documents, then the default home page simply becomeshttp://www.site.com/folder/
Each site has a number of unique settings and these are stored in web.config, which is usually located in the same folder as the main Cadzow 2000 Weblink files (although in some circumstances there may be multiple web.config files). The settings which require end-user modification are between <appSettings> and </appSettings>:
- Data Source: The location and login details for the database, relative to the webserver.
SQL Server (Named Pipes, Integrated Authentication) example:
<add key="connString" value="Provider=SQLOLEDB; Data Source=DBServer; Initial Catalog=CadzowDB; Integrated Security=SSPI;" />
SQL Server (TCP/IP, Integrated Authentication) example:
<add key="connString" value="Provider=SQLOLEDB; Data Source=DBServer,1433; Network Library=dbmssocn; Initial Catalog=CadzowDB; Integrated Security=SSPI;" />
SQL Server (TCP/IP, SQL Server Authentication) example:
<add key="connString" value="Provider=SQLOLEDB; Data Source=DBServer,1433; Network Library=dbmssocn; Initial Catalog=CadzowDB; User Id=User; Password=pass;" />
(Note SQL Server must be configured to use both Windows and SQL Server authentication if using this method.)
Microsoft Access example:
<add key="connString" value "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=c:\cadzow\success7\clients\smith\smith7.mdb" />
- Graphics Files: Cadzow 2000 Content Manager and Weblink support a short-hand syntax for embedding images in webpages, and this setting tells Weblink where the graphics are stored. This could be another server or the same server. This setting needs to be relative to the client's browser.
<add key="CustomLocation" value="http://www.anothersite.com.au/images/" />
The current webserver:
<add key="CustomLocation" value="" />
A different folder on the current webserver:
<add key="CustomLocation" value="../../Images/" />
A UNC path:
<add key="CustomLocation" value="\\webserver01\webroot\images\" />
NB. A UNC path would only be suitable in an intranet environment.
- SMTP Host: Mail host used to send emails, for example:
<add key="SmtpServer" value="mail.host.com.au" />
If you want to use secured SMTP, use the following additional commands:
<add key="UseSecured" value="-1"/>
<add key="UseSecuredUserName" value="username"/>
<add key="UseSecuredPassword" value="password"/>
<add key="UseSecuredPort" value="port"/>
- Icon File: The location of an icon file to be used by the browser.
<add key="ShortcutIcon" value="http://www.cadzow.com.au/favicon.ico" />
(Note most browsers will use a file called favicon.ico if it exists in the current directory. This setting can be used to specify an alternate file on another website.)
Also, the Apple iPhone will use a file called apple-touch-icon.png if it exists in the root. It must be 45×45 pixels.
Permissions and Security
In many circumstances the server hosting the database (whether .MDB or SQL Server) is different from the web server, although it is not always the case. Thus the web server needs to access the data on another server or vice-versa.
Database is stored locally on the webserver
In this configuration, the .MDB file is stored on the physical web server, either under the webroot (for example, .\DATA) or outside the webroot (for example, C:\DATA). If the web server is granting access to anonymous web clients, then the database directory needs read/write permissions for the anonymous user account (usually IUSR_<webservername>). If integrated Windows security is used, relevant users would be granted permissions using NTFS ACLs.
This directory would then be shared to be accessible to the Cadzow 2000 users on the LAN, with appropriate permissions granted, and the Cadzow 2000 startup file (GO.BAT) would specify this location.
This technique has the advantage that it requires a bit less configuration in terms of permissions and also means that the web server application can run completely by itself. If the web server is compromised, in principle the attacker does not have a pathway to other servers (depending on the nature of the compromise).
Database is stored on another server
In this configuration, the .MDB is stored on another server, and the web server needs permissions on that server to gain access. If the web server is granting permissions to anonymous web clients (via IUSR_<webservername>), the server containing the database also needs a user account called IUSR_<webservername> with the same password, or IIS needs to use a domain account as the anonymous account.
The advantage here is that the load of accessing the database is performed by a dedicated file server rather than the web server, although conversely the web server needs to pull more data from the network to serve requests for content. However, it also means that if the web server is compromised it may give an attacker an immediate pathway to files on another server.
Ultimately the choice about which method to use will depend on what is convenient for your location, and there may be network traffic considerations also, eg. if you expect to have a small number of LAN users and many anonymous web users, the database is best located locally to the web server. If the other way around, the database is best on a high-throughput file server.
Database is stored on SQL Server
If using SQL Server, the web server can connect via SQL Authentication, whereby the username and password are included in the connection string (note there are security considerations with this method), or via Integrated Authentication, whereby the “anonymous” user is configured to have access to the database on the SQL Server server. Because each computer gets its own “IUSR_<webservername>” account, the latter method usually means creating a new local account on the SQL Server server with the same name and password so the credentials can be passed straight through from the webserver to the database. This user is then given appropriate permissions to the database. This method can be fiddly, but has the advantage that credentials are not stored in plain text in the web server configuration files.
Updates are simply new packages. Follow “4. Install Files” above.