Dynamic Web Development with Seaside

Buy PDF Buy Print

23.1Preparing for Deployment

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.

Alternatively, you may find it easier to copy your application code into a pre-prepared, ‘stripped-down’ image. For Pharo we have had good experiences using the Pharo Core or Pharo Kernel images.

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:

WAAdmin applicationDefaults
removeParent: WADevelopmentConfiguration instance

You can always add it back by evaluating:

WAAdmin applicationDefaults
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:

  1. Click on Configure of the particular entry point.
  2. In the section Inherited Configuration click select WAAuthConfiguration from the drop down box and click on Add. This will will add the authentication settings below.
  3. Set login and password in the Configuration section below.
  4. Click on Save.

Configure an application for deployment

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'.
application configuration
addParent: WAAuthConfiguration instance.
application
preferenceAt: #login put: 'admin';
preferenceAt: #passwordHash put: (GRPlatform current secureHashFor: 'seaside').
application
addFilter: WAAuthenticationFilter new.

Alternatively you can use the method WAAdmin>>register:asApplicationAt:user:password: to do all that for you when registering the application:

WAConfigurationTool class>>initialize
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:

application
preferenceAt: #resourceBaseUrl
put: 'http://www.seaside.st/resources/'

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.

Configuration options for absolute URLs

Have a look at Figure 150 to see visually how these settings affect the URL. Server Protocol lets you change between http and 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:

application
preferenceAt: #serverProtocol put: 'http';
preferenceAt: #serverHostname put: 'localhost';
preferenceAt: #serverPort put: 8080;
preferenceAt: #serverPath put: '/'

User Contributed Notes

astares (9 January 2014, 10:12 pm)

#('browse' 'config' 'examples' 'javascript' 'seaside' 'status' 'tests' 'tools' 'welcome' )

do: [:each| WAAdmin register: self asApplicationAt: each user: 'admin' password: 'seaside' ].

 

WADispatcher default defaultName: 'myapp'

gaston.dalloglio (17 June 2013, 2:05 am)

eleison: See my note in http://book.seaside.st/book/advanced/deployment/deployment-preparing

gaston.dalloglio (3 January 2012, 10:03 pm)

In step 2 of "Password Protection", after do "add", asked me for a user and password (that are admin -> seaside). Maybe this info can be added to this step.

Add a Note

Copyright © 23 April 2014 Stéphane Ducasse, Lukas Renggli, C. David Shaffer, Rick Zaccone
This book is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 license.

This book is published using Seaside, Magritte and the Pier book publishing engine.