Dynamic Web Development with Seaside

Buy PDF Buy Print

18.6Recovering from Expired Sessions

The simplest way to change the default behavior of session expiry is to make your application bookmarkable. This involves serializing part of the application state into a URL so that at any later point in time it can be retrieved, even if the session has expired. This is also a useful feature if you want that your application to be indexed by search engines or if you want to allow the possibility of bookmarking certain states of the application.

Normally as a Seaside application developer we don’t worry about URLs. This is the only section of the whole book where we do, because we want to remember some of the application state. This is only because we want to be able to retrieve it later in case the session expired. Again we are using the MiniInn application as our running example.

Seaside provides the method WAComponent>>updateUrl: as a hook method that is called whenever the page is rendered. It allows one to modify the automatically generated URL that is displayed in the address bar of the web browser, so let’s override it in our class:

MiniInn>>updateUrl: anUrl
super updateUrl: anUrl.
startDate isNil
ifFalse: [ anUrl addField: 'startDate' value: startDate ].
endDate isNil
ifFalse: [ anUrl addField: 'endDate' value: endDate ]

In the above example we add both the value of startDate and endDate as a parameter to the URL. Have a look at the methods in WAUrl to see other possibilities on how to modify the URL differently:

  • WAUrl>>addField:value: Append the value with the key to the list of parameters. The key should be a string and not start with an underscore, such keys are reserved for internal matters by Seaside. The value will be converted to a string.
  • WAUrl>>addToPath: Append the argument as a new path element. If the argument contains slashes the string is split into multiple elements.
  • WAUrl>>fragment: Set the fragment part of the URL. This is the part at the very end of the URL separated by #.

Note that we could also have added the currently authenticated user to the URL. Essentially anything that can be meaningfully transformed to a string can be appended. It is the responsibility of the developer though to decide what application state is meaningful. As URLs are strings accessible to your users, you should expect that they might to try to manipulate the URL manually. Thus, it is better to avoid putting any security related information in there. Also try to avoid putting too much information into the URL, as some web browsers and servers have problems with URLs that are more than 2048 characters.

When running the modified application there is not much difference. If you select a date it should appear as an URL parameter and stay as long as you don’t change it again.

How can we now benefit from this additional information in the URL? Well, if the session expires we can have a look at the request parameters and we might find some information there that we can restore. To do this Seaside provides another hook method called WAComponent>>initialRequest: as presented earlier in this Chapter.

MiniInn>>initialRequest: aRequest
super initialRequest: aRequest.
aRequest fields
at: 'startDate'
ifPresent: [ :value | startDate := value asDate ].
aRequest fields
at: 'endDate'
ifPresent: [ :value | endDate := value asDate ]

When a new session is started, Seaside calls the method initialRequest: on all initially visible components. Other than that, the method is never called. This allows us to have a look at the WARequest object and check if any of our URL parameters are present. If so, we convert the strings to a date and assign it in our model. We successfully restored part of our application state.

To test we need a way to flush all Seaside sessions. First start a session, login and select a start and end date. Then use the following expression to expire all active sessions in your image.

WAAdmin clearSessions

When clicking on any link or simply pressing the refresh button, you will notice that the authenticated user was dropped. However, the start and end date is still persistent and you can interact with your application from within a new session.

More sophisticated examples of the interplay between updateUrl: and initialRequest: are included with your Seaside distribution. Browse for implementors of these two messages.

Copyright © 24 February 2017 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.