This section discusses the normal case where the token is used to find out which contexts belong to a specific user. To prevent to user from getting the same application more than once, the framework internally adds the application name to the token. This is needed because if a connection to a (physical) server fails for some time the UI might try to reconnect to all its contexts (i.e. applications).
Since the reconnect feature allows the UI Engine to reconnect to an existing context with potentially secret business data it is important to have a secure ULC reconnect token strategy. Therefore the strategies contained in the release should only be used as examples. If using a symmetric encryption algorithm (as within XXX) keep in mind that it will not be very hard for an enemy to reverse engineer the Java part (i.e. UI proxy of the strategy). If the company's underlying infrastructure (middleware) identifies and knows the user of the connection then the easiest and most secure implementation would be to identify the user on the server side without a UI round trip to ask the user for name and password.
To write the new strategy a new subclass of UlcReconnectTokenStrategy must be made and the getToken private method must be implemented: This method must return a String which is used when a user wants to reconnect to disconnected contexts. Normally this token identifies a user. If the server can identify the user then it can return its ID/token directly; otherwise a request must be sent to the UI to query the user for name and password.
getToken | challenge | challenge := self nextRandomNumber. ^self decrypt: (self context getUIReconnectTokenWithStrategy: self withChallenge: challenge printString) usingChallenge: challenge
The above example makes a call to the UI to ask for user name and password. This is always done using theUlcContext>>#getUIReconnectTokenWithStrategy:withChallenge: method. Get the token used for client reconnection from the UI using the specified strategy and the optional challenge (which can be used for encryption). This method must only be used by UlcReconnectTokenStrategy subclasses. This request is executed synchronously.
If user interaction is involved (eg entering name and password) then the typeString private method must be implemented too: Return the String that should be used as my identifier in all requests to the UI. Of course this method need only be implemented if the strategy sends requests to the UI.
typeString ^'com.ibm.ulc.ui.UserPasswordTokenStrategy'
There are four things to keep in mind:
This section describes the methods involved if strategies different from the ones above need to be implemented.
The next two methods must be kept in sync because they are used to get the token enriched with the application name. Normally the framework attaches the application name to the token that getToken returns. If you want to change the scope of the reconnect dialog, e.g. showing all hanging applications (in that server process/image) for a user without looking at the application name, you can do it by overwriting these two methods: