wcBASIC WCX applications is an important part of the WINSERVER system and framework.
WCX is an embedded server side compiled computer program use to create rich applications. Wildcat! comes with stock WCX applications and libraries which is distributed in the WILDCAT.WCL image library. By default, WCX programs with a HTML- prefix are meant to be used with the web server and when you have a URL with a WCX, it must contain the HTML- prefix.
However, this is all optional and Wildcat! offers security options to control who has access to WCX applications with or without HTML- prefixes.
The key point to remember is that WEB based applications have a HTML- prefix in its file name and text based applications do not. This is very important when it comes the security system.
This documents will summarize how WCX security is done for both text based and web based applications:
This section discussese ANSI/Telnet (Text Mode) WCX applications to help provide a focus in understanding the security differences between WCX applications for Text mode va Web Mode. We will show how it is traditionally done for text based applications and how it differs with web based applications.
Traditionally, Wildcat! offers a console/text interface and menu system. Console/text means the user has connection by dialing up and connection via modem, using telnet to connect via the internet or wcLocal which is use in a local network.
The text displays are created by the system operator (sysop) with the WCDRAW.EXE utility, and the WCMENU.EXE utility is used to create text based menus and menu items. Each menu item has a WCX assigned to it to perform its specific task.
When you create a WCX, you can add it to the menu and assign the access security groups allowed to see the menu item and thus run the WCX.
For example, using wcMENU, when you edit the stock message menu item "Check Personal Mail" option, it is setup to run the wcBASIC program "Check for mail.wcx":
NOTE: It is important to note HTML- applications will not be shown in the Program pull down selection field.
When you click the ACCESS button, the access securities are shown allowing you to select which access securities are allowed to run this particular wcx:
You can also view all the accessible WCX application on a per access basis by using WCCONFIG.EXE.
WCCONFIG | ACCESS PROFILES | WCX Code Access.
This viewl allow you to see all the WCX applications accessible by one specific access group, i.e. Registered users.
NOTE: It is important to note the WCX Code Access section will not display applications with an HTML- prefix in the selection list. Only WCX applications without a HTML- prefix will be shown.
When the user connects and logs in text mode (via modem, telnet or wcLocal), the Wildcat! built-in menu interface controller will control the menu displays and show only the accessible menu items based on the user's access to the WCX applications. It is impossible for the any user to run a WCX the user doe not specific access to.
TIP: Wildcat! text displays uses built-in menu\*.bbs menu displays. When a MENU\*.BBS file is available for a specific security, this is displayed instead of the two column menus. If you want to double check to see if the WCX security is proper for the user, you can remove, delete the MENU\*.BBS files and the menu controllers will show the colorized two column menu should only the menu items based on the user security.
For text based WCX applications, the WCX itself need not to have any security access control requirements since the menu controllers will control the access to the WCX applications.
However, this is not the case with WCWEB and this is the priimary reason why text based applications are separated from the web based applications by requiring the HTML- prefix for applications designed to run under the WEB.
Text based versus WEB based wcx applications are distinquished and separated by using the HTML- prefix.
When a WCX is created to run via the WCWEB, it is typically named with a HTML- prefix. For example, the URL
/code/html-message.wcx
can be used will start the wcWEB message client.
It it important to note, the WcWeb Server WILL NOT check the access for any WCX url that contains a HTML- prefix. So it is important the HTML- WCX application must add its own security access check. When the WCX does not have a HTML- prefix and you want to control access, this is where the WCXACCESS.LST access filter files are used and it is discussed in the Using WCXACCESS-CUSTOM.LST section.
But what if you wanted to use the Access Profiles for your own custom web based HTML- WCX applications in the same way the access profiles are used to control text based WCX applications?
Since the web server will not check the access for WCX applications having a HTML- prefix, there are two ways to control access to a HTML- application usnig a little bit of custom coding:
Using a non HTML- program stub:
As indicated earlier in the document, WCMENU and WCCONFIG will not show WCX applications that contain a HTML- prefix. Hence it is not manually possible to use these tools to assign an an access security directly to the HTML- WCX application.
However, you can create a stub application with the the HTML- prefix and in this way, add a few lines of code to your HTML application to have it check for security.
Example:
You have a custom HTML-MyProgram.WCX application and you want to assign specific security which is allowed access. This allows you to offer the SYSOP the flexibility to define who has access.
Step #1, Create a MyProgram.WCC file with a single comment line:
// THIS IS FOR ACCESS CHECKING ONLY
Step #2, Compile it to create the MyProgram.wcx file. Make sure the WCX file is placed in the main Wildcat! \WC root folder where the WCSERVER.EXE is located.
Step #3, Start the WCCONFIG Access Profiles manager and select the access securities you want to edit the WCX Code Access section. In the WCX Code Access section, you should see MyProgram listed. Toggle it to have the X tag and save your profiles.
Step #4, Edit your main HTML-MyProgram.WCC source code, and place the following at the top or in the appropriate place in your code. It should be the first thing that is done:
#include "clientlib.wch"
if not CheckWCXAccess("MyProgram") then
print "You do no have access to this module!<br>"
end
end if
Step #5, Compile it to create the Html-MyProgram.wcx file.
Step #6, Finally, test the security by running HTML WCX URL via wcWEB under various login accounts; ones with access and ones without.
As you can see, since you are passing the name of the WCX to the CheckWCXAccess() function, technically, you can any other existing WCX file name. It doesn't have to be specifically "MyProgram.wcx." In fact, for larger projects or 3rd party products where you have multiple HTML- programs, you can use the project or product name for the WCX instead, like "MyProductName.wcx" and all of your HTML- programs can reference this single WCX for controlling access.
Using the Client Access System:
Another way to control access and also make it part of the wcWeb Interface GOTO "navigator" top menu bar, is to use the Wildcat! Client Access security system. This is under the WCCONFIG | Access Profiles | Clients section.
The Wildcat! Client Access system was designed for WcWeb and WcNavigator user access to the stock clients and add-ons such as the wcCASINO add-on game clients. These stock clients include:
html-personal.wcx Personal Properties client
(Your Settings)
html-message.wcx
Mail client
html-chat.wcx Chat
client (wcJava Chat)
html-file.wcx File
client
html-who.wcx
Who's Online client
html-terminal.wcx Terminal client (starts Telnet user machine)
The wcWEB special URL is used to activate one of the HTML- wcx clients:
/client?XXXXXXX.wcn
For example, to start the mail client, the URL would be:
/client?message.wcn
The special url, /client?message.wcn, tells wcWEB to start the /CODE/HTML-message.wcx client for users logged via a web browser or for users logged in via WcNavigator to start the message.exe program installed on the user's machine.
WCWEB will not check the user access at this point because each client is expected to do its own security check.
All the stock wcWEB clients have specific access checking wcBASIC code to check the current user access to the Client application. Using the message client as an example:
#include "clientlib.wch"
if not CheckMailClientAccess() then
dim url as string = "wc:\http\template\NoClientAccess.htm"
dim arg as string = "client=message"
if not ProcessTemplate(url,arg) then
print "You do not have access to run this client."
end if
end
end if
To understand how this uses the Wildcat! Client Access system, we need to understand what CheckMailClientAccess() is doing. This is basically a helper function what basically calls:
CheckClientAccess("Message Client")
Hence, the CheckClientAccess() function takes a string "Message Client" and checks the access profile securities to see if the Message Client is toggled for the particular security:
So using the Client Access system, you can control what clients the user has access to.
You can add your own clients to this list to allow the sysop to control the security.
Example:
You have a custom HTML-MyProgram.WCX application and you want to assign specific client access security which is allowed access. This allows you to offer the SYSOP the flexibility to define who has access.
Step #1, Create a "Clients\MYProgram Client" folder.
Under the root \WCx folder, you have the stock Clients\ sub-folder. It will contain all the stock clients folder names. There will be others related to internal special wcNavigator clients.
Add your own folder by creating your own sub-folder called "MyProgram Client"
Step #2, Start the WCCONFIG Access Profiles manager and select the access securities you want to edit the Clients section. In the Clients section, you should see MyProgram Client listed. Toggle it to have the X tag and save your profiles.
Step #3, Edit your main HTML-MyProgram.WCC source code, and place the following at the top or in the appropriate place in your code. It should be the first thing that is done:
#include "clientlib.wch"
if not CheckClientAccess("MyProgram Client") then
print "You do no have access to this module!<br>"
end
end if
Step #4, Compile it to create the Html-MyProgram.wcx file.
Step #5, Finally, test the security by running HTML WCX URL via wcWEB under various login accounts; ones with access and ones without.
Note, your URL could be one of the followings:
/code/html-myprogram.wcx
/client?myprogram.wcn
The only reason why you may want to use the /client syntax is because if you have a myprogram.exe installed on the wcNavigator user's machine. If its purely a wcWEB application, then you can use the /code syntax or /client syntax with the parameters mode=html:
/client?myprogram.wcn?mode=html
Using the Master Administrator Access:
If your WCX is specifically designed to run for the MASTER administrator, you can use this simple wcBASIC code at the top of your application to limit access only to master administrators:
if GetObjectFlags(OBJECTID_MASTER_SYSOP) = 0 then
print "Restricted Access"
End
end if
When this is used, users who have the Master Administrator Access option enabled in their access profiles will have access to the application.
Text based versus WEB based wcx applications are distinquished and separated by using the HTML- prefix.
WCACCESS-CUSTOM.LST files are useful when you wish to run wcWEB WCX programs without the HTML- prefix and you want to make it available via the web in a controlled manner.
For example, the wcWEB url
/code/html-myprogram.wcx
versus:
/code/myprogram.wcx
The primary reason why a programmer will not want to use the HTML- prefix is one of coding convenience and preference. In a way, one can say the "/CODE/" part and "HTML-" part of the URL are semantically redundant, so it is reasonable to allow programmers run WCX applications without the HTML- prefix.
However, for security reasons, wcWEB will not recognize a HTTP /CODE request for a WCX which does not the HTML- prefix. In such a request, a 404 "not found" response will be issued by wcWEB server.
The reason for this security control is best illustrated by example.
Suppose your company created a WCX application called "special.wcx" designed to run in local mode. It is not designed to run for users. Special.wcx is intended to run only under strict local machine operations. Maybe special.wcx is a report generator. Maybe it is doing some special backend operation. In short, special.wcx is not designed to run by users.
Without the wcWEB HTML- prefix WCX requirement, if a malicious user knew the name of the WCX, it would be possible for unauthenticated users to run the special.wcx via a /public/code URL like so:
/public/code/special.wcx
So unless special.wcx took special precautions to check for authenticated users and/or securities, this would be a security threat.
Hence it is important that wcWEB does not allow WCX applications with a HTML- process to be recognized as valid HTTP request.
If this special.wcx was designed to be run via the WEB and you didn't wish to renamed it to HTML-SPECIAL.WCX, then you can control the security by using WCXACCESS-CUSTOM.LST access filter files.
If the WCX has the HTML- prefix, wcWEB will allow it to run and its outcome is purely based on what the HTML- wcx itself does. It can contain its own internal security as outlined in the previous section, but wcWEB will not do any checking for wcx applications having a HTML- prefix.
If the WCX has no HTML- prefix, wcWEB will check the following files for access, in this specific order:
To allow access to the non-html WCX file, simply add the WCX program name to your custom WCX ACCESS file, data\wcxaccess-custom.lst. Do not add it to data\wcxaccess.lst.
If the wcx file name is found in the file, WCWEB will continue to run it. If it is not found in the file, wcWEB will issue a 404 not found HTTP response.
There are special advance commands you can use to control WCX access by various session conditions. These advanced commands and conditions are discussed in Advanced WCX Access Commands.
DATA\WCXACCESS-CUSTOM.LST (For Customers)
The DATA\WCXACCESS-CUSTOM.LST is designed for customers to create. It is not supplied by SSI and it is not available during installation. You can use the WCXACCESS.LST as a template to create your own WCXACCESS-CUSTOM.LST file.
DATA\WCXACCESS.LST (For Santronics Only)
The DATA\WCXACCESS.LST is a stock file supplied by SSI and it is meant for SSI to whitelist special WCX applications that are distributed with Wildcat. You should not edit this file, unless it is 100% necessary. If you do edit it, keep in mind future updates may overwrite this stock file. If you want to create your own access file, use the custom file instead.
By default, the access file is a "White List", meaning if the wcx file name is found in the file, wcWEB will allow access to the WCX.
WCWEB will read the access file starting at the top and read each line. Lines beginning with # or ; are comment lines and ignored.
There are two commands that are checked as it reads the file:
Commands:
$ALLOW
$REQUIRE
Each command has the same syntax and optional conditions that it checks for:
$command SECURITY name[, name]
allow if security matches
$command IP ip[, ip]
allow if ip matches
$command USERNAME name[, name] allow if username matches
$command USERID #[, #]
allow if Userid matches
$command PUBLIC
allow if not authenticated
$command PRIVATE
allow if Authenticated
$command PCUSER name, [name] allow if
name is local machine user
$command AJAX
allow if AJAX call
The difference between the commands $ALLOW and $REQUIRE is:
$ALLOW sets a "ONE OF THESE" condition
$REQUIRE sets a "MUST HAVE THIS" condition
Example: Allow only administrator or syop security to run special.wcx
$ALLOW SECURITY Administrator, Sysop
special.wcx
Example: Allow only administrator or syop security or user on the local network and the request must be a AJAX command. Can not use the browser address input field.
$ALLOW SECURITY Sysop, Administrator
$ALLOW IP 192.168.1.*
$REQUIRE AJAX
special-ajax-program.wcx
Example: Require that the user be the administrator to run wcrefresh.wcx from the web.
$ALLOW SECURITY Sysop, Administrator
wcrefresh.wcx
