Because Smalltalk offers you an image-based development environment, deploying your application can be as simple as copying your development image to your server of choice. However, this approach has a number of drawbacks. We will review a number of these drawbacks and how to overcome them.
Stripping down your image. The image you have been working in may have accumulated lots of code and tools that aren’t needed for your final application; removing these will give you a smaller, cleaner image. How much you remove will depend on how many support tools you wish to include in your deployed image.
Preparing Seaside. The first task in preparing Seaside for a server image is to remove all unused applications. To do this go to the configuration application at http://localhost:8080/config and click on remove for all the entry points you don’t need to be deployed. Especially make sure that you remove (or password protect) the configuration application and the code browser (at http://localhost:8080/tools/classbrowser), as these tools allow other people to access and potentially execute arbitrary code on your server.
Disable Development Tools. If you still want the development tools loaded, then the best way is to remove
WADevelopmentConfiguration from the shared configuration called "Application Defaults". You can do this by evaluating the code:
removeParent: WADevelopmentConfiguration instance
You can always add it back by evaluating:
addParent: WADevelopmentConfiguration instance
Alternatively you can use the configuration interface: In the configuration of any application select Application Defaults from the list of the Assigned parents in the Inherited Configuration section and click on Configure. This opens an editor on the settings that are common to all registered applications. Remove
WAToolDecoration from the list of Root Decoration Classes.
Password Protection. If you want to limit access to deployed applications make sure that you password protect them. To password protect an application do the following:
- Click on Configure of the particular entry point.
- In the section Inherited Configuration click select
WAAuthConfigurationfrom the drop down box and click on Add. This will will add the authentication settings below.
- Set login and password in the Configuration section below.
- Click on Save.
If you want to programmatically change the password of the Seaside configure application, adapt and execute the following code:
| application |
application := WADispatcher default handlerAt: 'config'.
addParent: WAAuthConfiguration instance.
preferenceAt: #login put: 'admin';
preferenceAt: #passwordHash put: (GRPlatform current secureHashFor: 'seaside').
addFilter: WAAuthenticationFilter new.
Alternatively you can use the method
WAAdmin>>register:asApplicationAt:user:password: to do all that for you when registering the application:
WAAdmin register: self asApplicationAt: 'config' user: 'admin' password: 'seaside'
Next we have a look at the configuration settings relevant for deployment. Click on Configure of the application you are going to deploy. If you don’t understand all the settings described here, don’t worry, everything will become clearer in the course of the following sections.
Resource Base URL. This defines the URL prefix for URLs created with
WAAnchorTag>>resourceUrl:. This setting avoids you having to duplicate the base-path for URLs to resource files all over your application. You will find this setting useful if you host your static files on a different machine than the application itself or if you want to quickly change the resources depending on your deployment scenario.
As an example, let’s have a look at the following rendering code:
html image resourceUrl: 'logo-plain.png'. If the resource base URL setting is set to http://www.seaside.st/styles/, this will point to the image at http://www.seaside.st/styles/logo-plain.png. Note that this setting only affects URLs created with
WAImageTag>>resourceUrl:, it does not affect the generated pages and URLs otherwise.
Set it programmatically with:
Server Protocol, Hostname, Port and Base Path. Seaside creates absolute URLs by default. This is necessary to properly implement HTTP redirects. To be able to know what absolute path to generate, Seaside needs some additional information and this is what these settings are about. These settings will be useful if you are deploying Seaside behind an external front-end web-server like Apache.
Have a look at Figure 150 to see visually how these settings affect the URL. Server Protocol lets you change between
https (Secure HTTP). Note that this changes only the way the URL is generated, it does not implement HTTPS — if you want secure HTTP you need to pass the requests through a HTTPS proxy. Server Hostname and Server Port define the hostname and port respectively. In most setups, you can leave these settings undefined, as Seaside is able to figure out the correct preferences itself. If you are using an older web server such as Apache 1 you have to give the appropriate values here. Server Path defines the URL prefix that is used in the URLs. Again, this only affects how the URL is generated, it does not change the lookup of the application in Seaside. This setting is useful if you want to closely integrate your application into an existing web site or if you want to get rid or change the prefix
/appname of your applications.
Again, if you want to script the deployment, adapt and execute the following code:
preferenceAt: #serverProtocol put: 'http';
preferenceAt: #serverHostname put: 'localhost';
preferenceAt: #serverPort put: 8080;
preferenceAt: #serverPath put: '/'