Web console
Web console is a built-in HTML based application that provides command line interface to execute commands on the server within context of the Helicon Zoo application. Many application technologies, like Ruby, Python, Perl, Node.js, etc. require you to execute console commands during development and deployment process. These commands may include various calls to install application modules and other requirements, database creation or migration scripts, calls to create application template or modify application structure. While you may still use Windows command line interface to execute these commands, please note that with Helicon Zoo applications are executed in isolated environments. For example you may have number of environments and interpreters installed on your machine, like several different versions of Ruby and Python. With Windows console when you run a command you can’t tell for sure what exact version of interpreter you are calling, where it is located, where will it store it's settings, etc. Commands to install modules will usually install them globally into the system, so your application will lose portability. There could be conflicts between different versions of engines or modules installed in the system when you run global command line interface. This is why it is always recommended to install web application engines using Helicon Zoo repository, like installing Hosting Packages, instead of installing engines manually. And use of Helicon Zoo web console may also be essential if you want to avoid version conflicts and retain application portability.
Helicon Zoo web console was designed to run commands in the isolated environment of your application, so you can be sure all commands are applied to the application you are working on and executed by the same interpreter that runs the application itself. Applications keep portable because all modules and components are installed into the application folder and execution environment is easily replicable with Helicon Zoo hosting packages installation.
To use web console please specify CONSOLE_URL environment variable in the web.config file inside your web application folder. The default value for this variable is not set therefore there is no console for applications when it is not configured explicitly. The Helicon Zoo project templates for such technologies as Ruby, Python, Perl and Node.js has console URL already configured as the /console folder under project root.
For security purposes web console can only be invoked if the request comes from localhost or if any of the authentication method is used. No anonymous external access is allowed to the web console. If you wish to access web console remotely you need to enable authentication for the folder where CONSOLE_URL variable is pointing. On the local machine console will open without authentication.
The web console can be set on or off either globally or for individual web sites using switchboards in the applicationHost.config file. The syntax is the same as for enabling/disabling web application engines. By default web console is turned on. Put the following code into the <heliconZooServer> section of applicationHost.config to disable web console:
<heliconZooServer>
...
<switchboard>
<add name="console" enabled="false" />
</switchboard>
</heliconZooServer>
Shared hosting security considerations
Web hosting administrators always tend to restrict console access for remote users in a shared hosting environment. Since Helicon Zoo web console is designed to run in the context of IIS web site and with same credentials as user’s web application, the user in fact does not gain any additional powers or permissions by accessing the console. It is not the console creating a security breach, but incorrectly configured file permissions and user rights in the system. Generally you need to configure IIS to run every shared hosting client web site as a separate application pool with a dedicated user account, which should not have any write permissions except for the web site folder it owns. If all web sites run from a single Windows account with write permissions to some shared folders, restricting console access will not prevent these files from modifications. They could be damaged by scripts, CGI programs or direct file system access anyway. So the console itself isn’t good or evil. If you configure file permissions and system security correctly, if you use UAC and other Windows built-in security restrictions, then it is safe to allow shared hosting clients to have console access to the server. Otherwise restricting console access only hides the symptoms but does not improve a real security. So our suggestion is to set up server security according to hosting security best practice guidelines and to enable console access for remote clients as this will simplify client's development process significantly.